Characters overlap horizontally and have gaps vertically in LXTerminal

[mobluse]

The characters overlap horizontally in LXTerminal 0.3.2 included in most updated Raspberry Pi OS Buster on Raspberry Pi 4 B. I use LegacyComputing Regular 20, but the same problem is with 8 or 10. Also there are gaps vertically and that doesn't work for the block graphics characters. See dejavu-fonts/dejavu-fonts#383

[dokutan]

I am unable to reproduce this issue in LXTerminal 0.4.0 on Arch Linux. Considering that the alphanumeric characters which are not included in this font overlap as well, i strongly suspect an issue either in LXTerminal or your fontconfig.

For me this example

 🭁🭂🭃🭄
 🭁🭂🭃🭄

 🬝🬜🬟🬛 
 🬝🬜🬟🬛

 🬟🬟🬟🬟
 🬟🬟🬟🬟
 🬟🬟🬟🬟

results in the following output in LXTerminal:

[r-hoogenboom]

I think this depends on which 'base' font is chosen. I have also noticed that the 'sextants' don't align nicely with the "missing" sextants 'SPACE'/'NO BREAK SPACE', 'LEFT HALF BLOCK', 'RIGHT HALF BLOCK' and 'FULL BLOCK' from major monospace fonts.

[dokutan]

@r-hoogenboom To investigate further, i have created the following comparison (all fonts sizes are 10 pt):

This strongly suggests that Noto Sans Symbols2 is used instead of LegacyComputing, and the culprit behind the misaligned characters. If that is true, the fix would be to change your fontconfig (or the equivalent on other operating systems).

If you have other evidence suggesting LegacyComputing is the cause for the problems or suggestions to what i should change the width of the sextants (because i don't know from looking at the comparison i made), i would update this font.

[rohoog]

First of all, I am not a font expert, so forgive me if some things sound ignorant.
The remark from @r-hoogenboom (which is actually me...) was about font fallback, where the font renderer takes glyphs from another font if the user-selected font doesn't have glyphs for the code point to be rendered. Font-config provides font fallback in *nix systems. Windows terminal is yet to gain the concept of font fallback, but it is on their list.
In your renderings above, there is no mixing of different fonts on one line.

The funny thing about the sextants in the legacy computing is that the unicode group didn't include all 64 possible pixel combinations in the legacy computing block and the missing ones need to be taken from another code block (namely, the "Block elements"). So if the 2x3 sextants are used to display a bitmap image, you get a mix of glyphs from 2 different fonts and any misalignment stands out like a sore thumb. I guess the legacy computing is based on a full-block size of 8x12 pixels commonly used on legacy computer screens originally (divisible by 3 vertically and by 2 horizontally, resulting in almost-square sextant pixels on terminals using monospace fonts). Typically your font will not be a primary font, but rather a fallback font, as you can imagine.

To add extra complication in the mix, it seems that at least the xfce4-terminal emulator from Fedora 34 has some built-in support for these block elements and legacy computing glyphs. I don't have your font installed here, but I can show these sextant glyphs just fine in the terminal, while they don't show in the browser. This terminal emulator built-in support is obviously perfectly aligned; no overlapping or small gaps. Maybe that is the way to go for such glyphs in terminal emulators, as there is no freedom in how these glyphs are 'styled' anyway.

The gnome-terminal and xfce4-terminal of Centos-7 doesn't do that and it requires a font installed that implement these glyphs to show them. This is where the misalignments become apparent. The LEFT/RIGHT-HALF BLOCK and FULL BLOCK are a little higher than the sextants from your font. The amount of misalignment differs a little bit depending on which 'base' monospace font is selected.

I see that your font was designed with fontforge and I have briefly browsed through the 'design with fontforge' documentation. This documentation is primarily geared for proportional fonts (based on the EM-square) and nothing much is said about monospace fonts, but I guess that should be based on the 'FULL BLOCK' U+2588 geometry. Monospace fonts don't all seem to have the same aspect ratio of this full block. I guess what should happen with glyphs borrowed from another font is that those glyphs are anisotropically scaled to match the aspect ratio of the full block of the primary font. Then this fallback can work without alignment problems. I don't know if this is commonly done (eg. in Pango). I also don't know how to figure out the full block geometry of a monospace font to compare yours with others.

All in all, fonts are a complex science and it is easy to get something wrong. Who am I to say which part of the 'font-stack' is causing this misaligment. Maybe you can?

[rohoog]

The liberation mono font is also on github.
It advertizes ascent 1638 and descent 410, but the full block (U+2588) has vertical coordinates from -615 to 1705, generously beyond the ascent and descent. The width 1229 is adhered to by the horizontal coordinates.
Your font has ascent 800 and descent 200. The sextant 1256 has vertical -200 to 800, nicely staying within ascent and descent. The width of 600 is aligned with the horizontal coordinates.

If it is common practice that the full block is actually beyond the ascent and descent bounds, then that may be the reason why the vertical gaps are observed. I don't have an explanation for the horizontal overlap though.

[dokutan]

All in all, fonts are a complex science and it is easy to get something wrong. Who am I to say which part of the 'font-stack' is causing this misaligment. Maybe you can?

I wish i could.

Your ideas about exceeding the bounds make sense, therefore i have prepared a few tests: LegacyComputing.zip

1. U+1FB1E is changed to the word "TEST" to check if the intended font is used
2. the height U+1FB1F is increased to -300/900
3. The width of U+1FB21 is decreased to 50/550

I'm interested about your results of these tests. If changing the size of the glyphs is a viable fix, i would try to create a version of this font matching the liberation mono sizes.

[rohoog]

I will check it when I'm in the office again.

[r-hoogenboom]

I see the word TEST for the U+1FB1E, but it's not very useful to have increased the height of that same glyph. Better have changed one of the 'full-height' sectants, like U+1FB3B.
I have made a html file that shows the alignment problem, but needed to rename to .txt to get gitlab to accepted it as attachment
legacycomputing.txt
.

[r-hoogenboom]

Oh, I see that U+1FB1F is enlarged, not U+1FB1E...
Changed the html file accordingly and it seems to have fixed the problem. Try it yourself
legacycomputing2.txt
!

[r-hoogenboom]

The narrowing of U+1FB21 seems to worsen the situation. The glyph is much narrower than, for instance, U+2583 from liberation mono.

[dokutan]

In this version the glyphs U+1FB00 - U+1FB9F are scaled by 114% and moved by -40 in the Y-direction: LegacyComputing.zip. For me this results in the same width, height and vertical position as Liberation Mono. I achieved this using Transform on the glyphs in FontForge.

If this solves your problem, i will add a new release. Otherwise we would need to find a size that works for you.

[r-hoogenboom]

The alignment is better but still not perfect and it depends on which font it is 'paired' with. The only way I get good co-rendering of the block elements and symbols for legacy computing is when it is built-in in the terminal emulator (like fedora 34) or when both code blocks come from the same (monospace) font - I haven't seen such font yet. The an-isotropic scaling for the alien glyphs I suggested seems not implemented in any font rendering. Maybe something for fontconfig/pango. Maybe the built-in support in terminal emulators is the way to go.

That said, I do see that height of the 'FULL BLOCK' is always about 114% of the ascender to descender size in all monospace fonts and I think the 'FULL BLOCK' U+2588 should be the reference for all the pseudo-graphics symbol glyphs. Also pseudo-graphics are a thing from the past and don't fit well with the modern unicode design. Furthermore it is weird that 4 of the possible sextants are missing in the unicode block for legacy computing and need to be borrowed from another font.