Yup. I think we will need to file an request for enhancement somewhere
for this, and block this enhancement request against it.

Rich, could you please check how our current OOO bugs apply to this and file new ones if necessary?  This hasn't worked and they keep closing the attribute bugs so we might just have to re-open an existing one.  

I've just tried this with Writer in OOo 2.0.4. I did Insert-f to
get the text attributes for some text that was in Times-Roman.
Listed below are the default text attributes that we are getting 
back.

First some italic text:

size:12; left-margin:0; pixels-below-lines:0; pixels-above-lines:0; variant:normal; invisible:false; right-margin:0; strikethrough:false; underline:none; indent:0; style:normal; weight:400; justification:left

Then some bold text:

size:12; left-margin:0; pixels-below-lines:0; pixels-above-lines:0; variant:normal; invisible:false; right-margin:0; strikethrough:false; underline:none; indent:0; style:normal; weight:400; justification:left

Italic and bold are nicely being spoken by Orca. Note that we are 
able to do this because we can get the text attribute associated 
with the specific piece of text under the caret:

('style:italic', 10, 19)

and

('weight:600', 26, 32)

We don't get the font name, so I can file a bug against OOo 
Writer on that. Before I do that though, I have two questions:

1/ Are there any other text attributes that we want OOo to provide
   that aren't listed above?

2/ Are there any other text attributes that we want Orca to 
   automatically present that aren't currently being presented?

1.  Of course there are Rich. ;-)  

The executive summary is that if it is an attribute that can be applied to the text and readily identified by the sighted user via a mere glance, we want OOo to tell us about it.  It's a pain to have to suspect that something is formatted a certain way and then dig around on toolbars and/or dialogs in order to confirm those suspicions.

In particular:

* What I would consider a style (e.g. heading 1, text body, List)

* The bulk of the items in the Character dialog (Format menu... Character):
  * Color (foreground and background)
  * Highlighting
  * Position (superscript, subscript, normal)
  * Scale width
  * Spacing (expanded, collapsed, normal)
  * Relief
  * Rotation
  * Outline, Shadow, Blinking

2. This is probably one of those "poll the users" questions.  

*I* am of the opinion that one should be able to ask Orca for all of the aforementioned attributes for the same reason I think OOo needs to provide them. 

Under typical circumstances, Orca should only speak things that are different from the norm. (i.e. I don't need to know when text ISN'T blinking; only when it is). 

Perhaps we could have a setting a la punctuation in which we can specify just how much attribute information Orca provides?  (And then we can customize it on an app-by-app basis!) ;-)

I agree with everything you said. I really like the idea of having a
settings.<whatever> value for each text attribute and a default value, 
which can then be overridden on an individual application basis. 

I would like to have that in a separate RFE though, otherwise we are 
never going to get this one closed.

So I suggest this:

Please file a new RFE asking for these two new things:

1/ all the attributes you mention above that OOo doesn't give us.
   Feel free to reference this bug in the commentary.
2/ for each of those attributes: to have their own individual settings.

I'll then file an initial OOo blocker bug against the first part of
that new rfe, and see what we can do towards the second part with the 
existing attributes.

Let's keep this bug for style and font name. 
I think style is working just fine in OOo 2.0.4 and I'll 
open an OOo bug against font name tomorrow.

Thanks Joanie.

I wrote:

  "I think style is working just fine in OOo 2.0.4"

