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 6.1.4.2
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.
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel