1778770 - Text is missing with "WenQuanYi Zen Hei" font and vertical writing-mode

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[Sean Feng [:sefeng]]

Attachment: grid-bug.html

The attached testcase renders differently in Chrome (103.0.5060.53) vs Firefox.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of what dholbert sees

It looks the same to me, unless I'm missing something... Here's a screenshot of Firefox 104 Nightly (left) vs Chrome 105 dev (right).

Sean, can you clarify what's different? (Maybe you're testing an older Firefox or Chrome version? Or maybe there's some font/system-specific dependency that's required to reproduce the behavior-difference?)

Comment 3

[Sean Feng [:sefeng]]

Attachment: youliangxiazi.png

This is what I see. I am able to reproduce it with the latest Nightly (20220711094852) plus a clean profile. I don't know how to tell which font is being used. I am running Linux, should I list all the installed fonts?

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Sean Feng [:sefeng] from comment #3)

I don't know how to tell which font is being used. I am running Linux, should I list all the installed fonts?

You can right-click the text and choose "Inspect", and then in the right part of the 3-pane inspector layout, pick the "Fonts" section (possibly hidden in a dropdown arrow since it's near the end -- either "Fonts", or the dropdown arrow that contains it, will be to the right of the Layout | Computed | ... headings).

That will tell you what font is being used by the text you're inspecting. For me in Firefox, it's "Noto Serif CJK SC".

Comment 5

[Sean Feng [:sefeng]]

Ah thanks! Apparently I am using a font that targets chinese, it's called WenQuanYi Zen Hei.

Comment 6

[Daniel Holbert [:dholbert]]

Thanks. It looks like that font is easily available on Ubuntu via the fonts-wqy-zenhei debian package in the repos; I installed it with:

sudo apt install fonts-wqy-zenhei

and am playing around with local testcases which explicitly request that font by name.

It looks like specifically the part of your testcase with a vertical-rl writing-mode is broken.

And in my local modified variants of your testcase, it's broken in Chrome, too (the characters all pile on top of each other). So I think this might be a case where the font is lying and that produces browser-specific weirdness, and your testcase happens to have a hack that's sufficient to work around that weirdness in Chrome.

--> More testcases coming to provide more detail here.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1: same as original, but explicitly requesting the font by name

Here's the original testcase again, but now requesting the font by name.

(I've included a phrase in English which renders in the font's sans-serif-ish style for Latin characters if the font is found, vs. in monospace if you don't have the font.)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2: now with `text-align-last` style commented-out

Here's the testcase with text-align-last commented out. I think this is the hack that somehow was getting things to work in Chrome; with this removal, Chrome stacks the characters on top of each other in a jumbled mess.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: auto-sized content with this font in horizontal vs. vertical writing mode

This testcase demonstrates that Chrome and Firefox agree that the vertical-writing-mode sections have 0 height (which is a sign that the font is lying to us).

Comment 10

[Daniel Holbert [:dholbert]]

Firefox seems to decline-to-render-the-characters-at-all in testcase 1 through 3, which seems odd. But we do agree with Chrome in terms of sizing; and Chrome renders the characters but smooshes them all on top of each other due to them all occupying 0 height (in the absence of justification hacks), as shown if you view testcase 3 in Chrome.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screenshots of reduced testcases 1-3 in Firefox Nightly

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: screenshots of reduced testcases 1-3 in Chrome

Comment 13

[Daniel Holbert [:dholbert]]

Screenshots show that stuff's broken in Chrome, though the text does still paint (superimposed). So the main thing that we're arguably doing wrong here is not-painting-the-text.

jfkthame, do you have any insight here or cycles to take a look? (I wonder if maybe the font is reporting a zero-height paint area for the glyphs or something -- just like the apparently zero-height layout area -- and we're dutifully clipping to those bounds and not painting at all as a result?)

Comment 14

[Jonathan Kew [:jfkthame]]

I've seen issues with this font before..... ah, yes: bug 1534009. So this seems to be a longstanding issue with this font (and affects Chrome as well, per bug 1534009 comment 7 as well as your testing here), but we didn't dig deep enough to identify exactly what's happening.

Comment 15

[Jonathan Kew [:jfkthame]]

I downloaded a version of WenQuanYi-Zen-Hei.ttf that I found online (might not be exactly the version in the Ubuntu package, but whatever...) and confirmed that it's definitely a broken font. Trying to install it on macOS, I got a warning from Font Book.app, flagging "vmtx table usability" as a problem.

Trying to decompile the font with FontTools/TTX, I get a huge number of warnings about the vertical metrics table, of the form:

    WARNING: Glyph 'uni9FA9' has a huge advance height (65252); is it intentional or an (invalid) negative value?

before it finally throws an exception.

Installing the font, it actually seems to work reasonably for me in current Nightly; I think this is because since the fix in bug 1772189, we detect that the 'vmtx' table is bad, and ignore it and synthesize a standard advance instead. Chrome has more problems with it (and Safari refuses to use it, as it doesn't support user-installed fonts).

On Windows, it shows similar issues in Chrome and Edge; in Firefox, it works OK except that at certain sizes it has embedded bitmaps which we use, and they seem to be wrong (don't match the glyphs they're supposed to be).

Overall, it's just a badly-constructed font, and there's not much we can do about it.