Re: [orca-list] Braille output for tables

[Willie Walker <William Walker Sun COM>]

Hi Rudolf:

> I wondered, wether it would be useful, if cells in a table row in FF
> would be devided by | rather then a space on the braille display. This
> woudl make it possible to see, if a cell is empty.

In an unrelated phone call the other day, we were discussing the notion
of braille delimiters and allowing people to set them.  These delimiters
would be for things where more than one object is being presented on the
braille display -- a set of cells, a line of objects in a window (flat
review), etc.  

The notion was that there would be a customizable setting that would be
used to determine the delimiter.  The default could be a space (as it is
done today), but people could make it any string they want.  

Another thought was to have some sort of logic to allow you to have
pre/post delimiters -- for example, "[" and "]".  We agreed these would
probably serve to help sell more 80 character braille displays, but were
unsure of the utility of them.  I'm curious about your thoughts on this.

> An other thing that I noticed is, that in some conditions the number of
> spaces between cells is so large, that the next cell does not fit on the
> braille display. This way, you can't even know, that there's an other
> cell coming, unless you scroll the display to the right.

I curious about your thoughts on what Orca should do here.  Should it
compress spaces?  Should it always provide an end-of-line indicator to
let you know there is (or is not) more to be viewed on the line?
Something else?

> Where exactly in the code is the braille for tables in FF generated. I
> tried to hack braillegenerator.py, but nothing happend.

The braillegenerator.py is generally the right spot, but it can get more
complicated.  The first complication is that scripts can feel free to
subclass this, so you might need to look for a custom braillegenerator
class in the script for the application you're working with.

The second complication is that support for tables has an extra
complexity to deal with the "do I speak the whole row or just the cell
when I navigate up/down in the table" setting.  The places to start
looking might be braillegenerator.py:_getBrailleRegionsForTableCellRow
and braillegenerator.py:_getBrailleRegionsForTableCell.

Hope this helps,

Will