[css-inline-3] Propose N/A value for em-top and em-bottom baselines

[kojiishi]

A follow up for #5312.

I'd like to propose using some N/A value (undefined in JavaScript, 0, or something else) for when the font doesn't have none of top, bottom, nor central of em-box.

Imagine a case:

const ctx = canvas.getContext('2d');
ctx.font = '20px Arial, CJKFont';
const metrics = ctx.measureText('日本語');

I think the expectation is to get em-box from the CJKFont.

Another example:

ctx.font = '20px Arial, CJKFont1, CJKFont2';

and CJKFont1 doesn't have BASE table but CJKFont2 has. Is the expectation to synthesize from Arial, synthesize from CJKFont1, or use BASE table from CJKFont2?

Because this is JavaScript API, if author knows that the first available font doesn't have accurate metrics, they can choose options such as synthesize from ascent/descent of the first available font, fallback to the next font, or something else. If browser returns possibly inaccurate synthesized values, authors doesn't have a good way to determine how much they can trust it.

WDYT?

/cc @jfkthame @litherum @fantasai @annevk @yiyix @macnmm

[kojiishi]

Tests for cases I briefly explained in the meeting on Windows:

The blue lines are baseline/ascent/descent (for Windows), red lines are em-top/em-bottom computed by the currently proposed logic in #5312:

p = 1em/(ascent - descent);
return (ascent*p, descent*p);

MSGothic is an early '90s font, has small internal leading, similar to Latin fonts. Meiryo, our current default Japanese font, has modern metrics (big internal leading) but doesn't have the BASE table yet. Yu is newer than Meiryo, has similar metrics as Meiryo, but it has the BASE table, so we don't have to worry about.

[annevk]

This seems possible in theory, but if sites rely on this returning a number today it might break things, no? Are browsers prepared to ship a breaking change?

It also seems better to move this discussion to whatwg/html. (Transferring issues doesn't go across organizations unfortunately.)

[jfkthame]

In my mind, at least, em-top and em-bottom are expected to provide the alignment positions used by Canvas2d textBaseline=top and bottom, so they can't be undefined or zero or whatever.

The html spec calls for "the top [or bottom, respectively] of the em square", and its accompanying illustration makes it clear they're expected to be 1em apart, even if that means they're inside the font's ascent/descent. So there needs to be some definition of what they mean even for a Latin font with no BASE table.

(I suspect most use cases would be better served by ascent and descent options, but the top and bottom values are long-established. They're not very interoperable at the moment because of the lack of a clear definition, which I'm hoping this will provide.)

[kojiishi]

@annevk:

Are browsers prepared to ship a breaking change?

Blink once implemented, but hasn't shipped this property yet due to these concerns.

It also seems better to move this discussion to whatwg/html.

Agreed, but can you tell me a bit more details how? I think there are two sides of this discussion. In #5312 logic, when the first "if" clause succeeds:

if iTop | iBottom | iCentral:

I'm fine to use this logic, and IIUC @jfkthame as well. If @litherum is fine too, we can define this part in CSS. This logic also matches OpenType ideographic em-box, so I hope OpenType font experts would agree too. /cc @astearns @macnmm @kenlunde

The problem is in the "else" clause. OpenType ideographic em-box defines this case as "ideoEmBox cannot be determined for this font". HTML would want to know this condition -- when the logic hit this "else" clause -- then it can decide to return a synthesized value, undefined, 0 or negative value.

So I'm wondering, maybe it is CSS to first agree that this value can be determined only under certain conditions. Is my understanding correct, or is it better first discuss at html? In Blink, I'm talking to @yiyix, we're happy to follow however is easier for people, a guidance on how to proceed this is appreciated.

@jfkthame:

In my mind, at least, em-top and em-bottom are expected to provide the alignment positions used by Canvas2d textBaseline=top and bottom, so they can't be undefined or zero or whatever.

Blink uses text-over and text-under for them today, which is, as you said, not very interoperable unfortunately. I don't have a good idea how to make them interoperable, but we have a proposal to give authors an opportunity to opt-in to interoperable font metrics in #4792 (note, this comment indicates that at least one of CSS members does not want to make ascent/descent interoperable, so no consensus yet.)

BTW, Canvas2d textBaseline not well-defined is a very good point. I've been discussing with @yiyix about how to map these Canvas values to the concepts in CSS. Maybe this is a good opportunity to define them better?

[kojiishi]

The last part of my comment above was incorrect, sorry. Correction:

@jfkthame:

In my mind, at least, em-top and em-bottom are expected to provide the alignment positions used by Canvas2d textBaseline=top and bottom, so they can't be undefined or zero or whatever.

Blink uses text-over and text-under for them today

Blink used to use text-over and text-under, switched to the logic you suggested in whatwg/html#2470, but WebKit did not agree, so we're still not interoperable. I need to talk to our Canvas team on what we want to do with textBaseline, but I want to make sure em-top and em-bottom are good values and all impls agree before shipping them.

I don't know whether WebKit is happy with this new logic or not, but this new logic does not work well for Blink.

[macnmm]

I intended the ideo and icft and icfb baselines to be defined in all fonts, not just CJK fonts. The purpose of adding these metrics is for the font designer to inform the process of font metrics balancing with mixed-script typesetting and composite font creation. If we had the "optimal" CJK embox balance for all fonts, we could set the correct origin of each run way better than today (when setting text in a CJK embox-centric manner like the embox center baseline).
Lacking these metrics, we have to use heuristics to calculate the CJK embox for these fonts.
As long as this proposal doesn't discourage the above, and it is useful for engines to know whether the metrics exist or whether it has to use a heuristic, great

[annevk]

@kojiishi sorry for not replying to your earlier inquiry. CSS does indeed define the relevant primitives here and those should be updated so that HTML has something to "call" and branch on the result to the appropriate thing. I think it would still be good to have a corresponding HTML issue filed so people following that repository are informed that a change is expected to be made to this API.

[macnmm]

Another point that comes to mind is that each font can define baselines to suggest a "best positioning" for glyphs (scripts) not included in the font -- a Latin font including CJK baselines would suggest how that Latin glyph designer envisioned it should sit next to CJK fonts on a CJK baseline (or centerline, etc). Mixed fonts on the same line present this problem anyway, so comparing their baselines (metrics lines) can illustrate the issue and suggest solutions.