[BRLTTY] Brltty and the latex-access project

[Dave Mielke]

[quoted lines by Daniel Dalton on 2012/01/20 at 00:16 +1100]

>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, 
you'll find that executable contraction tables actually do work in the 
development stream. Note that they don't work yet on Windows.

>How would the actual content be passed? i.e. the input line to the
>latex-access translator and then of course output from the latex-access
>translator to the display? 

Yes. YOur translator needs to read from its standard input, do the translation, 
and then write the result to its standard output.

>What data does my project need to send to brltty? I suppose the updated
>cursor position once cursor routing works... 
>And brltty should tell latex-access the position of the cursor...?

Currently, four lines are written to the translator:

   cursor=number
   ecw=number
   outmax=number
   text=characters

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

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.

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.

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 far, the output from the translator can include these lines:

   inlen=number
   brf=bytes

inlen=number: The number of input characters actually translated.

brf=bytes: The BRF-encoded braille.

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.

>Then would it be up to my project to provide brltty with a translation
>of the desired length i.e. if the braille display is 40 cell then 40
>Braille chars? 

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.

>>    text=   utf-8 encoded characters which can be indented and contain blanks
>
>I really don't know much about uf8 to be honest... 

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

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | 2011 May 21 is the End of Salvation.
EMail: dave at mielke.cc | Canada  K2A 1H7   | http://Mielke.cc/now.html
http://FamilyRadio.com/                   | http://Mielke.cc/bible/