[BRLTTY] Brltty and the latex-access project

Daniel Dalton d.dalton at iinet.net.au
Thu Jan 19 08:16:42 EST 2012

On Fri, Jan 13, 2012 at 09:43:39PM -0500, Dave Mielke wrote:
> >latex-access still a problem, i.e. cursor routing data? I believe
> >getting a translation which was the desired length i.e. the same length
> >as the Braille display in use was still a bit of a problem? 
> I'd stopped at the point where we needed to settle on a protocol for passing 
> data back and forth. It needs to support sending multiple values in both 
> directions. What do you think about sending a set of lines, each in the form 
> name=value, with a blank line at the end? So, for example, brltyt might send 
> something like this to your software:
>    cursor=12
>    length=40


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 :)

That sounds ok as far as I can tell. 

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? 

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...?

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? 

>    text=   utf-8 encoded characters which can be indented and contain blanks

I really don't know much about uf8 to be honest... 

> Output from your software back to brltty would be the same, but, of course, 
> with a different set of data. Is this approach okay?

Sounds pretty good to me. 

> We'd need to decide how to deal with newlines in the input text, as well as 
> with whatever braille dot combination looks like a newline in the output data.

MMMM. we didn't really have a translation for new line characters,
besides wouldn't this change across Braille codes, currently
latex-access is very stable with nemeth and relatively stable with ueb
though there are some fundimental  bugs. 

> We could always have a way for the output to say that BRF characters are being 
> used, which would support 6-dot braille and which wouldn't have a newline 
> problem.

Wouldn't the output always be brf output though if it was coming through

To make what I'm saying clearer you can check out the code in svn at 

The testscript in the root directory should demonstrate how the latex is
converted to Braille. 

For instance you could do 

y = 2\sin(\frac{\pi}{2}x)+1
x = \frac{-b\pm\sqrt{b^2-4ac}}{2a}

To get an idea of how the translation actually works. 

Thanks for your help,

More information about the BRLTTY mailing list