PDF no longer uses anti-aliasing when zoomed out causing some symbols to not be visible
Categories
(Core :: Graphics: Text, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox-esr91 | --- | unaffected |
firefox92 | --- | unaffected |
firefox93 | --- | wontfix |
firefox94 | --- | wontfix |
firefox95 | --- | verified |
People
(Reporter: ke5trel, Assigned: lsalzman)
References
(Depends on 1 open bug, Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(3 files)
STR:
- Start with
gfx.webrender.software = true
on Windows 10. - Open example PDF file containing equations.
- Zoom out to 90%.
Rendering lacks anti-aliasing causing equals sign and minus sign in equations to disappear.
Occurs on Windows 10 with SW-WR but not HW-WR. Does not occur on Linux.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=15ab4f640c683a03a252e343554b97fca60d5127&tochange=cf996546dac5e0592b6537a0cd55c5e25f3d9dff
Regressed by Bug 1711553.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Lee could you triage this bug? Is that an important rendering issue to fix in beta and potentially in a dot release?
Comment 3•3 years ago
|
||
JIm, can you help getting this bug triaged? Thanks
Assignee | ||
Comment 4•3 years ago
|
||
It's not that AA isn't happening, because you can clearly see the color-fringing from ClearType in either circumstance, but for some reason certain glyphs are dropping out. Jonathan, could this maybe be related to incorrect selection of natural vs natural symmetric rendering modes (resulting from my patch that tried to avoid calling GetRecommendedRenderingMode)? Or at least, a plausible explanation of why the drop-out of certain glyphs occurs?
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Comment 5•3 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #4)
It's not that AA isn't happening, because you can clearly see the color-fringing from ClearType in either circumstance, but for some reason certain glyphs are dropping out. Jonathan, could this maybe be related to incorrect selection of natural vs natural symmetric rendering modes (resulting from my patch that tried to avoid calling GetRecommendedRenderingMode)? Or at least, a plausible explanation of why the drop-out of certain glyphs occurs?
I'm not sure exactly what modes are involved, but the lower sample in the image clearly has very different hinting behavior going on -- it looks like it is aggressively grid-fitting in the y-axis, whereas the upper sample doesn't grid-fit, it only antialiases.
The y-axis grid-fitting would be responsible for the very bumpy-looking text, where e.g. lowercase letters with a rounded top like 'o' or 'e' stick up higher than flat-topped letters like 'x'. It's probably also responsible for the dropouts (and for the opposite problem, overly-bold horizontal strokes making e.g. the serif "feet" of 'n' and 'm' look far too chunky); this would be a result of the top and bottom edges of the stroke being independently grid-fitted, so that what should be a near-hairline may snap to a whole pixel or alternatively collapse to nothing.
So yes, seems like this could well be the difference between natural vs natural-symmetric modes.
Assignee | ||
Comment 7•3 years ago
|
||
It would seem that the Microsoft implementation of GetRecommendedRenderingMode
is somewhat different from the WINE version and has further behavior of also
checking whether the font is hinted in the fallback case to determine if it
should truly default to natural rendering instead of natural symmetric. This
adds the hinting check to decide between natural or natural symmetric in that
fallback case.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 9•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Reproduced the issue with 95.0a1(2021-10-08), verified as fixed with 96.0a1 Nightly and 96.0b4 on Windows 10 x64.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•