[BRLTTY] Brltty and the latex-access project

Daniel Dalton d.dalton at iinet.net.au
Sun Feb 5 22:34:12 EST 2012


On Sat, Feb 04, 2012 at 11:47:40AM -0500, Dave Mielke wrote:
> >Sorry for the delay, I've been out of town for a few days and not the
> >kind of thing I can really study through email via android :)
> 
> Well, we've both been taking turns introducing delays. :-) My excuse, this 
> time, is that I was working on yet another driver. As of last night, however, 

No worries, thanks for all your work so far:)

> you'll find that executable contraction tables actually do work in the 
> development stream. Note that they don't work yet on Windows.

OK. Thanks. 

I test with my original python script now or maybe there are some minor
changes, I'm not sure, but it's the same one in svn as of now in the
latex-access svn branch... 
https://latex-access.svn.sourceforge.net/svnroot/latex-access

It seemed to be doing more than before, but my Braille display was
rapidly changing, so fast that I couldn't get time to see what it was
displaying. It was probably moving at more than 10 times a second, not
good for the display, I'm guessing, so didn't do that for long. 

> cursor=number: The cursor position, starting from 1. 0 means no cursor.

At this stage I'd say 0 since cursor routing isn't fully implemented on
latex-access' side yet. 

> 
> ecw=number: The "expand current word" setting. 0 means no, and 1 means yes. 
> There's a current word if the cursor is on a non-space character, and includes 
> all non-space characters either side of the cursor as well.

Hmm, I like this idea very much. In mathematics latex math mode any
spaces are ignored - so it'd be up to the user to remember to add
spaces. Is it possible to customise the way this works and say, look for
other symbols like bracing, +- and \? Anyway we can worry about that
later as I'm sure there is still many more important things to attend to
first. 

> outmax=number: The translator should stop translating once this many braille 
> characters have been rendered. If that's in the middle of a contraction then it 
> should stop early, in which case brltty will automatically pad with blanks.

So it is up to my project to stop translating after the translated text
reaches the length of the display? Does this mean I'll need to
just pass a string like output(text[:40])? 
(assuming the display is 40 cells long)

> text=characters: The characters which need to be translated. They're sent in 
> UTF-8 encoding, so the translator should use its source language's standard way 
> of decoding UTF-8 into its natural encoding.

So in this case this is the raw latex source which will be passed to a
function such as nemeth.nemeth.translate (text) which will convert the
latex source into nemeth and return the brf output?

> I'll let you know what needs to be sent back for cursor routing once I've 
> decided how it should be done. It won't be a simple new cursor position. It'll 
> need to be a list showing which points in the input map to which points in the 
> output.

Yes. At this stage cursor routing is only begun to be implemented on the
latex-access side, but it works for a few symbols and I intend to
continue developing this when I get a chance. 
> As mentioned above, your translator can stop early. I think I'll even add some 
> protection so that things won't go wrong if you send too much data either.

Great

> Would you like me to modify your Python script to handle the above-described 
> protocol?

Yes, thank you, that would be fantastic! 

Thanks very much for all your hard work! 

Dan


More information about the BRLTTY mailing list