GNOME Bugzilla – Bug 363439
Use CSS/XSLT names for text attribute mappings from enums
Last modified: 2021-06-10 11:27:13 UTC
The API docs are explicit here: http://www.gnome.org/~billh/at-spi-idl/html/interfaceAccessibility_1_1Text.html#a18 | /"Other text attributes should choose their names and value semantics | in accordance with relevant standards such as CSS level 2"/ The bridge is exporting the wrong names when people use the AtkTextAttribut enum (see http://developer.gnome.org/doc/API/2.0/atk/AtkText.html) Most of them map well, with the unclear ones being underline/strikethrough, pixels-inside-wrap, full-height and wrap-mode. Need more info on rise, scale and fg/bg-stipple. Here are some specific notes: ATK_TEXT_ATTR_LEFT_MARGIN The pixel width of the left margin left-margin (current) -> margin-left (CSS) ATK_TEXT_ATTR_RIGHT_MARGIN The pixel width of the right margin right-margin (current) -> margin-right (CSS) ATK_TEXT_ATTR_INDENT The number of pixels that the text is indented indent (current) -> text-indent (CSS) ATK_TEXT_ATTR_INVISIBLE Either "true" or "false" indicating whether text is visible or not invisible (current) -> visibility: hidden (CSS) (in CSS can be visible|hidden|collapsed) ATK_TEXT_ATTR_EDITABLE Either "true" or "false" indicating whether text is editable or not Keep as is, no CSS property for this. ATK_TEXT_ATTR_PIXELS_ABOVE_LINES Pixels of blank space to leave above each newline-terminated line. pixels-above-lines (current) -> padding-top (CSS) ATK_TEXT_ATTR_PIXELS_BELOW_LINES Pixels of blank space to leave below each newline-terminated line. pixels-below-lines (current) -> padding-bottom (CSS) ATK_TEXT_ATTR_PIXELS_INSIDE_WRAP Pixels of blank space to leave between wrapped lines inside the same newline-terminated line (paragraph). Unforunately this is modeled differently via CSS line-height ATK_TEXT_ATTR_BG_FULL_HEIGHT "true" or "false" whether to make the background color for each character the height of the highest font used on the current line, or the height of the font used for the current character. No CSS ... XSLT? ATK_TEXT_ATTR_RISE Number of pixels that the characters are risen above the baseline Don't know ATK_TEXT_ATTR_UNDERLINE "none", "single", "double" or "low" ATK_TEXT_ATTR_STRIKETHROUGH "true" or "false" whether the text is strikethrough underline+strikethrough (current) -> text-decoration (CSS). Possible values are text-decoration are underline|overline|blink|none There is no double or low in CSS. Can we use XSLT for that? ATK_TEXT_ATTR_SIZE The size of the characters. size (current) -> font-size (CSS) ATK_TEXT_ATTR_SCALE The scale of the characters. The value is a string representation of a double What does this mean? ATK_TEXT_ATTR_WEIGHT The weight of the characters. weight (current) -> font-weight (CSS) ATK_TEXT_ATTR_LANGUAGE The language used language (current) -> lang (W3C xml) ATK_TEXT_ATTR_FAMILY_NAME The font family name family-name (current) -> font-family (CSS) ATK_TEXT_ATTR_BG_COLOR The background color. The value is an RGB value of the format "u,u,u" bg-color (current) -> background-color (CSS) ATK_TEXT_ATTR_FG_COLOR The foreground color. The value is an RGB value of the format "u,u,u" fg-color (current) -> color (CSS) ATK_TEXT_ATTR_BG_STIPPLE "true" if a GdkBitmap is set for stippling the background color. ATK_TEXT_ATTR_FG_STIPPLE "true" if a GdkBitmap is set for stippling the foreground color. Need to look these up, there are some funky CSS background properties like background-repeat or something. ATK_TEXT_ATTR_WRAP_MODE The wrap mode of the text, if any. Values are "none", "char" or "word" Don't know of CSS attribute for this. XSLT? ATK_TEXT_ATTR_DIRECTION The direction of the text, if set. Values are "none", "ltr" or "rtl" Stays as is ATK_TEXT_ATTR_JUSTIFICATION The justification of the text, if set. Values are "left", "right", "center" or "fill" justification (current) -> text-align (CSS) ATK_TEXT_ATTR_STRETCH The stretch of the text, if set. Values are "ultra_condensed", "extra_condensed", "condensed", "semi_condensed", "normal", "semi_expanded", "expanded", "extra_expanded" or "ultra_expanded" stretch (current) maps well to font-stretch (CSS) ATK_TEXT_ATTR_VARIANT The capitalization variant of the text, if set. Values are "normal" or "small_caps" variant (current) maps well to font-variant (CSS) ATK_TEXT_ATTR_STYLE The slant style of the text, if set. Values are "normal", "oblique" or "italic" style (current) -> font-style (CSS)
Should really be handled in ATK itself.
Updated documentation about AtkText::AtkTextAttribute http://developer.gnome.org/atk/stable/AtkText.html#AtkTextAttribute
ATK Hackfest Conclusions: We will move over to the IA2 names which are a superset of CSS http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2/textattributes
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 . PLEASE NOTE: If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add atk-maint@gnome.bugs to your watchlist at the bottom of https://bugzilla.gnome.org/userprefs.cgi?tab=email to keep watching atk bug reports in GNOME Bugzilla. Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]
During these days I have been looking to AtkAttributes and Joanie pointed me this bug. FWIW, enums are just a convenient way to identify an attribute on code, but doesn't define a attribute name per-se. This is done at atk_text_attribute_get_name. So I don't think that we would need to change AtkTextAttribute enum. That is a enum with all the defined text attributes (and defined as were concluded to be relevant). If we decide to change the name exposed for each text attribute, what we should do is reimplement the utility methods atk_text_attribute_get_name and atk_text_attribute_for_name. In that way, doing that, all the implementors that are already using those methods will change the attribute name emitted through the bridge at the same time, and consistent, so ATs like Orca would need to do the chance just once (well, right now, twice, but due bug https://bugzilla.mozilla.org/show_bug.cgi?id=938197)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of atk, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.