Synthesize vertical font metrics/baselines from the horizontal metrics/baselines
Categories
(Core :: Layout: Block and Inline, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox153 | --- | fixed |
People
(Reporter: sajidanwar, Assigned: sajidanwar)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Bug 2014156 introduced HarfBuzz's font baseline synthesis for both horizontal and vertical fonts. But during my testing, I found that using HarfBuzz for synthesis of vertical baselines was insufficient for a couple reasons:
-
HarfBuzz's synthesis of vertical baselines for normally horizontal glyphs loses the horizontal baseline information, making it impossible to get sane alignment for some baselines. For example, vertical synthesis always returns an alphabetic baseline of zero (which will almost certainly be wrong since vertical font metrics use a centered ascent/descent) and a hanging baseline of 0.6em. These defaults make it so that horizontal glyphs can never actually align to the alphabetic, hanging, or x-middle baselines in vertical writing modes.
-
Some common fonts are wildly misbehaved w.r.t. their vertical baselines, rendering the synthesized values meaningless. For example, the Noto Sans CJK SC font has a defined ideographic-under (
ideoin OpenType) baseline value of 0. Per the CSS Inline 3 specification, the synthesized ideographic-under is 1em away at 1000, and the synthesized central is halfway at 500. But these are nonsensical given the font's vertical ascent/descent is 500/-500.
As a result, the most compelling option seems to be instead to synthesize vertical baselines from horizontal ones, by mapping the horizontal baselines within the horizontal maximum height to the equivalent location in the horizontal maximum height. Essentially, v_base = ((h_base + h_descent) / h_height * v_height - v_descent.
| Assignee | ||
Comment 1•1 month ago
|
||
Oh, for sensible x-middle baselines (for alignment-baseline) and cap baselines (for text-box-edge), these metrics should also be synthesized from the horizontal metrics since they only make sense anyway in the context of horizontal glyphs.
| Assignee | ||
Comment 2•1 month ago
|
||
Uses the font's existing horizontal metrics and baselines to synthesize the
vertical ones. Additionally updates multiple reftests whose expectations or
assertions were implicitly dependent on specific vertical font values when they
didn't need to be. Specifically:
-
Updates the misleading expectation for css/css-writing-modes/full-width-003.html.
This reftest checks for support of thetext-combine-upright: digits <number>
property by asserting a mismatch between the test and the reference, where the
test usestext-combine-uprightand the mismatch reference does not. Browsers
with no support for thedigitssyntax are supposed to fail as the rendering
should be the same. Firefox Linux was passing despite not supportingdigits
due to slight rendering differences caused by a discrepancy in vertical font
metrics synthesis. The improved synthesis in Bug 1403440 removes this
discrepancy, now causing the reftest to (correctly) fail. -
Updates some existing canvas veritical writing mode reftests. Previously, the
reference renderings for these tests were rotated horizontal canvas text using
default fonts. Now, these tests are referenced against HTML text in vertical
writing modes using the Ahem font for consistent layout and baseline
calculations. See https://github.com/whatwg/html/issues/11449 for ongoing
discussions around formal specifications for canvas writing modes.
Updated•1 month ago
|
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/59986 for changes under testing/web-platform/tests
Comment 6•1 day ago
|
||
| bugherder | ||
Upstream PR merged by moz-wptsync-bot
Description
•