Skip to content
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

[css-inline-3] sTypoAscender / sTypoDescender should not be recommended #5485

Open
litherum opened this issue Aug 29, 2020 · 13 comments
Open
Labels

Comments

@litherum
Copy link
Contributor

https://drafts.csswg.org/css-inline-3/#ascent-descent

Note: It is recommended that implementations that use OpenType or TrueType fonts use the metrics sTypoAscender and sTypoDescender from the font’s OS/2 table (after scaling to the current element’s font size) to find the ascent metric and descent metric for CSS layout. In the absence of these metrics, the "Ascent" and "Descent" metrics from the HHEA table should be used.

WebKit on macOS and iOS uses Core Text, and Core Text usually uses the metrics from the hhea table. (Note, hhea is lowercase, not uppercase.) The CSS spec should not pretend that using metrics from hhea is any worse than using metrics from OS/2.

@gsnedders
Copy link
Contributor

399aebf / https://lists.w3.org/Archives/Public/www-style/2010Aug/0419.html seems to be the origin of this recommendation

@kojiishi
Copy link
Contributor

kojiishi commented Sep 2, 2020

/cc @jfkthame

@jfkthame
Copy link
Contributor

jfkthame commented Sep 2, 2020

Core Text usually uses the metrics from the hhea table

[emphasis mine]

Are there circumstances where it uses something else? What else, and when?

@svgeesus
Copy link
Contributor

svgeesus commented Sep 4, 2020

Recommending sTypoAscender/Descender has a long history, see the 1997 Web Fonts specification:

9.11. Maximum unaccented height

For Type 1 fonts, this value may be obtained from the 'Ascender' value in the AFM file. For TrueType and OpenType fonts, this value may be obtained from the 'Ascender' entry in the 'hhea' table or (preferably) from the 'sTypoAscender' value in the 'OS/2' table. For TrueType GX fonts, the 'horizontalBefore' entry in the 'fmtx' table is used, over-riding Ascender values in the 'hhea' table.
https://www.w3.org/TR/WD-font-970721#typoascent

My hazy recollection is that Windows had a broken way of measuring ascender and descender, Mac had a broken way to measure them, and sTypo* was supposed to be the platform-neutral fix (although putting it in the OS/2 table is an odd historical curiosity)

@litherum
Copy link
Contributor Author

litherum commented Sep 5, 2020

@svgeesus Despite that being the recommendation 23 years ago, I think the ship has sailed.

@jfkthame Yes there are, but I don’t think I can get into the details - Core Text is a sophisticated, modern, production-ready text engine.

@fantasai fantasai added css-inline-3 Current Work CSS2 labels Sep 9, 2020
@fantasai
Copy link
Collaborator

fantasai commented Sep 16, 2020

@litherum Was expecting you'd file this issue. :) The text is copied over from CSS2.

@litherum @jfkthame @svgeesus What do you think the spec should say about ascent/descent metrics? Should we just remove the note? Replace it with one talking about platform differences? Continue to suggest sTypo for anyone who's not using a platform API that has its own opinions? Something else?

@svgeesus
Copy link
Contributor

It is copied over all the way from the pre-CSS Web Fonts draft.

At that time, sTypoAscender was the new shiny, and the hope was that Mac would move away from their old one and Windows would move away from their old one. (The latter did happen).

I think just removing the note is best.

@litherum
Copy link
Contributor Author

I think just removing the note is best.

+1

@litherum
Copy link
Contributor Author

What needs to happen in order for this to progress?

Since we're just discussing a note, can this be an editorial change?

@svgeesus
Copy link
Contributor

Sure, let's just remove the note.

@khaledhosny
Copy link

@svgeesus
Copy link
Contributor

svgeesus commented Feb 1, 2021

From https://twitter.com/nedley/status/1350145513849384961

We needed a way to opt fonts into some modern behaviors while avoiding unexpected metrics changes.

If Ned Holbrook is describing using sTypo* on Apple platforms as modern then perhaps the recommendation should stand?

@svgeesus
Copy link
Contributor

svgeesus commented Feb 1, 2021

img

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants