-
Notifications
You must be signed in to change notification settings - Fork 6
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
Support for font metrics values for override #106
Comments
That is a good idea! How would you like to see this data presented? Say you want to set the
Wakamai Fondue could show the percentages for the CSS properties:
(Not entirely sure if positive descender values are legal in fonts, otherwise I guess it's a matter of making them positive, as "negative values are invalid at parse time.") |
Parsed values would be better. I'm not familiar with the conversions I would have to make to get them working in CSS. The code also needs to tell people that even though the values for the font come from the web font, they should be applied to the local fallback font (and it should use the local() descriptor). Thanks! |
Different browsers use different metrics to determine ascender/descender/line height: hhea.ascender So which ones should Wakamai Fondue present as the metrics that will be used in the real world? Note to self: figure out which are the most commonly used metrics in browsers, and use those to propose CSS. |
This is exactly the problem that these |
Current plan: Translate metrics to percentages. Use https://github.com/googlefonts/gf-docs/tree/master/VerticalMetrics to determine "best" metrics, select those by default. (Currently thinking this is OS/2 typo, also see https://twitter.com/boldmonday/status/1350125003510067201) Offer other metrics in a dropdown? Only when the deviate from "best metrics"? Theoretically, either metric should be fine as the font designer sets these to be the same. Except when some metrics are tweaked to work around quirks in a specific environment. Relevant Twitter thread: https://twitter.com/PixelAmbacht/status/1350059386731954176 (be sure to click at random on tweets as there are a lot of replies which Twitter helpfully hides/shows complete willy nilly) |
EDIT: if we tell the users to apply the override descriptors in, both, the fallback and the target font, we don't need to worry about what metric to use, since the user will be using the metrics that the tool provide. What do you think? |
@vhoyer Yes, it comes from the |
From Karsten Luecke, via mail:
|
guys, what's the state of this? 👀 |
Unfortunately I've been caught up in other projects, and have little free time to work on the fondue right now :-( I hope to pick this up in the winter sometime. |
Any update on this feature? I would love to see it implemented For those looking I found this was a good alternative for my personal use case |
Hi everybody, thanks for your patience. Unfortunately I was/am preoccupied with other projects. I have implemented something similar for a different project so I hope to be able to port it to Wakamai Fondue when time permits! |
Hey, this tool is doing a great job! https://github.com/unjs/fontaine |
The Fonts Level 4 Editor Draft includes default font metric overrides for ascenders, descenders, and line gap. These are now supported in Chrome (@font-face descriptors to override font metrics)
Is it possible to query the HHEA table for the font being analyzed and present that data to the user so they can use the data for overrides?
The text was updated successfully, but these errors were encountered: