Font previews in some apps render incorrectly with lots of extra horizontal space

[somelinguist]

Describe the bug
In some font preview apps like PopChar and Font File Browers, versions 7.050 and 7.051 of Libertinus Serif, Libertinus Sans, and Libertinus Serif Display appear with a lot of horizontal space on both sides of each glyph. In PopChar, it causes each glyph to be rendered at a very small size. See the screenshots below of Libertinus Serif Regular compared to other fonts.

Actually using the fonts in other apps and documents to compose text works fine.

Screenshots / logs

Additional context
Previous versions still display correctly in both PopChar and Font File Browser. Did anything change in the latest versions that might have affected this?

[alerque]

Congrats on the strangest bug report I've seen this week. I have no idea what this is about.

Nothing in the rage v7.040..v7.050 suggests itself as being problematic. The biggest change likely to be responsible here is tooling: lots of the tools used to build the font have been updated in the intervening years (fontmake, fonttools, psautohint, etc.). Its not impossible there is some error in this font repository triggering this behavior, but it's also possible some font handling library introduced the issue along the way.

Out of curiosity do you have the same results with the newly minted TTF variants, or only the OTFs? Does it affect all fonts in the family or just Libertinus Serif?

[somelinguist]

Congrats on the strangest bug report I've seen this week. I have no idea what this is about.

Thanks! I try!

Thanks for the explanation about the tooling. It's no fun with tooling updates create issues.

I just tried the TTF of Libertinus Serif Regular, and it looks better, but still has roughly the same problem?

[somelinguist]

Sorry I don't know enough about fonts to be much help.

I just found this site https://fontdrop.info that gives lots of info for font files you drop on it.

I happened to have old files for 7.030 on my drive as well, so I compared the Libertinus Serif Regular OTF files for both, and some of width/size values are significantly different:

	7.051	7.030
head – Font Header Table
xMin:	-6275	-1325
yMin:	-256	-256
xMax:	6171	1269
yMax:	1125	928
hhea – Horizontal Header Table
advanceWidthMax	6272	1300
minLeftSideBearing	-6275	-1325
minRightSideBearing	-953	-439
xMaxExtent	6171	1269

Sorry again that I don't know much about how those would be set, etc., or if that might actually be what is affecting previews for me. :)

[somelinguist]

Does it affect all fonts in the family or just Libertinus Serif?

Sorry, I missed this question. It looks like all of them except for Libertinus Mono.

[alerque]

I guess there is an easy way to know if it is tooling related. I can try to regenerate v7.040 using current tooling and/or v7.051 with old tooling.

[alerque]

Here are some pseudo releases to compare with:

• Libertinus-7.041.zip
  v7.041 is the same sources as v7.040 with as minimal changes as possible to build with current tooling versions (minus the monospace font that won't build with new tooling but doesn't seem relevant to this test), and

• Libertinus-7.052.zip
  v7.052 is the same sources as v7.051 but built with tooling versions from a couple years ago (via an old Docker image of Fontship).

Can you give each of these a spin and see if either/both show the same effects?

[somelinguist]

It looks like 7.041 and 7.052 both have the same problem. I went back and downloaded the actual 7.040, and it looks fine.

[somelinguist]

I browsed through the glyphs in the font files with Font File Browser and the font drop website I mentioned above, and it looks like there are a few really wide ones, though I couldn't find any reference to them this repository. The uniE008 glyph is in all versions since 7.050, including the 7.041 and 7.052 versions you just made, but it's not in 7.040. Interestingly, it reports an advancedWidth of 6272.

Are the other two below just variants that get created because of widths?

uniE008

UNI0305.6250

UNI0332.6250

[somelinguist]

Oh, wait, here it is:

https://github.com/alerque/libertinus/blame/a6487570b8fdcfa69557744f5e5c5d044de0a9db/sources/LibertinusSerif-Regular.sfd#L32026

[alerque]

This still isn't making a bean of sense to me. The uniE008 glyph has been part of the project since the Linux Libertine days and I don't see any relevant changes there.

In other news though, by test above was a bit incomplete. I built v7.052 using a Fontship version from the same year that v7.040 was built, but it turns out if was from a couple months after the release. I just did another build using the actual version that would have been current at the time Libertinus shipped:

Libertinus-7.053.zip

What does that do for your app?

[somelinguist]

7.053 works:

I saw after my last comment that I could find uniE008 in the source pretty far back in the commit history. But I checked, and I still can't see where it shows up in the viewer apps in 7.040 or 7.053, where as it does in 7.050, 7.051, 7.052, and 7.041.

So something must be up with the tooling.

[somelinguist]

What code point(s) should render uniE008? I'd like to see what it looks like in a text document.

[alerque]

Whew, at least we got one result as a stepping stone to work from. So it's something in between Fontship v0.7.6 and Fontship v0.8.2. And probably not Fontship itself but one of the bundled tools like python-fonttools or python-sfdlib or python-sfd2ufo. There isn't much more to bisect there, the breakage almost certainly comes in with something in Fontship v0.8.0 which brought lots of updated Python tooling.

Also it still isn't clear this is even a bug in the font, it might be correct behavior from the font and a bug prior, and your preview apps just don't handle the correct encoding properly. I think we have enough evidence to go on here yet, but still digging...

[alerque]

UniEOO8 is in the private use area of Unicode and I have idea why there are PUA glyphs in any of the family fonts in the first place. There is a handful of random signage and flourishes and iconography in Libertinus Serif and others that (in my opinion) just doesn't need to be in a body text font family at all.

[alerque]

Here is the code point if you want to try it in something: .

[somelinguist]

I just tried it out in various versions of Libertinus Serif Regular, but it doesn't seem to render in any of them when used in a text/document file. I tried on both macOS and Windows. Is it just a glyph that gets added to some other code point?

[kimmus]

Re uniE008: in v7.040 and v7.051 I find nothing in the Private Use Area at all, at least in the OTF version of the fonts. The original Linux Libertine fonts did have lots of glyphs there.

[khaledhosny]

Long time ago I dropped all PUA code points from the fonts, I kept the gluphs in the sources but made them unencoded so they were inaccessible, and I think I had a subsetting step that would remove any inaccessible glyphs. Either inaccessible glyphs are now kept, or something is adding codepoints back to the glyphs.

[somelinguist]

Thanks for the helpful info!

As you say, I wonder if something in the tooling change skips taking them out now, or if they get added back in.

[khaledhosny]

I think it might be caused by 9fedcbe