New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TextMetrics baselines may not be compatible with internally-used browser metrics #4033

Open
litherum opened this Issue Sep 14, 2018 · 2 comments

Comments

2 participants
@litherum

litherum commented Sep 14, 2018

https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-getbaselines

In WebKit, we synthesize these baselines. I don't think it's clear about whether or not synthesized values should be present in the dictionary (or non-null, if we use that mechanism).

Is this API meant to be compatible with text that the browser draws? Or is it meant to be a faithful as possible to the font file?

Or, are we required to stop synthesizing these baselines in order to implement this API? (Thus potentially changing how the entire Web looks for some users)

If it's meant to be compatible with the text that the browser draws, should baselines present in the font but unused by the browser be present?

@domenic @kojiishi @jfkthame

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk
Member

annevk commented Sep 14, 2018

domenic added a commit that referenced this issue Sep 14, 2018

Revert "Add advances to TextMetrics and change baselines API"
This reverts commit 7711a1f. As
discussed in #3995, these changes were made prematurely without
appropriate implementer signoff. Since then, a plethora of issues around
the changes here have been opened up (e.g. #3994, #4023, #4030, #4033,
#4034). We revert these changes until a more complete and agreed-upon
specification can replace them.

Closes #3995.
@litherum

This comment has been minimized.

Show comment
Hide comment
@litherum

litherum Sep 17, 2018

The answer to this question probably has ramifications on what data structure is used to expose this information. If the API is supposed to be faithful to what the browser uses to draw native text, there will be a set of well-known baselines (perhaps the values for the CSS dominant-baseline property) and these can be attributes in an interface.

However, if the API is supposed to be faithful to whatever the font file happens to have in it, an open dictionary makes more sense, because we don’t want to tie ourselves to a particular font format. This is because the tags used by OpenType are a different set of tags than the ones used by AAT TrueType.

litherum commented Sep 17, 2018

The answer to this question probably has ramifications on what data structure is used to expose this information. If the API is supposed to be faithful to what the browser uses to draw native text, there will be a set of well-known baselines (perhaps the values for the CSS dominant-baseline property) and these can be attributes in an interface.

However, if the API is supposed to be faithful to whatever the font file happens to have in it, an open dictionary makes more sense, because we don’t want to tie ourselves to a particular font format. This is because the tags used by OpenType are a different set of tags than the ones used by AAT TrueType.

domenic added a commit that referenced this issue Sep 17, 2018

Revert "Add advances to TextMetrics and change baselines API"
This reverts commit 7711a1f. As
discussed in #3995, these changes were made prematurely without
appropriate implementer sign-off. Since then, a plethora of issues
around the changes here have been opened up (e.g. #3994, #4023, #4026,
#4030, #4033, #4034). We revert these changes until a more complete and
agreed-upon specification can replace them.

Closes #3995.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment