1803999 - CSS ic unit becomes extremely large in vertical writing-mode

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect)

Description

[nanto_vi (TOYAMA Nao)]

Attachment: 20221205-ic-in-vertical.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

1. View https://jsfiddle.net/e5hy0L9a/
   There are two 1ic x 1ic square. The first square is in horizontal writing-mode and The second square is in vertical writing-mode.

Actual results:

The second square is 640x larger than the first square.

Expected results:

The first square and the second square are the same size.

Comment 1

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Attachment: Screenshot on Nightly 2022-12-14.png

I failed to reproduce this issue on Nightly.

Jonathan, ic [1] unit is measured against the font. I wonder if this bug is related to font?

[1] https://drafts.csswg.org/css-values/#ic

Comment 2

[Jonathan Kew [:jfkthame]]

Yeah, that's strange.... probably related to the specific font in some way. So to reproduce/investigate, we'll need to know what specific font is being used to measure the unit.

Toyama-san, if you add a no-break space character ( ) into each of the paragraphs of your example, and then check the Fonts panel (maybe titled "フォント"? I'm not sure) in the Inspector for each of the blue squares, what font does it report is being used?

Comment 3

[nanto_vi (TOYAMA Nao)]

Meiryo font is used in my environment. I find some fonts reproduce this issue and others don't.

Fonts that reproduces this issue:

• Meiryo (1ic = 10240px)
• Yu Mincho (1ic = 10240px)
• Yu Gothic (1ic = 10240px)
• MS Mincho (1ic = 81920px)
• MS Gothic (1ic = 81920px)
• SimSun (1ic = 81920px)
• Microsoft YaHei (1ic = 10240px)
• Microsoft JhengHei (1ic = 10240px)
• Malgun Gothic (1ic = 10880px)

Fonts that works as expected (1ic = 16px):

• Arial
• Times New Roman
• Courier New
• Microsoft Sans Serif
• Segoe UI
• Noto Sans
• Noto Serif

Comment 4

[Jonathan Kew [:jfkthame]]

Thank you; I can confirm I see the same bad result when trying one of those fonts. Presumably these are all fonts that include vertical metrics (and we're misinterpreting them in some way), whereas the fonts that work correctly don't have vertical metrics and so we synthesize them.

Moving this to Graphics:Text; the actual bug here is likely to be on the graphics side of things, interpreting the font resources, rather than in the CSS engine, which is just working with the (bad) values it gets from gfx.

Comment 5

[Jonathan Kew [:jfkthame]]

This is simply a mistaken conversion in the code here that sets up the ic unit for fonts that actually provide vertical glyph metrics, and support the water-ideograph character. (Other fonts end up using a fallback that doesn't hit the bug; hence this manifests only with "better" CJK fonts.)

The advance value we get from the shaper isn't in FUnits, it is a fixed-point advance for the scaled font. So the conversion to a gfxFloat for the metrics record is incorrect; it should be advance / 65536.0 to convert 16.16 fixed-point to float.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1803999 - Fix incorrect glyph advance conversion when setting up the 'ic' unit in GetVerticalMetrics. r=#gfx-reviewers

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8e2b1cbec006
Fix incorrect glyph advance conversion when setting up the 'ic' unit in GetVerticalMetrics. r=gfx-reviewers,lsalzman

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/8e2b1cbec006

Comment 9

[Timea Zsoldos [:tzsoldos], Desktop QA]

I have reproduced this issue using Firefox 109.0a1 (2022.12.04) on Win 10 x64, with Microsoft YaHei font.
I can confirm this issue is fixed, I verified using Firefox 110.0b9 on Win 10 x64.