textBaseline not interoperable

[annevk]

Apparently textBaseline is not interoperable. Firefox implements the HTML Standard, but at least Chrome and Safari do not.

Bugs:

• https://bugzilla.mozilla.org/show_bug.cgi?id=737852
• https://bugs.chromium.org/p/chromium/issues/detail?id=607053

Questions:

• What is the desirable behavior?
• Do we have web-platform-tests?

[gmurray81]

Last I remember all of them behaved consistently (though perhaps incorrectly) except FF

[gmurray81]

If I had to guess, some of the browsers may have informally settled on max ascent or something of it's ilk since it's a more useful metric in terms of bounding boxes. If someone wants to position some text by the top left of its bounding box so that all the ascenders are below a certain y coordinate then the top of the em square isn't entirely useful compared to the outer bounding.

I'm not sure if that's what the non-FF browsers are doing, but perhaps that's the motivation, however not per spec.

[kojiishi]

Interesting, I didn't know about this spec but this looks like related to something I've been investigating, not for canvas but for some fonts work.

Could you mind if I ask questions to the spec in this issue, or is there any other places I should ask?

1. It says top/middle/bottom of the em square, but I couldn't find the em square defined. Could someone point it to me? Is it equivalent to OpenType ideographic em-box?
2. If so, the algorithm has two problems, where the "If this is a CJK font" is not defined, and the result is undetermined if that fails. What should impl do?
3. I suppose hanging/alphabetic/ideographic corresponds to hang/romn/ideo terminology in OpenType BASE table. How could we compute these values when the font doesn't have these values?
4. Not too important but the naming issue is here too, I don't know how to do this if it's already widely implemented. Just strange to native speakers, no real harm.

[kojiishi]

I hope @jfkthame can help us to clarify this better in the spec?

IIUC Gecko uses sTypoAscender and sTypoDescender more than Blink does, so I suspect bottom is where sTypoDescender points to, rather than OpenType ideographic em-box, but just a guess.

top is less clear to me. OpenType recommends the sum of sTypoAscender and sTypoDescender to be 1em, but this is hardly true, so the top could either be sTypoDescender + font-size, if we prioritize em square be 1em in CSS sense, or sTypoAscender, if we prioritize font metrics.

FYI, I made a list of metrics of Windows fonts. In most non-CJK fonts, the sum of sTypoAscender and sTypoDescender is not UnitsPerEm.

[KrasnayaPloshchad]

IIUC Gecko uses sTypoAscender and sTypoDescender more than Blink does, so I suspect bottom is where sTypoDescender points to,

I found this is a long tradition of vertical CJK layout before digital typography, during the period of movable type, Chinese characters usually aligned with descenders especially in books and newspapers printed with vertical layout, in this file you will see the samples.

[jfkthame]

1. It says top/middle/bottom of the em square, but I couldn't find the em square defined. Could someone point it to me? Is it equivalent to OpenType ideographic em-box?

I don't think the spec was ever intending to refer to the "ideographic em-box" here. The concept of the "em square" is mentioned, for example, in https://www.microsoft.com/typography/otspec/TTCH01.htm, where it is "an imaginary square that is used to size and align glyphs", and provides the FUnit coordinate system used for glyph outlines, etc.

The total height and width of the em square will thus always be UnitsPerEm font units, or 1em exactly. But (as https://www.microsoft.com/typography/otspec/TTCH01.htm explicitly mentions) "portions of glyphs may extend outside the em square".

[kojiishi]

Thank you @jfkthame.

The total height and width of the em square will thus always be UnitsPerEm font units, or 1em exactly.

I'm good with that definition, just wish it be defined somewhere. To me, the concept of the "em square" outside the CJK looks ambiguous.

And does Gecko use sTypoDescender for the bottom of "em square"? Using this definition helps me to solve my issue in text-decorations, but not entirely sure that is what Gecko does, nor is good definition for outside CJK.

/cc @r12a possible i18n topic.

[jfkthame]

And does Gecko use sTypoDescender for the bottom of "em square"?

No, I don't believe so. That could have the effect of putting the top of the em-square unexpectedly low in cases where the font has long descenders. The sTypo* metrics often sum to considerably more than 1em, in which case we would assume that they project both above and below the em-square; we don't stick the em-square to just one edge of the sTypo* bounds.

Without going back and reading the code, what I think I recall is that we compute emAscent and emDescent values such that their ratio matches that of sTypoAscender:sTypoDescender, but normalized so that emAscent+emDescent = 1em. These emAscent/emDescent values then determine where "top" and "bottom" of the em-square occur in relation to the baseline.

[kojiishi]

Oh, I see, that sounds like a brilliant idea. As I recall my tests on Latin fonts, that might work good.

Not rushing at all but could you mind to confirm the code when you got a chance, so that we can discuss spec'ing the algorithm into the spec?

I think we should try to confirm a couple of more points:

1. Great if we can get confirmation that this definition matches to the design intention of the textBaseline. @annevk do you know who designed this?
2. I think this definition should work great for Latin and CJK, but not sure for other scripts, especially for tall scripts. @r12a any ideas?
3. Maybe after these, but how do we get consensus from other impls?
4. Maybe ping other WGs? It's not great if later other specs want different definitions?

For Blink, I think we can match if these are resolved, for top/middle/bottom.

For hanging/ideographic, we need to support BASE table first, and need definition on when the BASE table is missing, but we don't have ETA for the BASE support at this moment.

[annevk]

This took me a while, but it was added in 96b4346. The corresponding mailing list thread is https://lists.w3.org/Archives/Public/public-whatwg-archive/2008May/thread.html#msg36.

[kojiishi]

Thank you @annevk ...oh, 10 years old? If that's old, I guess I'll need to look into web compat too before diving into the change. I thought this is a new spec.

Either way, I think this is a good opportunity to seek for interests in more interoperable font metrics, and Jonathan's info is very helpful.

[annevk]

Yeah, as far as I can tell this was part of the initial wave of font/text APIs for canvas, so there definitely can be compatibility issues.

[adamschwartz]

Thank you all so much for working on this.

When I built https://github.com/cloudflare-apps/smart-underline, I ran into this issue and ultimately went with reading pixel data from a canvas after drawing an “I” and “g” to work around it.

Along the way, I built this test suite of sorts:
https://cdn.rawgit.com/adamschwartz/typography.js/master/index.html

I hope it can be helpful in some way with the work being done here. 😄

[davidqz]

Hello, I'm on the canvas team for chrome. Thanks for everyone that have contributed to this long discussion. We just submitted a change to make top, middle and bottom alignment to finally match the spec and use the EM square measurement instead of the font ascender/descender. This change matches what Firefox already does.

https://chromium-review.googlesource.com/c/chromium/src/+/1194494

[annevk]

@davidqz great, thanks! I see that PR also touched web-platform-tests so I think we can close this then.