[scribus-dev] Vertical extent of text

[Michael J Gruber]

[I don't know whether you prefer top or bottom eplies here, so please excuse.]

So, some more digging into this issue reveals the following: There are
three possible sources for vertical metrics in a font (hhea, OS/2
sTypo, OS/2 usWin). As I understand, the behaviour of freetype 2.10 is
more in-line with the font spec as well as with other software which
changed (e.g. browsers, newer office) but creates incompatibilities
with others (e.g. older software); it most probably will not be
reverted. Whether you notice any difference depends on the fonts:
whether some of these metrics are set to zero, whether they differ,
and whether the "use typo metrics" flag is set.

For the font Alegreya Sans Regular where I first noticed the problem
the metrics are:
sTypoAscender 800
sTypoDescender -200
sTypoLineGap 200

h.ascent 900
h.descent -300
h.lineGap 0

This explains everything you see in the two different PDFs which I
posted... Note that A-D+G == 1400 in both cases. (usWin is different
but not used by any freetype version for this font).

But maybe it indeed is Scribus which should take into account the
LineGap when filling the paragraph background? In fact, there are good
reasons to extend the filled background by 0.5*LineGap each above the
Ascender and below the Descender. At least for this font, this would
lead to the same behaviour as with the hhea values, and is probably
the reason for these values.

Michael

Am Di., 26. Nov. 2019 um 12:31 Uhr schrieb Craig Bradney
<cbradney at scribus.info>:
>
>
>
> > On 26 Nov 2019, at 11:42, Michael J Gruber <mjg at fedoraproject.org> wrote:
> >
> > So, the analysis went further, and I've bisected the problem down to
> > this commit:
> >
> > https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=f72b00746c64e13625cf8371f031411fbd0d6161
> >
> > That is: A freetype with this commit produces the described problem
> > with scribus, one without does not. Even a freetype 2.10.0 with that
> > commit reverted works.
> >
> > Now, I have no idea whether the condition "OS/2 table exists and
> > fsSelection bit 7 (USE_TYPO_METRICS)" is something that scribus should
> > or even could have any influence on. If no then the bug is in
> > freetype, or in the fonts - in many fonts! In the "no" case, filing a
> > bug against scribus is pointless, and someone would have to take this
> > to the freefont mailing list or bug tracker.
> >
> > Probably, freefont is doing the right thing according to the font
> > specs and most fonts don't... But I have no expertise in that area.
> >
> > Michael
> >
> >> Am Mo., 25. Nov. 2019 um 17:18 Uhr schrieb ale rimoldi <ale.comp_06 at xox.ch>:
> >>
> >> hi michael
> >>
> >> wow!
> >>
> >> i'm not a font expert, so i can't say much on the details but:
> >>
> >> at the end of the process can you please summarize your findings in the
> >> bug tracker?
> >>
> >> https://bugs.scribus.net
> >>
> >> we probably need a demo .sla with the different pdf outputs with the
> >> different versions of freetype...
> >> attaching also some of the fonts that can be used to reproduce the
> >> issue will probably also help.
> >>
> >> congratulations for your analysis!
> >>
> >> a.l.e
> >>
>
> Typically in these situations we have limited Scribus to certain versions of a library. We could consider that again. I know Jean keeps a keen eye on free type issues
>
> Thanks for the deep dive.
>
> Craig
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev