[css-inline-3] Define em-top and em-bottom baselines

[fantasai]

The Canvas API has several references into the metrics defined in

It also defines emHeightAscent and emHeightDescent but doesn't have a concrete definition for them. Talked with @jfkthame about what they might be defined as and currently thinking maybe we add in definitions for these for HTML to refer into, so all the related metrics are all defined in one place (even if CSS doesn't end up using this particular pair).

Proposed definition from me and @jfkthame is:

• if the ideographic-top + ideographic-bottom or ideographic-central baselines are defined by the font, emHeightAscent is 0.5em above the ideographic-central and emHeightDescent is 0.5em below. (This will normally make ideographic-top = emHeightAscent and ideographic-bottom = emHeightDescent, but if ideographic-top and ideographic-bottom are not 1em apart it will normalize the distance to 1em)
• if none of the ideographic baselines are defined, use the ascent and descent normalized proportionally so they add up to 1em

Roughly in code, something like:

if iTop | iBottom | iCentral:
  /* rules of font format considers at least one of these defined */
  if iBottom && !iTop:
    iTop = iBottom + 1em;
  if iTop && !iBottom:
    iBottom = iTop - 1em;
  if !iCentral:
    iCentral = (iTop + iBottom)/2;

  return (iCentral + 0.5em, iCentral - 0.5em);
else:
  p = 1em/(ascent - descent);
  return (ascent*p, descent*p);

CC @annevk @yiyix

[kojiishi]

Thank you for working on this. A few questions:

• I think you mean iTop = HorizAxis.ideo and iBottom = HorizAxis.idtp? What is iCentral?
• ascent/descent are the ones defined in CSS?
• It looks like the definition is similar but slightly modified from OpenType Ideographic Em-Box. Is this intentional?

cc @macnmm @litherum

[fantasai]

I think you mean iTop = HorizAxis.ideo and iBottom = HorizAxis.idtp? What is iCentral

i* corresponds to ideographic-* defined in https://drafts.csswg.org/css-inline-3/#baseline-types

ascent/descent are the ones defined in CSS?

I'm unsure, but I guess so.

It looks like the definition is similar but slightly modified from OpenType Ideographic Em-Box. Is this intentional?

Yes. jfkthame says particular metric is should be normalized to 1em.

(Please note this is not a metric used for CSS layout. This is just for this particular Canvas API. See https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-fontboundingboxascent )

[kojiishi]

I think you mean iTop = HorizAxis.ideo and iBottom = HorizAxis.idtp? What is iCentral

i* corresponds to ideographic-* defined in https://drafts.csswg.org/css-inline-3/#baseline-types

Thank you, so:

• iTop = ideographic-over
• iBottom = ideographic-under
• iCenter = central

?

central is defined as "halfway between the ideographic-under and ideographic-over baselines", so it will never be defined without iTop and iBottom, correct?

(Please note this is not a metric used for CSS layout. This is just for this particular Canvas API. See https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-fontboundingboxascent )

Thank you, yes, I think we're in sync. emHeightAscent and emHeightDescent, not fontBoundingBoxAscent and fontBoundingBoxDescent, correct?

Fonts have horizontal and vertical metrics. Which metrics do we want? Maybe we suggest HTML Canvas to add horizontal and vertical metrics?

[fantasai]

central is defined as "halfway between the ideographic-under and ideographic-over baselines", so it will never be defined without iTop and iBottom, correct?

Depends on the font format, some formats have an explicit ideographic-central baseline.

emHeightAscent and emHeightDescent, not fontBoundingBoxAscent and fontBoundingBoxDescent, correct?

Yes.

Maybe we suggest HTML Canvas to add horizontal and vertical metrics?

I guess that's an issue for Canvas API :) In CSS we use the correct set depending on writing-mode...

[css-meeting-bot]

The CSS Working Group just discussed Define em-top and em-bottom baselines, and agreed to the following:

• RESOLVED: Accept the addition of the terms with the current proposed definitions.

The full IRC log of that discussion

