Re: [orca-list] Tabs with brltty and orca

[Willie Walker <William Walker Sun COM>]

Hi Michael:

The main thing that is happening here is that the application is 
interpreting the tab and then adjusting the horizontal position of the 
text based upon its interpretation.  Without peering into the guts of 
the application, it's not really possible to predict where the text is 
going to end up by analyzing just the text string itself.  The problem 
gets even worse when someone presses space a few times before pressing 
tab -- in this case, the text can often start on the same exact position 
on the line had the person pressed tab alone.

What's currently happening in Orca is that it's telling you pretty much 
exactly what is in the text string.  We are looking at ways to support 
more of a 'physical' presentation of what's on the screen and are 
tracking it here:

http://bugzilla.gnome.org/show_bug.cgi?id=400732

Hope this helps,

Will

Michael Whapples wrote:
> I will try and explain this, and I believe it is a brltty and orca
> issue.
>
> All characters in a computer have a unique value, and it is up to the
> computer (operating system or any other software controlling the output
> devices) to decide how these should be displayed. In a text console, I
> believe it expands tabs for the display (enters the number of spaces
> needed to make the correct indentation) and for nano I guess that orca
> is getting this expanded tab (nano understands it as a tab character,
> that is why when backspacing a tab in nano it only takes one press to
> remove it). 
>
> For gedit (or other GUI apps such as eclipse), orca is interacting with
> the app, not a console (display system) so recieves the tab character
> itself. Orca could expand the tab (I think the windows based screen
> readers do), but orca doesn't and passes the tab character to brltty.
> Brltty might be able to expand the tab as well, but the table for nabcc
> (/etc/brltty/text.nabcc.tbl which probably is the table you are using)
> defines tab as dots 2 4 7 and 8. You will find other characters which
> bring up strange braille symbols (the carrage return character, used by
> windows as part of the new line marker displays dots 1 3 4 7 and 8).
> Infact this behaviour isn't entirely unique to orca and linux, the linux
> new line character (typically \n in programming or value 0x0A in hex)
> when viewed in notepad by window-eyes appears in braille as dots 2 4 5 7
> and 8.
>
> To state it shortly, something needs to process the tab characters,
> console apps have the console doing this, but GUI apps miss that middle
> step out and communicate direct with orca and so nothing changes them to
> multiple spaces.
>
> Now how to resolve this. Either orca needs modifying which should be
> possible but requires programming skills, or alter the brltty table
> although I am unsure if brltty supports mapping a single character to
> multiple braille cells.
>
> Hope this helps you understand why and what might be done about it.
>
> From
> Michael Whapples
>
>
> _______________________________________________
> Orca-list mailing list
> Orca-list gnome org
> http://mail.gnome.org/mailman/listinfo/orca-list
> Visit http://live.gnome.org/Orca for more information on Orca