Comment by sirn
2 months ago
The first issue is due to the assumption that character count equals character display width. Thai tone markers usually[1] should not contribute to the display width (เพื่อน is chars = 6, width = 4), so it caused a layout shift.
The second issue is due to the program's layout engine not adjusting the glyph width of a fallback font to that of the main font. A lot of terminals do this, but it's not common for text editors or browsers (arguably this is the correct behavior for non-terminals, since you cannot assume everything must be snapped to a grid).
Fun test for this:
|กล้วยหอม|
|Bananas|
This has the same character width. Ghostty, etc., will render it correctly (| aligned). Most browsers and text editors will not.
[1]: some layout engines render free-standing tone markers as 1 character; in that case, this rule only applies to when tone markers are following a character.
That test looks pixel perfect in Chrome Android.
Same in Firefox for Android!
Thanks for the explanation.
Safari on iPad lines these up almost perfectly - the second line is a tiny bit wider, I didn’t even notice it at first.
That example had a tone mark but no vowels, so I will try one with both. E&OE.
[edit] These are even closer, but still imperfectly aligned on my iPad.
This isn't a renderer bug, it's font. Proportional fonts aren't designed with alignment in mind at all, and you can't just expect monospace fonts for all languages outside of ASCII range to be present on random systems, or a single font or font family to support multiple different languages consistently.
You can't really control alignment of deeply Unicode characters like Thai or "→" against monospace characters without serving your own monospace fonts that are guaranteed to work for the characters you'll be sending out, assuming you can always have one in hand.
You can still handle this well enough in the renderer, so I'd still consider this a renderer bug - e.g. my terminal emulator will scale any glyph that exceeds the bounding box as defined by the expected number of cells for a given character range. You can't expect any given feature of random characters to align, but I can expect box drawing characters surrounding any given characters to align correctly or consider it a bug (my terminal is almost certainly going to get CJK and Thai wrong - it's entirely untested -, but if so it is a bug, not a font issue).
That includes if I have to fall back, including fallback to proportional fonts, which will look ugly, but work and remain aligned.
4 replies →