1734853 - PDF no longer uses anti-aliasing when zoomed out causing some symbols to not be visible

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect)

Description

[Kestrel]

Attachment: PDF equations missing equals and minus sign at 90% zoom

STR:

1. Start with gfx.webrender.software = true on Windows 10.
2. Open example PDF file containing equations.
3. 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.

Comment 1

[Kestrel]

Attachment: example.pdf

Comment 2

[Pascal Chevrel:pascalc (PTO until April 26)]

Lee could you triage this bug? Is that an important rendering issue to fix in beta and potentially in a dot release?

Comment 3

[Pascal Chevrel:pascalc (PTO until April 26)]

JIm, can you help getting this bug triaged? Thanks

Comment 4

[Lee Salzman [:lsalzman]]

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?

Comment 5

[Jonathan Kew [:jfkthame]]

(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.

Comment 7

[Lee Salzman [:lsalzman]]

Attachment: Bug 1734853 - Ensure unhinted fonts default to symmetric rendering in Skia. r?jfkthame

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.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/47bcc76a8237
Ensure unhinted fonts default to symmetric rendering in Skia. r=jfkthame

Comment 9

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/47bcc76a8237

Comment 10

[Gabi Cheta [:Gabi] Desktop QA]

Reproduced the issue with 95.0a1(2021-10-08), verified as fixed with 96.0a1 Nightly and 96.0b4 on Windows 10 x64.