[BRLTTY] Brltty and the latex-access project

[Dave Mielke]

[quoted lines by Daniel Dalton on 2011/12/12 at 23:16 +1100]

>What do you mean by coding in this specific area?

Coding specific to executable contraction tables.

>I tested just now, and noticed that my executable table (the code I
>provided to you in the brltty wrapper, also available in the svn for
>latex-access), acts as a brf table, no longer doing nothing like
>before. However, it looks to me that for some reason the executable
>isn't being ran still, (I put code into the python script to create a
>file). When I invoke myself, this works as expected, but brltty never
>triggers this and thus the file isn't created. 
>
>Or is this functionality still needing to be implemented? Maybe I'm
>doing something wrong...?

That part of the code isn't written yet.

>So for now, the output from our python latex-access modules is in the
>form of brf for instance a half is output as "1/2" without the quotes of
>course. Is this output ok? 

As it turns out, now that I'm looking at making this work much more closely, 
it's not qutie enough though I can probably work with it this way for now. The 
problem is that brltty needs to know how much of the source is consumed by the 
amount of contracted braille that fits on the display. Ideally, brltty would 
tell your software how wide the display is and your software would be able to 
then tell brltty how many characters of the source were used up.

>I don't understand why we would be passing cursor routing data in brf anyway? 
>We will have two python lists to hold the corresponding character values, one 
>for latex2braille chars, and the reverse braille2latex chars. (Although this 
>isn't really necessary, but one of the other developers wanted to do this 
>stuff so I'll need to discuss with them.)

The way brltty works is that contracting braille results in the passing back to 
the core of more than just the contracted braille itself. As mentioned above, 
one of the extra pieces of information is how many source characters were used. 
Another is a table which maps offsets into the source to offsets into the 
result. Ideally, the protocol between brltty and your software would allow 
brltty to read back all of this information together.

>Is it best we fully implement cursor routing before attempting to pass
>this to brltty or can brltty assist us with development so we can get
>something working for now, and test our code as we add it? 

Brltty already handles cursor routing. As long as it can read back the 
above-mentioned offset mappings, it'll all work. Cursor routing itself doesn't 
interact with the contraction table at all. Rather, it uses the information 
which was returned when the characters were contracted.

-- 
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/