GNOME Bugzilla – Bug 372964
Orca should have text-attribute settings
Last modified: 2006-11-18 22:50:41 UTC
As has been discussed in the comments of bug #363827, it would be helpful to have a series of individual text-attribute settings so that the user can customize what information Orca provides when Insert F is pressed. As Rich has suggested, there could be a "settings.<whatever> value for each text attribute and a default value, which can then be overridden on an individual application basis."
Using gedit, a call to text.getDefaultAttributes() return the following attributes: left-margin:2; right-margin:2; indent:0; invisible:false; editable:true; pixels-above-lines:0; pixels-below-lines:0; pixels-inside-wrap:0; bg-full-height:false; rise:0; underline:none; strikethrough:false; size:8; scale:1; weight:400; language:c; family-name:Monospace; bg-color:65535,65535,65535; fg-color:0,0,0; bg-stipple:false; fg-stipple:false; wrap-mode:word; direction:ltr; justification:left; stretch:normal; variant:normal; style:normal We are going to have to come up with nice setting.<whatever> names for each of these.
Here's my suggested approach for how to implement this. We add a new setting in setting.py called enabledTextAttributes. This will be a string of text attributes of the form <key>:<value>; The <value> part will be the "default" value for that attribute. In other words, if the attribute for a given piece of text has that value, it won't be spoken. If no value part is given, then that attribute will always be spoken. For example, here's what settings.enabledTextAttributes will look like by default: settings.enabledTextAttributes = "size:; family-name:; weight:400; indent:0; underline:none; strikethrough:false; justification:left; style:normal;" (Note that we already have a method in default.py called textAttrsToDictionary(), that can convert this into a dictionary.) In readCharAttributes() in default.py, we'll get that setting and convert the string into a dictionary. We'll get the text attributes for the given text string. Then for each of the attributes in the dictionary created from the settings value, we'll look to see if the text attributes has that key. If it does and the value of that key doesn't match the "default" value or if there was no value for that key in the settings.enabledTextAttributes string, then we add it the set of attributes that we want to present for this piece of text. We then call outputCharAttributes() in default.py to speak the text attributes. Note that both readCharAttributes() and outputCharAttributes() can be overridden in specific application scripts if so desired. I now plan to generate a patch that implements this so interested folks can try it out.
Created attachment 76773 [details] [review] Patch to hopefully implement this feature. I've NOT checked this patch in. I'd like feedback from others on whether this is a good fix and/or what adjustments need to be made. Seems to work nicely with gedit and OpenOffice Writer. Here's a variant that you can add to your ~/.orca/user-settings.py that will speak a few more attributes by default: orca.settings.enabledTextAttributes = "size:; family-name:; weight:; indent:; underline:; strikethrough:; justification:; style:;" Again, this is another of those cases where we really should add a nice GUI to Orca to allow users to easily adjust the text attribute settings they are interested in. Once we agree on the way to fix this one, we can add a new enhancement request for that.
Just tried it with Writer, Gedit, and Gaim. I also tried it with app-specific settings. I agree that it does seem to work nicely with the editors. More about Gaim momentarily. In the meantime, some thoughts for your consideration, listed in the order of how badly I would like to see them implemented (1=badly) :-) 1. Now that we have the potential to get lots of attributes via Orca, would it be possible to customize the order in which this information is presented so that the user can get what he/she cares about the most first (size, perhaps), interrupting speech as appropriate? Perhaps the code could look at the order in which the user has specified the attributes in orca.settings.enabledTextAttributes and use it?? 2. Would it be possible to customize the name spoken for each attribute? For instance, instead of "size 12", I might want Orca to say "point size 12" or "It's this big 12" or just "12." 3. Would it be possible to customize what string, if any, is spoken after each attribute? Thus: "size 12 point" (or "12 point" assuming #2 is doable) 4. Please add "strikethrough" to the pronunciation dictionary. ;-) In Gaim, I get an error: Traceback (most recent call last):
+ Trace 87291
consumed = self._function(script, inputEvent)
defDict = self.textAttrsToDictionary(defAttributes)
if item[1].endswith(";"):
Thanks for trying it Joanie. Here's some answers: 1/ Yes, this should be easy to do. The order you define the text attributes in the settings.enabledTextAttributes string can be the order they are spoken. I'll work that into a new patch. 2 & 3/ Yes, this is doable. You would override the outputCharAttributes() method in your application script to do this. See the one in default.py for how it turns a weight > 400 into "bold". 4/ Yup. I'll add that into the new patch too. gaim.py: Looks like it's text attributes don't have a ":" in the middle. I'll bullet-proff this in the textAttrsToDictionary() method in the new patch. New patch to come.
Created attachment 76780 [details] [review] Revised patch based on user feedback. Revised patch makes the following changes: 1/ Speaks the text attributes in the order they were given in the settings.enabledTextAttributes string. 2/ Adds "strikethrough" to the pronunciation dictionary. 3/ Adds a bit of bullet proofing to the textAttrsToDictionary() method to check if there was a ":" in the <key>:<value>; text attribute sub-string. Joanie, gaim seems to be working fine for me. This is with gaim 2.0.0beta3.1 on Ubuntu Edgy. For your gaim crash, was it possible that you had a settings.enabledTextAttributes string in your ~/.orca/user-settings.py file where one (or more) of the key/value pairs was not separated by a ":"? If so, then I think this should no longer crash, and should hopefully just skip this malformed attribute.
When I use the revised patch in StarOffice, I now get a key error: Traceback (most recent call last):
+ Trace 87345
self.outputCharAttributes(userAttrList, attributes)
attribute = attributes[key]
Regarding Gaim, I don't *believe* so: orca.settings.enabledTextAttributes = "size:; family-name:; weight:; underline:; justification:; style:; indent:;" But for good measure, I commented that line out and restarted Orca. Either way I get the same error: Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/orca/input_event.py", line 178, in processInputEvent consumed = self._function(script, inputEvent) File "/usr/lib/python2.4/site-packages/orca/default.py", line 2586, in readCharAttributes [defUser, defDict] = self.textAttrsToDictionary(defAttributes) File "/usr/lib/python2.4/site-packages/orca/default.py", line 2541, in textAttrsToDictionary if item[1] and item[1].endswith(";"): IndexError: list index out of range I just looked at the version of Gaim. (I've changed my repositories to get the Feisty Fawn packages as they become available) Seems I'm now using 2.0.0 beta 5. I just tried it on one of my feisty-free boxes. (i.e. has Gaim 2.0.0 beta 3.1) There I don't get the aforementioned error, but I do get a key error similar to what I reported for StarOffice, only the offending key seems to be "weight." Finally, something I forgot to mention last comment: Back with the first patch, I noticed that Orca reports the indent in Writer to be 0 even when I've pressed the increase indent button and indented the text. Is that something that is not getting exposed by OOo.?
Created attachment 76787 [details] [review] Further revised patch based on Joanie's feedback. Fix for the KeyError traceback. Joanie, I'm going to need a little help debugging the gaim problem you are seeing on Feisty. The problem is in textAttrsToDictionary() routine in default.py. Could you add the following two print lines: allTokens = str.split() ==> print "textAttrsToDictionary: allTokens: ", allTokens for i in range(0, len(allTokens)): item = allTokens[i].split(":") ==> print "textAttrsToDictionary: item: ", item if item[1] and item[1].endswith(";"): (without the arrows of course), and tell me what you get? Finally, I think you've found yet another Open Office bug. Could you file another bug against Orca for that problem, so that we can track it, and then I'll (probably) then open up another OOo bug againbst the real problem. You probably are also itching now to open up another rfe against Orca for a GUI for these new text attributes. That's okay too. ;-) Once we've got the gaim crash solved, I think these changes are ready to check in. Thanks.
Your fix for the KeyError traceback is confirmed. Thanks!! And thanks for the customizable order for attributes. That is VERY helpful! Regarding my itch for GUI support for this feature, ;-) please see bug #376515. Regarding yaoob ("yet another Open Office bug"), please see bug #376517. w.r.t the print lines in Gaim: ^[[CtextAttrsToDictionary: allTokens: ['left-margin:2;', 'right-margin:2;', 'indent:0;', 'invisible:false;', 'editable:true;', 'pixels-above-lines:0;', 'pixels-below-lines:5;', 'pixels-inside-wrap:0;', 'bg-full-height:false;', 'rise:0;', 'underline:none;', 'strikethrough:false;', 'size:10;', 'scale:1;', 'weight:400;', 'language:en-us;', 'family-name:DejaVu', 'Sans;', 'bg-color:65535,65535,65535;', 'fg-color:0,0,0;', 'bg-stipple:false;', 'fg-stipple:false;', 'wrap-mode:none;', 'direction:ltr;', 'justification:left;', 'stretch:normal;', 'variant:normal;', 'style:normal'] textAttrsToDictionary: item: ['left-margin', '2;'] textAttrsToDictionary: item: ['right-margin', '2;'] textAttrsToDictionary: item: ['indent', '0;'] textAttrsToDictionary: item: ['invisible', 'false;'] textAttrsToDictionary: item: ['editable', 'true;'] textAttrsToDictionary: item: ['pixels-above-lines', '0;'] textAttrsToDictionary: item: ['pixels-below-lines', '5;'] textAttrsToDictionary: item: ['pixels-inside-wrap', '0;'] textAttrsToDictionary: item: ['bg-full-height', 'false;'] textAttrsToDictionary: item: ['rise', '0;'] textAttrsToDictionary: item: ['underline', 'none;'] textAttrsToDictionary: item: ['strikethrough', 'false;'] textAttrsToDictionary: item: ['size', '10;'] textAttrsToDictionary: item: ['scale', '1;'] textAttrsToDictionary: item: ['weight', '400;'] textAttrsToDictionary: item: ['language', 'en-us;'] textAttrsToDictionary: item: ['family-name', 'DejaVu'] textAttrsToDictionary: item: ['Sans;'] HTH!
Thanks Joanie. I've checked in the last patch to make it easier to play around with this from now on. The gaim problem is apparently from a malformed part of the attributes: 'family-name:DejaVu', 'Sans;', This seems plain wrong to me. Tomorrow I'll try to come up with a workaround in the Orca code for you to try. Thanks for filing the other two bugs.
Created attachment 76796 [details] [review] Patch to work around the gaim malformed text attributes. Joanie, I think the attached patch (which I have NOT applied to CVS HEAD) will work around the gaim problem. Could you try it on your Fiesty Fawn system please. Thanks.
That patch solves the problem of the error (thanks!), but it causes the family-name info to not be announced at all. Would it therefore make sense to file a bug against Gaim regarding the malformed attribute?
If you would, that would be great. I suggest doing the first line of debug, i.e.: ['left-margin:2;', 'right-margin:2;', 'indent:0;', 'invisible:false;', 'editable:true;', 'pixels-above-lines:0;', 'pixels-below-lines:5;', 'pixels-inside-wrap:0;', 'bg-full-height:false;', 'rise:0;', 'underline:none;', 'strikethrough:false;', 'size:10;', 'scale:1;', 'weight:400;', 'language:en-us;', 'family-name:DejaVu', 'Sans;', 'bg-color:65535,65535,65535;', 'fg-color:0,0,0;', 'bg-stipple:false;', 'fg-stipple:false;', 'wrap-mode:none;', 'direction:ltr;', 'justification:left;', 'stretch:normal;', 'variant:normal;', 'style:normal'] for both versions of gaim. Hopefully that will show them that the family-name text attribute is being provided incorrectly in beta5. I've checked in that last patch to CVS HEAD. Closing as FIXED. For reference, can you please report back on the gaim bug number in a new comment to this bug. Thanks Joanie.
You know.... It turns out this bug is not a Gaim thing after all. I think it's a GNOME thing. Give this a try: 1. Launch Gedit. 2. Go to the Preferences dialog, Font & Colors, and select DejaVu Sans Mono Book as your editor font. 3. Type some text and press Insert F Here's what I get: ['left-margin:2;', 'right-margin:2;', 'indent:0;', 'invisible:false;', 'editable:true;', 'pixels-above-lines:0;', 'pixels-below-lines:0;', 'pixels-inside-wrap:0;', 'bg-full-height:false;', 'rise:0;', 'underline:none;', 'strikethrough:false;', 'size:12;', 'scale:1;', 'weight:400;', 'language:en-us;', 'family-name:DejaVu', 'Sans', 'Mono;', 'bg-color:65535,65535,65535;', 'fg-color:0,0,0;', 'bg-stipple:false;', 'fg-stipple:false;', 'wrap-mode:word;', 'direction:ltr;', 'justification:left;', 'stretch:normal;', 'variant:normal;', 'style:normal'] ['size:;', 'family-name:;', 'weight:400;', 'indent:0;', 'underline:none;', 'strikethrough:false;', 'justification:left;', 'style:normal;'] I can accomplish the same thing in Gaim 2.0.0 beta 3 by going to System, Preferences, Font and changing my fonts over to the DejaVu Sans family. I had forgotten that an earlier Feisty update nuked the Sans family thus necessitating a system-wide change. It had nothing to do with Gaim... My bad! So.... What should this be filed against?
Interesting. Okay, file it against gail please. Please assign it to Padraig.Obriain@Sun.COM Tell 'em the problem is around line 611 in .../gail/libgail-util/gailmisc.c: case ATK_TEXT_ATTR_FAMILY_NAME: value = g_strdup (pango_font_description_get_family (attrs->font)); break; The string returned by pango_font_description_get_family() needs to be munged into the correct format as the font name might have spaces in it. Maybe: case ATK_TEXT_ATTR_FAMILY_NAME: value = g_strdup_printf ("%s", pango_font_description_get_family (attrs->font)); break; Maybe. I dunno. I didn't try testing it. Thanks.