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

fantasai · 2020-07-09T22:42:52Z

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

The text was updated successfully, but these errors were encountered:

kojiishi · 2020-07-20T03:10:11Z

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 · 2020-07-21T20:36:17Z

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 · 2020-07-28T08:43:37Z

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 · 2020-07-31T14:42:50Z

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 · 2020-07-31T14:58:53Z

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

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

…5312

See w3c/csswg-drafts#5312. And also #5429 for where all of this started. Ideally though w3c/csswg-drafts#5431 would be fixed too and we'd figure out how to update images/baselines.png (I've asked Ian if there's an original somewhere).

fantasai added css-inline-3 Current Work HTML Requires coordination with HTML people labels Jul 9, 2020

fantasai mentioned this issue Jul 9, 2020

[css-inline] HTML taking a dependency on ascent/descent metric #5266

Closed

fantasai added the Agenda+ F2F label Jul 19, 2020

fantasai modified the milestones: VF2F-2020-07-28 Slot B, VF2F-2020-07-27 Slot B Jul 20, 2020

astearns added this to the VF2F-2020-07-28 Slot B milestone Jul 27, 2020

astearns modified the milestones: VF2F-2020-07-28 Slot B, VF2F-2020-07-31 Slot A Jul 30, 2020

css-meeting-bot removed the Agenda+ F2F label Jul 31, 2020

mozilla-apprentice mentioned this issue Jul 31, 2020

[css-inline-3] Define em-top and em-bottom baselines mozilla/wg-decisions#334

Open

This was referenced Jul 31, 2020

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

Open

[css-inline-3] Ascent and Descent Metrics in vertical flow #5381

Open

fantasai added a commit that referenced this issue Aug 12, 2020

[css-inline-3] Define em-over and em-under baselines for Canvas API. #…

0cb8202

…5312

fantasai added the Closed Accepted by CSSWG Resolution label Aug 13, 2020

fantasai closed this as completed Aug 13, 2020

annevk mentioned this issue Aug 14, 2020

[css-inline-3] Canvas 2D's textBaseline = "middle" neccessitates an em-middle baseline? #5431

Open

annevk mentioned this issue Aug 14, 2020

Reference even more baseline concepts in CSS Inline Layout whatwg/html#5826

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

fantasai commented Jul 9, 2020

kojiishi commented Jul 20, 2020

fantasai commented Jul 21, 2020

kojiishi commented Jul 28, 2020

fantasai commented Jul 31, 2020 •

edited

Loading

css-meeting-bot commented Jul 31, 2020

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

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

Comments

fantasai commented Jul 9, 2020

kojiishi commented Jul 20, 2020

fantasai commented Jul 21, 2020

kojiishi commented Jul 28, 2020

fantasai commented Jul 31, 2020 • edited Loading

css-meeting-bot commented Jul 31, 2020

fantasai commented Jul 31, 2020 •

edited

Loading