[font-metrics-api] Clarification on internal leadings

[kojiishi]

There once was confusion about handling of internal leading in font metrics. Microsoft published a few good kb articles 32667 or 74299 to clarify this, but I think some web developers still have different understanding on this, especially when their native scripts do not use accents.

I wish this new spec clearly defines whether the ascent includes the internal leading or not (I believe it should but I'm ok either way), and hopefully the naming clarifies this point to let web developers think about it, or provide both methods for convenience.

It may make the method names long and redundant though. Thoughts?

cc @astearns @eaenet

[kojiishi]

After re-reading the current draft, it reads to me that height and emHeightAscent do not include the internal leadings. Is that correct?

I'm fine with that, but maybe we want to add methods that includes internal leadings?

[eaenet]

That's a good idea. I'll clarify it. What would you suggest as a name for metrics that include internal leadings?

[kojiishi]

Not particular, but what about:

• cellHeightAscent, borrowed the terminology from MS kb articles kb32667 or kb74299.
• Looks like Gecko has internalLeading in their native font metrics. We could expose this, and assume emHeightAscent is clear enough to understand emHeightAscent + internalLeading is OpenType ascent?
• I thought I once saw ascentWithInternalLeading or ascentIncludingInternalLeading in Gecko code, but can't find any longer, maybe my memory is wrong.

[eaenet]

Thanks, I'll update the doc to clarify it and to add internal leading.

[kojiishi]

Regarding whether to return internalLeading or ascent with internalLeading, I started to mildly prefer ascent with internal leading, since it's a max value of possibly multiple fonts, and having the max of ascent + internal leading seems to help better than having the max of ascent and the max of internal leading to me.