Bugzilla – Full Text Bug Listing
| Summary: | StyledText getTextAttributes should always return font & colors | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Carolyn MacLeod <carolynmacleod4> | ||||
| Component: | SWT | Assignee: | Felipe Heidrich <eclipse.felipe> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Carolyn MacLeod <carolynmacleod4> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | skovatch | ||||
| Version: | 3.6 | Flags: | carolynmacleod4:
review+
skovatch: review+ |
||||
| Target Milestone: | 3.6 RC1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Scott, I remember you mentioned the screen reader on the Mac always need the foreground when it is different than the default value (that is why we use st.foreground instead of st.getForeground(), right). And what is the deal with the font, when does it need to be set ? Car, the fix you suggested is fine, but st.foreground and st.background are usally null, is that a problem ? > st.foreground and st.background are usally null, is that a problem
Would be better if they were real colors, actually.
(In reply to comment #2) > > st.foreground and st.background are usally null, is that a problem > Would be better if they were real colors, actually. Lets wait for SK's comments, I don't remember the whole story but we had to use st.foreground (st.getForeground() was wrong). (In reply to comment #3) > (In reply to comment #2) > > > st.foreground and st.background are usally null, is that a problem > > Would be better if they were real colors, actually. > > Lets wait for SK's comments, I don't remember the whole story but we had to use > st.foreground (st.getForeground() was wrong). This was a problem for runs of colored text where only one attribute was different from the default color. For example, if you selected text and made the foreground red, voiceover would say "<text> red on white". LIkewise, changing the background would give you "<text> black on yellow". Compare this against TextEdit, which just reports back the color that is different from the default. ("<text>, red", in the first example I gave). I think Carolyn's suggestion is a good one, but let me try it out here and see how it affects Cocoa. (In reply to comment #0) > if (!isListening(LineGetStyle) && st.renderer.styleCount == 0) { > e.textStyle = new TextStyle(st.getFont(), st.foreground, st.background); > e.start = 0; > e.end = contentLength; > return; > } This change fixes a subtle bug I just discovered in Cocoa. If a StyledText just has a string of plain text in it the font isn't being reported back by VoiceOver. It does in TextEdit.app, so this a good change. For the colors, maybe a better refinement would be to report the color in the TextStyle if it is different from the platform default (foreground or background) or different from the color set for the entire widget. Does IAccessibleText always expect a color? I think I can (sort of?) get away without specifying colors, but I do need a font. The relevant pieces of info from the spec are: "If an attribute is not specified and if the table shows that there is a default value, the default value should be assumed." the default background color is "transparent". the default foreground color is rgb(0,0,0). the default font is "no default". http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2/textattributes Created attachment 167356 [details]
patch
the first line of the patch is as Car suggested
the second line is other case where font could be null.
the idea is that the font is always set, the colors are only set when they differ from the default. This way we won't have the mac reading <i'm a mac> black on white.
Please let me know if the patch works on windows (car) and mac (scott). Sorry I don't have the software for testing (or if do, I do not know how to use it). Thank you. Looks good: Courier New, 10, normal (and no colors). So good to go for Windows. Thanks! Yes, this looks good for me, too, but it looks like the font is being read back too often. I don't think that's a result of this change, however. Go ahead and check it in. fixed in HEAD > 20100506 |
Screen readers don't want to assume (or figure out) what the default font & colors of an IAccessibleText are. So we need to return something for them, even if there are no styles. Something like this (did not test): if (!isListening(LineGetStyle) && st.renderer.styleCount == 0) { e.textStyle = new TextStyle(st.getFont(), st.foreground, st.background); e.start = 0; e.end = contentLength; return; }