[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differe

From: Behdad Esfahbod
Subject: Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Date: Sat, 22 Dec 2018 15:06:33 -0500

On Sat, Dec 22, 2018 at 11:23 AM Nikolaus Waxweiler <address@hidden> wrote:

> The thinking within the working group was that no one uses win
> metrics, so we didn't encode their variations.  Indeed, the only time
> one uses them these days is if typo and hhea metrics are not set...

But MVAR tags for win metrics exist?

'hcla'  horizontal clipping ascent      OS/2.usWinAscent
'hcld'  horizontal clipping descent     OS/2.usWinDescent

Or are they specifically for clipping avoidance and should never modify
line metrics?

You are right.  Those are for clipping on older Windows systems.  Only if there's no usable line size in hhea or typo ones should one use win.
Then the code should be removed anyway from the MVAR
apply function. I see in the HB code you linked that you use the typo
metrics if the typo bit is set and hhea metrics otherwise. I can find
no mention of win* metrics in the codebase. Should FreeType behave
similarly? I.e.

1. If OS/2 table exists and typo bit is on, use typo metrics
2. Otherwise, use hhea metrics
3. Unless they are zero, then use typo metrics. If they are zero as
well, so be it.
(4. Always ignore win metrics)

The comment given in sfobjs.c:1662 says that some ARIALNB.ttf has typo
metrics set to zero. So, not sure about 4., maybe only for static fonts?

I'm in a bit of a bind with Cantarell, as I already released a version
that ships with GNOME and does not have the typo bit set. Grr. I guess
I need to look into how to make GTK or whatever add line gap somewhere
or change the metrics around...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]