Font line height modified even without -l option?

[nathanielevan]

Hi, I recently manually patched this version of Fantasque Sans Mono and I noticed that the resulting line height is a little taller than the "stock" version; the font itself looks the same as far as I can tell, just that there's some extra space at the bottom, and it doesn't seem to matter whether I ran the patcher with the -l option or not; I happen to have an older patched version of the same font (same version of font) and it didn't seem to do that. Pertaining to this, what exactly changed along the way?

[Finii]

The -l option does not do 'anything', iirc 😬

Line height is always problematic, often because the original font itself has contradicting data embedded and whatever is rendering the font can do it this way or that. But when the patcher runs it needs to decide on one line height.

I assume you used a recent font-patcher? Can you give the script version (the second number, that is in parentheses, shown on startup, maybe 3.4.3 is current.

[Finii]

So I assume you are on Mac? (Because they use typically the HHEA values.)

If that is indeed a problem and we understand it, we could solve it via -l (so that that flag actually is useful for something :-D )

[Finii]

Relevant code ... hmm 🤔

    def setup_line_dimensions(self):
        # win_ascent and win_descent are used to set the line height for windows fonts.
        # hhead_ascent and hhead_descent are used to set the line height for mac fonts.
        #
        # Make the total line size even.  This seems to make the powerline separators
        # center more evenly.
        if self.args.adjustLineHeight:
            if (self.sourceFont.os2_winascent + self.sourceFont.os2_windescent) % 2 != 0:
                self.sourceFont.os2_winascent += 1

            # Make the line size identical for windows and mac
            # ! This is broken because hhea* is changed but os2_typo* is not
            # ! On the other hand we need intact (i.e. original) typo values
            # ! in get_sourcefont_dimensions() @TODO FIXME
            self.sourceFont.hhea_ascent = self.sourceFont.os2_winascent
            self.sourceFont.hhea_descent = -self.sourceFont.os2_windescent

The -l actually does something (the bottom paragraph). But does that all makes sense?
Win-Ascent will not be used anyhow with your font, because it has use typo metrics set.

And we have this

        gap = max(self.sourceFont.hhea_linegap, self.sourceFont.os2_typolinegap) # TODO probably wrong
        if self.sourceFont.os2_use_typo_metrics:
            gap = self.sourceFont.os2_typolinegap
        self.sourceFont.hhea_linegap = 0
        self.sourceFont.os2_typolinegap = 0
        if gap > 0:
            gap_top = int(gap / 2)
            gap_bottom = gap - gap_top
            print("Redistributing line gap of {} ({} top and {} bottom)".format(gap, gap_top, gap_bottom))
            self.font_dim['ymin'] -= gap_bottom
            self.font_dim['ymax'] += gap_top
            self.font_dim['height'] = -self.font_dim['ymin'] + self.font_dim['ymax']
            self.sourceFont.os2_typoascent = self.sourceFont.os2_typoascent + gap_top
            self.sourceFont.os2_typodescent = self.sourceFont.os2_typodescent - gap_bottom
            # TODO Check what to do with win and hhea values

The TODO question in the bottom is right. We do not adjust the hhea values?
Need some sleep, will continue later.

[nathanielevan]

Here are a couple of images. Both of them are the same resolution so hopefully the line height difference is clear:

3.0.5	3.2.2

Tested on LibreOffice Writer, it appears that the original unpatched font has the same line height as the "taller" 3.2.2 version -- whereas on the terminal, the original unpatched font has a line height similar to the "shorter" 3.0.5 instead.

I use Alacritty 0.11, which I believe is the latest. Distro is Arch Linux.

Here are the metrics:

metrics	unpatched	3.0.5	3.2.2
Typo ascent	1750	1750	1800
Typo descent	-498	-498	-548
Typo line gap	100	0	0
HHEA ascent	1750	1750	1750
HHEA descent	-498	-498	-498
HHEA line gap	50	0	0

(3.4.3 shares the same metrics as 3.2.2.)

I think what is happening here is that my terminal ignores the line gap? So when that line gap gets distributed it appears as if the font patcher just made the line height taller.

[Finii]

Will combine this with #1056

[Finii]

I think what is happening here is that my terminal ignores the line gap?

The font is inconsistent / contradicting vertical metrics...
With the zip you linked above:

$ font-line report FantasqueSansMono-Regular.ttf
[...]
::::::::::::::::::::::::::::::::::::::::::::::::::
  Baseline to Baseline Distances
::::::::::::::::::::::::::::::::::::::::::::::::::
hhea metrics: 2298
typo metrics: 2348
win metrics:  2298

[OS/2] fsSelection USE_TYPO_METRICS bit set: True

Mainly Mac applications observe the HHEA value, while Windows applications follow WIN or TYPO metrics, hopefully observing the use-typo-metrics bit.

With the latest commit in 1056 the patcher will use the WIN metrics, which is also what you would expect.