Topic: Define em-top and em-bottom baselines
github: https://github.com//issues/5312
fantasai: The canvas API has a handful of metrics that it allows getters for
fantasai: They decided to defer to CSS Inline for their definitions
https://drafts.csswg.org/css-inline-3/#baseline-types
fantasai: We ahve a section in css-inline which defines a bunch of metrics, their opentype equivs
fantasai: They're taking a dependency on ascent and descent metrics for the purpose of font bounding box
fantasai: There's another metric in this canvas spec that we dont' have a definition for in the CSS spec
https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-fontboundingboxascent
fantasai: So I propose we include that
fontBoundingBoxAscent/Descent
fantasai: Those map to our ascent/descent
emHeightAscent/Descent
fantasai: Then there's the em height ascent/desent
"highest top of the em squares in the inline box"
fantasai: Which don't have a definition in HTML; the deifnition is "to the highest top of the em squares in the inline box", and I'm not sure what that really means
fantasai: So the proposal is we define that metric, so the canvas api spec can hook into it
fantasai: Even if we don't end up using the metric in our own spec
fantasai: I talked to jfkthame about what he thinks the metric should be
+1 for keeping all definitions in one place
https://github.com//issues/5312#issue-654391546
fantasai: Idea is [in the issue]
Proposed definition from me and @jfkthame is:
if the ideographic-top + ideographic-bottom or ideographic-central baselines are defined by the font, emHeightAscent is 0.5em above the ideographic-central and emHeightDescent is 0.5em below. (This will normally make ideographic-top = emHeightAscent and ideographic-bottom = emHeightDescent, but if ideographic-top and ideographic-bottom are not 1em apart it will normalize the distance to 1em)
if none of the ideographic baselines are defined, use the ascent and descent normalized proportionally so they add up to 1em
florian: So dont' use the actual size, but use the proportions?
faceless2: Lots of fonts dont' have these metrics add up to 1, so normalizing is important
q?
AmeliaBR: So looks like midpoint of ascent/descent, then .5em both ways.
AmeliaBR: So it might be larger or smaller than ascent/descent if they weren't 1em apart originally?
fantasai: Yes. And bias toward the ideographic lines if they exist, they're more likely to be 1em apart
fantasai: They're also more likely to be in the center of where the ink falls, because they're centrally painted
fantasai: It works out well for CJK, and it works out fine for other writing system so long as these metrics are halfway reasonably defined.
Rossen_: Koji, any opinion on this?
koji: I generally support defining this.
koji: Been discussing with our canvas team aobut it
koji: Tehy're not really well-defined
koji: How to do it, I think we need more investigation/discussion.
koji: I'm asking in the issue some questions, and not sure what the correct way to define it is yet.
koji: So no concrete proposal yet, but think we need more investigation to make this move.
Rossen_: If the current approach is something we can resolve for now, and then refine as we go if we identify it's not the precise math we need...
Rossen_: I think there's alignment behind exposing these metrics and roughly defining them as suggested
Rossen_: Possibly with tweaks as we adjust
Rossen_: Are you against that?
koji: Not all my questions are answered yet. Like, font top metric is visual, but we probably need to support vertical flow.
q?
Rossen_: I think elika just answered that in the issue about 30s ago.
AmeliaBR: What is the actual use-case for these metrics? ARe we expecting people to use them to draw boxes around their text?
AmeliaBR: Knowing that might inform what a useful definition is.
fantasai: I think they'll be used to position the text.
Rossen_: There are more and more solutions taking a dependency on canvas today for word-like or excel-liek apps
Rossen_: So more and more need doing higher-fidelity typography thru canvas
iank_: The exact use-cases are basically "everything youc an imagine someone wanting to do when laying out text". It's pretty broad.
AmeliaBR: Right, the question is what this adds to the existing terms, and is this proposed dfn solving what's needed?
AmeliaBR: I don't know, bc I don't know what the people who added this metric were thinking about.
q?
fantasai: Well the current ascent/descent metrics aren't interoperable, so one thing this adds is a consistent answer for something ascent/descent-like.
fantasai: The font metrics used for these differ depending on browser/OS currently.
q+
fantasai: So at least in cases where we have ideographic metrics, we can get a consistent cross-platform answer here.
koji: This wouldn't be interoperable, right? It relies on ascent/descent.
fantasai: Yeah, it's just closer to interop.
koji: Is Gecko okay to change to match this?
ack jfkthame
jfkthame: I think we'd be fine with this, it's fairly close to what Gecko already does.
jfkthame: I think omst of the use-cases are better served by canvas's ascent/descent metrics, but those don't necessarily add up to 1em, and there's a legacy expectation that canvas text baseline has a top/bottom values which are specified to be the top and bottom of the em square.
jfkthame: I think there's a legit expectation for those to be 1em apart.
jfkthame: But it's not clear where the text falls in the em square if ascent+descent doesn't equal 1em.
jfkthame: So that's where this normalization comes in, giving a sensible definition to where the em square is
Rossen_: Do we know what current word formatters do in this case?
koji: There's one definition in opentype saying the ideographic em box with almost the same algo proposed here
koji: Except opentype says it only exists for cjk fonts, and it's udnefined otherwise
Rossen_: Is it a problem to define it for non-cjk?
koji: We tried to do some work there. When we used platform ascent/descent, it was quite bad
koji: We then used [s-type?] ascent/descent, we use that for underline position.
koji: we probably need more heuristic investigations
s/s-type?/sTypo/
koji: In canvas we dont' ahve font cascading, right?
koji: So if we define this in CSS, this is okay for the primary font, but going to the fallback algo would be bad. I'm concerned about that.
AmeliaBR: Canvas does do font fallback like CSS does.
Rossen_: So looking for progress.
I have to drop for a meeting, back online around noon
fantasai: I'm happy to put a note in saying that these metrics are for canvas, and not meant for CSS.
fantasai: I think we should add the terms and dfns, and note we dont' plan to use them in CSS.
fantasai: And then if there are changes to the algo needed, we can address that in further issues.
Rossen, for the CSS OM Color item, Lea and I would like to present our work before the discussion opens up. About 10 minutes should do it. [10:56] == Rossen is away: Away
RESOLVED: Accept the addition of the terms with the current proposed definitions.

, right?