Display model reports the wrong background color for text drawn in transparent mode #6467
Comments
|
Our displayModel currently only records chunks of text. If a fill or other non-text drawing action occurs, any existing text in its path is simply removed from the model. Thus the only background color info we have currently is from written text. I'm assuming you mean we should actually track other non-text drawing actions, including its background and foreground color, so that if a drawing action such as text has a transparent color we can inherit the background color from the existing chunk? This would be a large project. What is the impact of this (taking into account GDI becoming less used anyway)? |
|
I don't think you need anything that complex. Before you call the original GDI This impacts my ability to make Dragon NaturallySpeaking fully accessible as part of the DictationBridge project. Specifically, Dragon has some custom list views where I can't yet track the highlighted item because NVDA thinks the background color of all the text in the list view is white. |
|
If the background contained some kind of pattern or image then it may I will look into it at some point, though if you need it quicker I'll |
michaelDCurran
added
the
p4
|
Hi, @michaelDCurran, attached is the path that Matt should have sent as an official PR, but looks like it didn't make it through. I'm attaching in in case you'd like to review it and let Jamie or someone commit this. Thanks. |
…arent text drawing (#6844) * GDI hooks: In the TextOut and ExtTextOut functions, get the previous color at the provided X, Y coordinates before calling the original function, so we at least have a chance of knowing the correct background color if the text is being drawn in transparent mode. This is necessary to detect highlighted text in some parts of Dragon NaturallySpeaking. Fixes #6467
|
This was reverted in 338fb3e |
|
Some quick research seems to reveal that JAWS suffers from exactly the same problem. |
Resolves concerns about contributed PR: #9197 Workaround for #6467 # Summary of the issue: From #6467 (comment) > When text is written with the GDI background mode set to transparent, the display model doesn't necessary report the > correct background color for that text. In this case, the GDI hook should look at the actual background color before the > text is drawn, rather than using the result of GetBkColor. # Description of fix: There have been two prior attempts to fix this, both causing severe performance regressions. - #6844: "Display model: Try to provide the correct background color for transparent text drawing (issue #6467)" - #7440: "displayModel: second try at recording the actual background color for text when a transparant background color is set." This implementation merely exposes information about the potential transparency of the text background. Using the samples in https://github.com/nvaccess/testDisplayModel to test with various GDI dependent GUI APIs shows that the GetBkColor result can be: - Opaque and matches visual presentation(rawGDI) - Transparent and matches visual presentation: (mfcTest, GDItest) - Transparent and does not match visual presentation: (anecdotal) - The exposure of the transparency (via the alpha value on the colors.RGB class) will allow appModules or add-ons to customize NVDA's presentation as necessary. For users, there is no change in behavior by default. An option is introduced to the advanced settings panel to allow reporting of transparency in colors. The intention here is that developers will use this to identify where color reporting could be improved. The prior approach used the colorref high-level byte of a colorref struct. However, MSDN requires this byte be zero. This prior approach did not pass the colorref into any Windows API's, so it was safe. But to prevent this from being accidentally introduced in the future, a compatible alternative type is introduced and used instead. In order to stay compatible with python code interpreting this color value, a single bit is set if the color is considered transparent. # Testing: - Built applications from https://github.com/nvaccess/testDisplayModel - Tested with/without transparency reporting enabled (advanced panel) - Ensure color reporting is enabled in document formatting panel of NVDA settings - Use NVDA+Numpad 7 to switch to screen review - Use Numpad 7, Numpad 8, Numpad 9 to read the dialog Co-authored-by: Leonard de Ruijter <leonard@babbage.com>
|
There is a work around introduced in #12658. @mwcampbell, @LeonarddeR is there anything else expected here? Or is the workaround good enough to close this issue? |
|
The work around from #12658 is not really useful, as it only allows to know that the background is transparent which does not allow to track which option is highlighted. Determining what is highlighted in such cases will allow to solve some issues in Becky! Internet Mail and make menus in MCS Electronics IDE's accessible. This should remain open - while a complete fix is non trivial both JAWS and Window-eyes work better here, which means that this can be solved with additional GDI hooks. |
When text is written with the GDI background mode set to transparent, the display model doesn't necessary report the correct background color for that text. In this case, the GDI hook should look at the actual background color before the text is drawn, rather than using the result of
GetBkColor.The text was updated successfully, but these errors were encountered: