[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: Nikolaus Waxweiler
Subject: Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Date: Thu, 31 Jan 2019 00:37:08 +0000

Even more testing.

ftview and Qt actually do the same GTK does: they don't add the line gap to the top, so text fields look compressed when the USE_TYPO_METRICS bit is set and typo asc+desc is smaller than hhea asc+desc. I'm not sure this is supposed to happen?! Didn't test MVAR modification.

Firefox and Chromium disregard FT_Face's ascender, descender and height attributes and use either hhea (I think; no USE_TYPO_METRICS) or typo metrics (USE_TYPO_METRICS), modifying typo metrics and the FT_Face attributes through the MVAR table therefore has no effect unless the USE_TYPO_METRICS bit is set.

The document body of a new text file in LibreOffice Writer stays the same regardless of bit so I think LO Writer is doing it right. It doesn't support VFs though so I can't test MVAR modifications.

Behdad, I'm not completely sure of typo deltas in MVAR modifying the currently active metrics. Given that the hhea set is basically a legacy value and is probably taller spaced than the typo metrics, so we might end up doing things the designer didn't intend? What FF/Chromium do strikes me as saner, i.e. writing typo metrics to FT_Face ascender/descender/height when USE_TYPO_METRICS is set :/

Otherwise, I'd say unless anyone has objections, I think we can merge the branch.

reply via email to

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