qwerasd205
Line spacing is wider on Windows than on Linux
Using the release archive AnnotationMono_v0.2.zip, file dist/ttf/Regular.ttf in that archive, if I install the font on a Windows machine I see a much wider line spacing than I do if I install it on Linux.
I've had this problem with a font of my own recently, so I know something about why it happens (although not how it got that way in the first place). Running ttfdump Regular.ttf and paging through the output, you can see three pairs of ascent/descent metrics in the font. The Linux and Windows font rendering stacks make different choices about which of those metrics to trust, so if they disagree with each other, you get inconsistent behaviour.
One pair of vertical metrics is in the hhea table:
yAscender: 800
yDescender: -200
The other two pairs are both in the OS/2 table:
sTypoAscender: 800
sTypoDescender: -200
usWinAscent: 1150
usWinDescent: 250
That last pair of metrics, usWinAscent and usWinDescent, are the ones that Windows uses, and you can see that in this font they don't agree with the previous two. If those metrics were set to 800 and 200, the line spacing would look the same on Windows as everywhere else. (In fact I confirmed that by hex-editing the font file and trying again.)
I set the USE_TYPO_METRICS bit in fsSelection, so Windows apps should be using the typo values not the win values. The win values need to be large enough to contain the min and max bounding box Y otherwise some software will clip the glyphs when rendering if they extend past there.
I believe this issue may be a result of Windows doing some heuristics and determining that the ascender metric is "wrong" so defaulting the the win metrics anyway- something like this issue: https://github.com/fonttools/fontspector/issues/206
I don't have a Windows machine to test on, but changing the win metrics is a non-starter for me, since those define the clipping region, as explained in the OpenType specification (https://learn.microsoft.com/en-us/typography/opentype/spec/os2#uswinascent):
The “Windows ascender” metric. This should be used to specify the height above the baseline for a clipping region. ... In the Windows GDI implementation, the usWinAscent and usWinDescent values have been used to determine the size of the bitmap surface in the TrueType rasterizer. Windows GDI will clip any portion of a TrueType glyph outline that appears above the usWinAscent value. If any clipping is unacceptable, then the value should be set greater than or equal to yMax.
(Emphasis mine)
What software on Windows are you seeing this extra line spacing in? Have you compared the behavior of other fonts? I'd like to fix this, but I'll need more information.
As a shot in the dark, perhaps there's some sort of detection for if the win metrics don't exactly match the yMax and yMin. What happens if you set them to that (1106 and 235 respectively for Regular), does the behavior persist?
You clearly know more than I do about all of this – I didn't know about the USE_TYPO_METRICS flag at all, or about the different semantics of the usWinAscent fields. In that case I have to agree that trying to persuade Windows to use sTypoAscender seems more like the right answer.
(When this happened in my font, the problem was indeed that usWinDescent was being set to a huge size because of a glyph with an enormous bounding box, but that enormous bounding box wasn't to do with the intended appearance of any glyph: it had been accidentally generated by what looked like a numerical instability in Fontforge's outline simplification. So for me the fix was to make usWinDescent have a more sensible value, by stopping Fontforge from making that mistake.)
What software on Windows are you seeing this extra line spacing in?
I tried both PuTTY, which is what I mostly use monospaced fonts with in any case, and Notepad just in case the problem was specific to PuTTY. I saw the same wide line spacing in both cases.
On Windows 10, in case that makes a difference. (Sorry, I should have mentioned that detail in the first place.)
What happens if you set them to that (1106 and 235 respectively for Regular), does the behavior persist?
Yes, I'm afraid it does.
I wouldn't be surprised if PuTTY was being incorrect and ignoring the USE_TYPO_METRICS bit, but I would be pretty surprised if Notepad did. Maybe I'll set up a Windows VM to test at some point to see if I can narrow down the cause. I'm pretty busy lately, so it may be a while before I get around to it. (You'll notice the other open issues on the repo, I plan on addressing them in a batch for v0.3 whenever I do some work on Annotation Mono again.)