I set the TypoAscender and TypoDescender to sum to the UPM body height, which means default leading is expressed using the TypoLinegap value. /2
-
-
Replying to @TiroTypeworks @koeberlin and
So long as doing so won't result in clipping, I then set the WinAscent and WinDescent metrics to sum to the same height as the combined Typo metrics, providing Windows compatibility regardless of which set of metrics are used for linespacing. /3
1 reply 0 retweets 0 likes -
Replying to @TiroTypeworks @koeberlin and
But a pretty frequent aspect of my work involves adding script support to existing fonts, and this sometimes involves introducing glyphs that exceed the existing WinAscent and WinDescent values. So unless I can change those metrics, those glyphs will get clipped. /4
1 reply 0 retweets 0 likes -
Replying to @TiroTypeworks @koeberlin and
So the use typo metrics flag is pretty much the only chance to maybe, in some environments, maintain backwards compatible linespacing and also avoid clipping. It isn't implemented as widely or as well as it should be after 15 years, but it's still the only option. /5
2 replies 0 retweets 0 likes -
Replying to @TiroTypeworks @koeberlin and
This leads to the question of how to set hhea metrics, and where 'best practices' meet compromise. I see a lot of fonts these days that set the hhea Ascender to equal the WinAscent, and the Descender to equal the WinDescent, and the LineGap to be zero. /6
1 reply 0 retweets 0 likes -
Replying to @TiroTypeworks @koeberlin and
That is recommended as best practice on the criterion of achieving most compatible behaviour across most existing environments. But that's not the only criterion that might be considered. /7
1 reply 0 retweets 0 likes -
Replying to @TiroTypeworks @koeberlin and
As
@aaronbell points out, if we're always aiming for compatibility across existing environments, some of which have been doing the wrong thing for three decades, we're never going to get to a better place where environments behave compatibly. /83 replies 0 retweets 0 likes -
Replying to @TiroTypeworks @koeberlin and
My inclination is to set the hhea metrics to mirror the Typo metrics, because I know that at some point I might need to break compatibility of the Win metrics to avoid clipping of tall glyph additions. For me, that's best practice, given the kind of fonts I work on. /9
1 reply 0 retweets 1 like -
Replying to @TiroTypeworks @koeberlin and
With respect to
@mwichary, I should never have to see an explanation of how one particular piece of software does linespacing, or recommendations on how to make my fonts work in a single piece of software. Linespacing should be a standard. /101 reply 0 retweets 3 likes -
I totally agree. This was partly in recognition that this is indeed a messy universe and hoping to provide information about otherwise a black box, and partly an invitation to point our the flaws in our thinking (which
@aaronbell already did :·) ).2 replies 0 retweets 1 like
Figma’s weird multi-platformness also provides a different set of challenges, which I think it’s not particularly obvious (e.g. we don’t use win metrics even if you use Figma on Windows).
-
-
Replying to @mwichary @TiroTypeworks and
Generally, I would see it as a failure if Figma ever becomes an annoyance or an extra step necessary to account for during font production. Please give me/us feedback if that ever feels this way.
1 reply 0 retweets 2 likes -
I hate to say it, but more likely font developers will just set metrics as we always have and if they don’t work perfectly on Figma, that’ll be on Figma. In my experience, hacks to support a single application beget hacks. So I’m going to be as standards compliant as I can.
1 reply 0 retweets 1 like - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.