OTB files generated by old version of fonttosfnt have incorrect metrics

[ghost]

This was previously discussed in #25

I didn't end up using the newly generated .otb due to reasons outlined in this post: #25 (comment) (i.e. alacritty could succesfully use the .otb, but pango couldn't). I gave up and downgraded Pango instead.

Today I decided to try again, as it looks like updates have been made to Pango.

With Pango 1.46.2, there is still an extra 1-pixel gap between glyphs when using the .otb version.

I did a lot of digging and debugging, and I was able to eventually figure out that the version of fonttosfnt used at the time of #25 had some issues w.r.t. calculating font metrics. This means that Pango was never the issue.

The method outlined in #25 (comment) can be used, but needs the latest version of fonttosfnt to convert properly. (everything from the last release (1.1.0) up to commit ca9ad454, https://gitlab.freedesktop.org/xorg/app/fonttosfnt)

This will probably be easier once they push out a new release, but I just wanted to confirm that:

1. The issue still exists
2. There is a solution
3. I've tested the result this time, and can verify that Tamzen works with newer versions of Pango

[ghost]

For interest's sake, I couldn't figure out exactly what changed in fonttosfnt, but I imagine that the issue must be related to things like this: https://gitlab.freedesktop.org/xorg/app/fonttosfnt/-/commit/de8068f9c4251fb6cb9407c07bf245e1937270bc

If you have more time, you can use Python FontTools to dump .otb metadata, e.g.

fonttools ttx -t EBLC TamzenForPowerline7x13r.otb

That gives you a .ttx file which is a human-readable version of the binary headers in the font file. I thought the issue was that horiBearingX was set to 1 (whereas for OTB versions of Terminus it's 0), but it seems like the change that makes the font render properly must be in another table.