That's what line-gap is: gap between consecutive lines. There is no line before the first line, and as such, no gap.
On Wed, Jan 30, 2019 at 4:37 PM Nikolaus Waxweiler <[email protected]> wrote: > 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. > > -- behdad http://behdad.org/
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
