Orca customizing readCharAttributes for StarOffice.py

[Joanmarie Diggs <j-diggs comcast net>]

Hi again.  

Thanks to Rich, I have figured out how to create a customized
readCharAttributes for StarOffice.py.  (Thanks again Rich!)  

As was mentioned in another message, there is quite a bit of information
that one can obtain from the OOo Formatting tool bar which is currently
not made available via at-spi including:

* The font name
* The true style name (OOo occasional places something like "oblique"
into style via at-spi, but never things like "heading")
* Line spacing (single, 1.5, or double)
* Whether or not text is bold (although it seems that when "weight" is
400, the text is not bold; when it's set to 600, the text is bold)
* Whether or not the text is a superscript or subscript

I have figured out how to grab all of this information when the toolbar
happens to be visible.  What I'm toying with now is what to do with it.
I figured I'd brainstorm with y'all. <smile>

One possibility is to output all of the information that is not made
available via at-spi and then pass things along to the super class to
handle the rest.  I think the advantage of this approach is that as more
information gets made available via at-spi, one could trim down
StarOffice.py's readCharAttributes -- potentially eliminating it
completely.

The other possibility that occurs to me is to handle things completely
in StarOffice.py and not pass anything along to the super class for
handling. The reason I'm thinking this might be worthwhile is that there
is potentially a lot of attributes which you care about when formatting
a document that you might not care about in some other environment (e.g.
email).  If one takes the approach of outputting some of those things in
StarOffice.py and then allowing default.py to do the rest, the order in
which things are presented might not be ideal.  In my mind, attributes
like bold, underlining, italics, strike through, superscript and
subscript should be grouped/presented together when more than one of
them has been applied to the current text.  If staroffice.py handles
some things and default.py handles the rest, this grouping will not
occur.   Which brings me to a related question:

According to my handy Python reference, dictionaries are unordered.
Since readCharAttributes calls outputCharAttribute which in turn outputs
a given dictionary item by item, I assume we cannot count on attributes
being presented in a particular order.  Is my assumption correct?? If
indeed it is: If there are only a few items, it is, of course, no big
deal.  But if there are lots of items (as may be the case in a
significantly formatted OOo document), it might be nice for the order to
be predictable.

I have other things to brainstorm about, but they depend on what the
answers to the above are, and this message is already really long so
I'll stop for now. <smile>

Thanks in advance for your time and thoughts!
Joanie