Joanie replied (via emaiul):

  "What I mean by "style" is the thing that you choose in the
  combo box that is just to the left of the font name -- or by going to
  the Format menu and selecting Styles and Formatting.   Getting "normal"
  and "italic" through the "style" exposed by OOo 2.0.4 is working just
  fine.  However, getting information about the style being used (like
  whether or not it's a heading, etc.) is, from what I can tell, not
  working at all because OOo is not exposing that information."

Understood. I'll make sure I mention this when I file the OOo bug
tomorrow. Thanks.

Thanks Rich!

As was also discussed via email:  It seemed to me that the RFE Rich requested I file might make more sense as two RFEs. Rich concurred.  Therefore:

Text attribute settings RFE:  bug #372964
OOo Writer attributes RFE:  bug #372965

Thanks for the two new RFE's. I've opened issue #71383
against OOo for this problem and adjusted the summary of
this bug to reflect that we are currently blocked.

http://www.openoffice.org/issues/show_bug.cgi?id=71383

Rich (and others):  Given the progress updates on the OOo bugs and announcement that this was verified in 2.2-dev m5, I had to give it a try.  Look at all the attributes we're now getting:

attribute run: (['line-height:100%', 'paragraph-style:Default', 'justification:left', 'pixels-below-lines:0', 'pixels-above-lines:0', 'indent:0', 'right-margin:0', 'left-margin:0', 'vertical-align:baseline', 'writing-mode:lr-tb', 'text-shadow:none', 'text-rotation:0', 'text-decoration:none', 'font-effect:none', 'stretch:normal', 'direction:ltr', 'language:en-us', 'scale:1', 'style:normal', 'variant:normal', 'family-name:Nimbus Roman No9 L', 'weight:400', 'size:12', 'strikethrough:false', 'underline:none', 'invisible:false', 'fg-color:0,0,0', 'bg-color:255,255,255'], 0, 5)

default attributes: line-height:100%; paragraph-style:Default; justification:left; pixels-below-lines:0; pixels-above-lines:0; indent:0; right-margin:0; left-margin:0; vertical-align:baseline; writing-mode:lr-tb; text-shadow:none; text-rotation:0; text-decoration:none; font-effect:none; stretch:normal; direction:ltr; language:en-us; scale:1; style:normal; variant:normal; family-name:Nimbus Roman No9 L; weight:400; size:12; strikethrough:false; underline:none; invisible:false; fg-color:0,0,0; bg-color:255,255,255 

Awesome!!!

The above, btw, is for text whose formatting I haven't altered (i.e. for the sake of adding it to settings.enabledTextAttributes). Even though 2.2 is not yet released, and even though we're focusing on 2.1 for GNOME 2.18, would it make sense to go ahead and add support into Orca now for the early adopters?

As for the color, it would sure be nice to have a look-up table of some sort so that we can give names rather than spit out RGB values.  Maybe that's a new RFE?

Hi Joanie,

> Even though 2.2 is not yet released, and even though we're focusing on 2.1 
> for GNOME 2.18, would it make sense to go ahead and add support into Orca 
> now for the early adopters?

Absolutely. It shouldn't adversely affect OOo 2.1 user's if we do it right.
I'll leave it to you and Mike to decide what should be added here. Getting it
in before the next tarball (that Will will build in about 8 days time), should
be our goal.

I suggest that the changes should be confined to the StarOffice.py script too.
There is already:

        settings.enabledTextAttributes = "size:; family-name:; weight:400; indent:0; left-margin:0; right-margin:0; underline:none; strikethrough:false; justification:left; style:normal;"

at line 627. Were you just thinking of adjusting this?

> Were you just thinking of adjusting this?

In terms of the next tarball, yes. :-)  

I was chatting with Will about this yesterday:  Potentially, we might care about all of the new attributes, but we certainly don't want to take all that information in auditorily.  As an experiment, I had adjusted my settings.enabledTextAttributes, went gonzo with some text, and pressed Insert F.  By the time Orca got around to telling me the color, I couldn't recall if my text was blinking or not. :-)  And the only way to find out was to do another Insert F and listen to all the other stuff again until Orca got to that attribute.

So what *I* was thinking long term is that we want two levels of support for text attributes:  What you get from Insert F and some way to access all of the attributes for the current char via a dialog box.  What do y'all think?

As for color, as I mentioned in comment #9, it would be nice to speak a name rather than an RGB value.  That, of course, involves more than simply adjusting settings.enabledTextAttributes.

> So what *I* was thinking long term is that we want two levels of support for
> text attributes:  What you get from Insert F and some way to access all of the
> attributes for the current char via a dialog box.  What do y'all think?

Sounds good to me. Pass it by Mike first though. If he likes it, I suggest
filing a new separate enhancement request.

> As for color, as I mentioned in comment #9, it would be nice to speak a name
> rather than an RGB value.  That, of course, involves more than simply adjusting
> settings.enabledTextAttributes.

Sounds good too, but again as another separate bite-sized enhancement request.

For both of these, I'm not sure we are going to have the time (or more
accurately, the proprity) to do them for this release (let alone the next
tarball). 

Whate (if any) small tweaks do you think should be applied to Orca for
GNOME 2.18?  What still needs to be done before this particular bug (and
the other similar one) can be closed as FIXED?

Thanks.

Will do on the RFEs.  Mike?

Small tweaks on this one:  

1. add 'paragraph-style:Default;' to settings.enabledTextAttributes in StarOffice.py
2. add 'setScriptMapping(re.compile(_('VCLSalFrame')), "StarOffice")' to settings.py
3. Oops, no 3.  Close it as FIXED. :-)

On the other one, I propose that Mike identify which of all those newly-exposed attributes we care about when we press Insert+F and that those get tacked on to settings.enabledTextAttributes in StarOffice.py, and then you close that one out too. :-)

Created attachment 81949 [details] [review]
Patch to implement the two suggestions from Joanie

This seems reasonable. Mike, is this okay with you?
If so, I'll commit it. Thanks.

Here's where *I believe* we are w.r.t. this item:

1. We now provide access to the font name automatically because the OOo guys starting exposing this information via AT-SPI effective OOo 2.2.

2. We *could* be providing access to the style name via Orca_Modifier+F since this information is also now being exposed.  I think we should be; as I recall, Mike thinks it should be presented to the user someplace else/in some other fashion.  Now that the new app-specific settings dialog allows this to be more easily changed, and given that we have RFE 376515 (Add GUI support for the new customizable text-attribute feature) which will make it easier still, I feel far less strongly about Insert F including the style name.

So, *I* think this RFE is complete.  Changing the status from blocked to pending.