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
-
-
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 -
Replying to @mwichary @TiroTypeworks and
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).
1 reply 0 retweets 1 like -
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
I don’t think this is anything different than what I said. :·)
-
-
Replying to @mwichary @aaronbell and
Maybe with one exception: As far as I understand all this, there is no actual standard to be compliant with – just a floating set of practices that evolve and change.
1 reply 0 retweets 0 likes -
I’d say that there is a standard (or three), but because of the mishmash of implementations and applications that run 20 year old code, people have had to do all sorts of ugly things to try and achieve consistency. As
@TiroTypeworks says, none of this should be necessary.1 reply 0 retweets 0 likes - 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.