1850314 - Broken chinese font rendering in Nightly PDF preview

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect)

Description

[yoyo930021]

Attachment: expected result

Attach (recommended) or Link to PDF file here:

Steps to reproduce the problem:

1. https://ga.ntu.edu.tw/upload/cont_att/4878aacb-3114-437b-9cee-443572b16f26.pdf

What is the expected behavior? (add screenshot)
The font rendering is correct.

What went wrong? (add screenshot)
The font rendering is broken.

Comment 1

[yoyo930021]

Attachment: actual result

Comment 2

[yoyo930021]

I will happend in any 標楷體 font pdf.
https://zh.wikipedia.org/zh-tw/%E6%A8%99%E6%A5%B7%E9%AB%94

This font is very popular in Taiwan

Comment 3

[yoyo930021]

mozregreasion:

2023-08-28T14:43:51.666000: DEBUG : Found commit message:
Bug 1847959 - Update OTS to pick up https://github.com/khaledhosny/ots/pull/264, to avoid clipping glyphs with incorrect bbox values. r=gfx-reviewers,lsalzman

Differential Revision: https://phabricator.services.mozilla.com/D186476

Comment 4

[Alice0775 White]

yoyo930021 ,
Would you please attach the contents of your "about:support"? Use the "Copy text to clipboard" button and paste that text as an attachment to this bug.

Comment 5

[yoyo930021]

Attachment: about:support

Comment 6

[yoyo930021]

Attachment: about:support.json

Comment 7

[yoyo930021]

(In reply to Alice0775 White from comment #4)

yoyo930021 ,
Would you please attach the contents of your "about:support"? Use the "Copy text to clipboard" button and paste that text as an attachment to this bug.

I add it, thanks.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

:jfkthame, since you are the author of the regressor, bug 1847959, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 9

[Hani Yacoub, Desktop QA]

Managed to reproduce the issue on macOS 11.6.
The issue isn't reproducible on Win10.

Comment 10

[Emilio Cobos Álvarez [:emilio]]

It's unclear if this is reproducible on beta where we don't provide so strict OTS validation (gfx.downloadable_fonts.otl_validation).

Hani, can you check if flipping gfx.downloadable_fonts.otl_validation and restarting fixes this on macOS?

Comment 11

[Jonathan Kew [:jfkthame]]

OTL validation isn't relevant to this; the issue is about the actual glyph data and instructions. It reproduces with or without gfx.downloadable_fonts.otl_validation enabled.

It does not reproduce for me on either Windows or Linux; only on macOS.

The font involved here is what FreeType refers to as a "tricky" font, which relies on complex TrueType instructions to shift and scale sub-glyph components. This means that if a system tries to render the glyph outlines without applying the "hinting" instructions, some glyphs look quite scrambled because their components have not been adjusted as required.

MacOS doesn't normally apply TrueType instructions these days, relying on its antialiasing instead. What I suspect is happening here is that the macOS font rasterizer specifically recognizes these "tricky" fonts (like FreeType) and knows that it does need to apply their instructions. But whereas FreeType recognizes them based on the font name, I'm guessing macOS is (also?) using some other criteria such as the glyf table checksum to decide whether to special-case the font. So then when OTS corrects the bad bounding box data in some of the glyphs, the resource no longer matches macOS's list of "tricky" fonts, and just gets rendered "normally" (without applying instructions); hence, scrambled.

I note that if I take the font and simply decompile it with TTX and then re-compile, the resulting TTF file (which is not binary-identical to the original, as TTX will automatically recompute things like bounding boxes and checksums) shows similarly broken rendering in all browsers.

More recent versions of the font do not exhibit this behavior, but the PDF here was generated from an old version of MS Word (2007), probably running on an old version of Windows, and so the font resource that it embedded is this old "tricky" version.

I'll look into some possible mitigations here.

Comment 12

[yoyo930021]

Attachment: repro.pdf

Comment 13

[Irvin (MozTW)]

(In reply to yoyo930021 from comment #3)

mozregreasion:

2023-08-28T14:43:51.666000: DEBUG : Found commit message:
Bug 1847959 - Update OTS to pick up https://github.com/khaledhosny/ots/pull/264, to avoid clipping glyphs with incorrect bbox values. r=gfx-reviewers,lsalzman

Differential Revision: https://phabricator.services.mozilla.com/D186476

confirmed the same regression window with test file,

24:34.67 INFO: No more integration revisions, bisection finished.
24:34.67 INFO: Last good revision: b4d4ce5324846ca627149985464c21d1a63c9c17
24:34.67 INFO: First bad revision: d412b291820d7a24a94db9d8f082f4cb080cf225
24:34.67 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b4d4ce5324846ca627149985464c21d1a63c9c17&tochange=d412b291820d7a24a94db9d8f082f4cb080cf225

Comment 14

[Irvin (MozTW)]

The font is the default and second most common Traditional Chinese font that came with Windows since win 3.1 days, and is default font for all government and general officially docs. The Word version is also popular in organizations (in this case - the primary university) because it's the last few version prior to office 365 subscription model. So I think it would be very noticeable among users.

Comment 15

[Peter Pin-Guang Chen [:petercpg] (MozTW.org)]

Attachment: about:support

I can not reproduce this issue on Build 20230829211224 on Windows 11 (x64), both OS and Nightly are in native zh-TW version. Any configuration or  preferences might differ?

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to Peter Pin-Guang Chen [:petercpg] (MozTW.org) from comment #15)

I can not reproduce this issue on Build 20230829211224 on Windows 11 (x64),
both OS and Nightly are in native zh-TW version. Any configuration or
preferences might differ?

AFAICT this is only an issue on macOS, because of how it renders fonts without relying on TrueType hinting instructions (see comment 11). I suspect Windows always applies the TrueType instructions.

Comment 17

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1850314 - Don't do glyph bounding-box fixup for "tricky" fonts, because it may disrupt glyph rendering on macOS. r=#gfx-reviewers

Comment 18

[Jonathan Kew [:jfkthame]]

Here's a patch to OTS to make it skip the bounding-box fixup for these "tricky" legacy fonts, which avoids breaking the rendering.

I'll file an OTS issue upstream as well.

[edit: opened https://github.com/khaledhosny/ots/pull/266 to propose this change upstream]

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cdb5bfd06567
Don't do glyph bounding-box fixup for "tricky" fonts, because it may disrupt glyph rendering on macOS. r=gfx-reviewers,lsalzman

Comment 20

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/cdb5bfd06567

Comment 21

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox118 to wontfix.

For more information, please visit BugBot documentation.

Comment 22

[Jonathan Kew [:jfkthame]]

Comment on attachment 9350803 [details]
Bug 1850314 - Don't do glyph bounding-box fixup for "tricky" fonts, because it may disrupt glyph rendering on macOS. r=#gfx-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: Broken rendering of some old CJK fonts (probably on macOS only)
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: View the attached repro.pdf, and check rendering of the Chinese glyphs (e.g. the first character in the title; compare "actual" and "expected" screenshots)
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• String changes made/needed:
• Is Android affected?: No

Comment 23

[Donal Meehan [:dmeehan]]

Comment on attachment 9350803 [details]
Bug 1850314 - Don't do glyph bounding-box fixup for "tricky" fonts, because it may disrupt glyph rendering on macOS. r=#gfx-reviewers

Approved for 118.0b3

Comment 24

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/11aaf08123b9

Comment 25

[Hani Yacoub, Desktop QA]

Verified as fixed on macOS 11.6 and on macOS 10.15.