[BRLTTY] Brltty and the latex-access project

[Daniel Dalton]

On Mon, Dec 12, 2011 at 01:50:50AM -0500, Dave Mielke wrote:
> [quoted lines by Daniel Dalton on 2011/12/12 at 12:45 +1100]
> 
> >I was just wondering whether the addition of executable contraction
> >tables to support the latex-access project we discussed last week was
> >still a possibility. There is no hurry of course, i'm just receiving
> >some pressure from fellow developers as to the status of this project so
> >we can be aware of roughly how long it should take? 
> 
> Yes, it's definitely feasible. Unfortunately, I do have a paying job to contend 

Great

> with, and, once in a while, my management likes to make high priority demands 
> on my time. That's why I was unable to work on this project last week.

Yes, certainly. Sorry, didn't mean to sound pushy, was just wanting to
track progress that's all...

> 
> I've actually, just now, added the infrastructure for executable contraction 

Thanks

> tables. The rest will just be coding in this specific area. All the changes 
> that impact the general code have now been made.

What do you mean by coding in this specific area?

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

> >We've began implementing cursor routing support into our code as well,
> >so it's definitely worth supporting this, although we do have quite a
> >bit of work to do on this still. 
> 
> Excellent! We'll have to decide on a format for you to pass this data back to 
> brltty. BRF, of course, won't be good enough. I'll include support for BRF 
> because it's good enough for the normal case, but we'll need a way to pass more 
> information. We may even want to consider, right up front, a way to pass all 
> eight dots, rather than just six, as well.

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

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? 

Thanks,
Dan