[BRLTTY] Brltty and the latex-access project

[Daniel Dalton]

Hi Dave, 

I was just wondering what the status of executable contraction tables
was, currently? Should anything be working at this point is there
anything I could begin implementing on my project's side? I've received
a bit of pressure from fellow developers on my project to follow this
one up... I haven't seen any relevant commits recently anyway. 

Is the way string data will be passed between brltty and my project
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? 

Or do you think this is going to be a lot more difficult to implement
than first thought? If you feel it's best for me to continue work on my
brlapi application rather than this I'm happy to do that, although this
does sound like the ideal solution, so I've paused that for the moment
anyway. 

Thanks for all your hard work on this matter so far anyway. 

Look forward to hearing what you think... 

Regards, 
Dan

On Tue, Dec 13, 2011 at 11:15:51AM +1100, Daniel Dalton wrote:
> On Mon, Dec 12, 2011 at 08:37:25AM -0500, Dave Mielke wrote:
> > >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.
> 
> Right, ok.
> 
> > >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.
> 
> Is this as simple as a len(contracted text)? I think I had to write a
> similar function for the brlapi application stuff when I started
> implementing that. It can be found in brltty.py in the latex-access
> sources. I've put the function below my name. The idea was to basically
> display the right length of contracted text on the display, given it's
> length relative to the cursor of course. 
> 
> > 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.
> 
> So I should return a table which maps latex (input characters) to
> Braille (nemeth output characters)?
> 
> > 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.
> 
> Sorry I meant to say: Should I complete the mapping stuff so that the
> mapping table is complete for this to work? i.e. the mappings between
> the latex input characters, and the Braille (nemeth) output characters. 
> 
> Thanks,
> Dan
> 
> (the code to braille the right length of text in my app, I removed some
> unnecessary functions)
> 
> import brlapi
> 
> class braille:
>   """Establish a connection to the Braille display and allow
>   manipulation.
>   
>   This class provides a mecagnism to easily call commonly required
>   functions of the Braille display, and to send a LaTeX line to the
>   display, having it translated so it looks good on the display, no
>   matter the size. Takes into account where the cursor is."""
> 
>   def __init__ (self):
>     """Initialise the display.
>     
>     Initialise and connect to the Braille display and make a local class
>     handle to the display, self.b."""
>     try:
>       self.b = brlapi.Connection ()
>     except: # No display attached
>       self.b = ''
> 
> # This is the function I was talking about below.
>   def segmentToBraille (self,text, point=0):
>     """Decide on what section of the current line should be Brailled.
> 
>     This function decides what text should be Brailled, given the length
>     of the Braille display, and the location of the cursor."""
>     if text.replace("\n", "") == "":
>       return " " # So we can braille blank line 
>     panning = False # Are we > display length chars into current line
>     display = BrailleDisplaySize () # length of display 
>     reps = 0 # How many display lengths into current line 
>     while point >= display-1: # Shift the Braille window until the
>       # display shows the location of point 
>       panning = True # Hence we are > one dsipaly length in 
>       reps+=1 # How many display lengths into line are we
>       point-=display # Reduce point until it fits on display 
>     if panning: # Hack to get the starting char right 
>       start=reps*display-1 
>     else:
>       start=reps*display
> 
>     end=reps*display+display
> 
>     return text[start:end].replace ("\n", "") # Remove newline chars 
> 
> def BrailleDisplaySize ():
>   """Return the size of a Braille display.
> 
>   Use Brlapi to figure out the size of the connected Braille display."""
> 
>   try:
>     bs=brlapi.Connection() # Connect to the display.
>     return int(bs.displaySize[0]) # Return the number of cells of display.
>   except:
>     return -1 # Either brlapi not found or display not connected
>