When how would you accommodate continuous grade two reading of text on a braille display? I am assuming that if the reader advances the display to the next text area (40 or 80 characters) then you would get computer braille again and then have to toggle or switch to grade two braille. Q. How does the brltty buffer get filled? Say, every time you hit next page or previous page in pine or hit spacebar in lynx, does it reinit the buffer and refill it with new text? all I know is that in spb.exe and jaws, once you toggle grade two braille on, it remains on, until you turn it off regardless of what you do from the computer keyboard that effect the cursor or mouse pointer. text always continues to go to the display as grade two until you turn it off. -- Bill Gaughan wgaughan@snet.net On Mon, 26 Nov 2001, Dave Mielke wrote: > [quoted lines by John J. Boyer on November 26, 2001, at 08:49] > > Hi: > > >The Grade 2 translation should be on-the-fly and should affect only as much > >information as will fit on the display. > > BRLTTY, of course, would have no way of knowing how much translated data will > fit within the braille window. It, therefore, would have to pass in the whole > rest of the line starting at the position where the left end of the braille > window is. > > What about the case where the left end of the braille window starts in the > middle of a contraction? This shouldn't happen when already in grade 2 mode, > but might happen when switching into grade 2 mode. I guess it should just leave > that little bit at the beginning uncontracted. > > There's also the possibility that the end of what'll fit within the braille > window won't fit. Should it show the beginning of the contraction/symbol, or > leave the end of the window blank? > > >Translating the whole screen at once > >would probably be a bad idea. > > I agree, even if simply because it may be a lot of useless work since the > screen might change by the time te reader gets there. > > >One way the Grade 2 translator could work > >would be to pass it the place where the translation is to begin. It will > >then translate as much as will fit on the display and pass back the place > >where it ended. > > I think it'd have to be screen unaware. I'd like to be able to pass in a > character string, which would end up being the rest of the current line from > the place where the braille window starts. To make cut&paste work correctly, > I'd want back the offset into the input string of each character in the output > string. > > >The translation tables should be provided in a form that is easily edited, > >so that users can make changes and write tables for new languages. A table > >compiler would probably be advisable to preprocess the tables before they > >are actually used in translation. > > Yes, that'd be a good way to design it. Hopefully the table would be general > enough to support languages other than English. > > >A keystroke on the Braille display can toggle between Grade 2 and the > >present display mode. > > Agreed. > > >The table can be "compiled" when BRLTTY starts, or even recompiled > >on-the-fly with a special keystroke. > > Bewtter yet might be to check the timestamp on the table, and recompile if it > changes. > > >We can do better than Jaws, which doesn't have user-accessible tables. > > Of course! > >