For vertical text in CJK languages the center baseline is between ideo top and ideo bottom. Those metrics are not equivalent to the center of ascent and descent, so I find the current definition of central to be ambiguous. Also, the practice of centering the Latin cap height between the ideo extremes is a better way to center Latin type for use in vertical CJK lines.

@macnmm For a font which lacks ideo/idtp baselines and is not a CJK font, say, perhaps it is a Thai font: should the ideographic-central baseline fall back to halfway between the ascent/descent or to cap-middle or to something else?

One possibility might be to define central as halfway between ideo and idtp if they exist, else coinciding with math if that exists, else halfway between the non-interoperable ascent/descent. (Or maybe throw in the cap-middle in that fallback list?)

@AmeliaBR @svgeesus Any idea what the interop restrictions on central might be from an SVG point of view? Judging from w3c/svgwg#618 and variants of that testcase at least, there seems to be not much interop...

On the web, I don't think we have consistent enough implementations to worry about slight pixel changes to a certain baseline alignment, so long as central still provides reasonably centered results.

However, since central was mostly recommended for ideographic alignment (e.g., as the default for vertical alignment), I'd prefer keeping it to the correct centered ideographic alignment when the font data is available, and only make changes as necessary to define a consistent fallback for when those baselines aren't specified.

(Unless there's a widespread issue with fonts that have those baselines specified, but poorly?)

I'm trying to understand the fallback issue.

The SVG 1.1 definition was:

This identifies a computed baseline that is at the center of the EM box. This baseline lies halfway between the text-before-edge and text-after-edge baselines.

If I understand the linked issue, the problem is that the “em box” itself isn't defined, except as the pair of ascent/descent metrics relative to the coordinate system origin, and different rendering engines use different font metrics to compute ascent/descent, and in broken fonts the various ascent/descent metrics aren't always consistent?

But the broken examples have basic alignment broken, too, so what are we really trying to optimize for by defining a consistent central alignment if everything else about the alignment is broken?

I think the existing "text-top", "text-bottom" and "center" should not be used for CJK, but rather use specific baselines "ideo", "idtp" and "ideographic-central" (or "ideo-center"). My reason being that existing implementations that depend on how they were defined as related to font ascent and descent should probably remain, but for CJK we try to get away from such ambiguous practices using Latin metrics or overriding them conditionally by font script.

As to what should happen when composing text in a CJK manner with fonts that lack these metrics, the heuristics would be to try to center a given height within the ideographic embox or within a height that equals the point size. For Latin scripts, the cap height is such a metric. For Thai, perhaps a derived cap height can be computed to serve the same purpose, or use a different metric that achieves the same (CJK oriented) balance in the mixed-script line.

Some background reading: https://docs.microsoft.com/en-us/typography/opentype/spec/baselinetags and https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6bsln.html

@macnmm Given that the central baseline is primarily used in CJK writing, and is most consistently defined if we use CJK metrics, and has wildly inconsistent behavior in current implementations, I think making central be the ideographic central baseline is a realistic possibility.

But even if we add a new value for the ideographic central, we can't fall back to "not defined" in CSS like the OT spec does, we have to fall down to something. Eliminating the “Else If this is a CJK font” condition in the OT algorithm @litherum links to so that we never hit “undefined” seems fine to me.

The CSS Working Group just discussed About the central baseline, and agreed to the following:

• RESOLVED: Define the central baseline so if the font has an explicit ideographic central baseline, use that. If not, use halfway between ideographic top and bottom. If that's missing, halfway between ascent and descent

OK, checked in edits that clarify the central baseline as being the ideographic central baseline. The definition in css-inline-3 now reads:

Corresponds to the ideographic central baseline, halfway between the ideographic-under and ideographic-over baselines.

and there are additional notes on what to do when these are missing in Appendix A.

@litherum @macnmm Let me know if you'd like any adjustments to these definitions?
(Also while you're staring at that Appendix, if you notice anything else wrong, please file an issue; I suspect it's overall kinda shaky.)

A follow-up question to @macnmm’s earlier comments is, do we want to suggest cap-middle as the fallback for non-CJK fonts (those that fall through to the undefined case in OpenType's calculation ) instead of halfway between the ascent/descent?

I'll also note #4707 ; @macnmm’s suggestion to use cap-middle as a fallback here might mean we practically don't need an additional baseline.

I don't think that this resolution is currently implementable on top of Core Text, without browsers parsing font files themselves (which they shouldn't have to). See https://developer.apple.com/documentation/coretext/ctfont-q6r

I'm also worried about compat. This resolution will affect ~all vertical text. This may not be a huge problem for the web, which doesn't have that much (percentage-wise) vertical text, but it is relevant for book readers, which are important use cases for WebKit.

@litherum Wrt compat, my understanding is that CJK fonts generally have their ascent/descent matching the ideographic top/bottom lines, so this would not result in a noticeable change for most of those cases. And definitely it's the correct behavior for vertical CJK, which I imagine constitutes most of your vertical content.

Wrt CoreText capabilities, I'm not seeing any API to get information about any baselines there, nevermind this one specifically. I think it's reasonable to ask Apple to extend CoreText to return baseline metrics? (Also seems a bit weird for Apple to go through the trouble of defining baseline metrics in AAT but not make them accessible through CoreText.)

tl;dr: the resolution is good, let’s proceed.

Yeah, I should have been more clear. Sorry about that.

A reasonable path forward here is to say “if your text library doesn’t expose the metrics, the CSS engine has to synthesize them instead.” And, since we can synthesize whatever values we want, we can synthesize the values that happen to cause no behavior change.

That being said, I do think there’s a reasonable argument to be made that the behavior change proposed in this thread would be a progression, rather than a regression, so the statement I made about compat isn’t particularly relevant. It’s likely that halfway between the ideographic top and ideographic bottom will be better than halfway between the ascent and descent, and it’s likely that ideographic central will be better yet.

(Of course, all this is modulo the engine’s freedom to ignore/fix-up any data we see in the font that doesn’t look reasonable. So even if the baselines are present, if they’re crazy we can just ignore them, or just pretend they are set to something better. We do this already for existing metrics, and these new ones should be no different. Philosophically, it’s the engine’s job to make things look good, regardless of whether or not the data in the fonts is bogus/missing or not.)

Therefore, that was a long way of saying that we should move forward with this resolution, with the above caveats. I was really just stating my concerns for the record; not actually objecting or resisting.

(Aside: In Core Text, the baselines in the font are used/observable if you use the CT line-layout facilities which automatically handle this baseline stuff. WebKit can’t use that API though, since CSS defines its own line layout algorithms. So we instead use the lower-level API, which doesn’t happen to expose a getter for this stuff. The Core Text team is aware of and sympathetic to CSS’s needs here.)