[biztos]

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.

    |ดื่มน้ำอยู่|
    |abcdef|

[edit] These are even closer, but still imperfectly aligned on my iPad.

[numpad0]

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.

[vidarh]

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.

[numpad0]

ok... I disagree, and I mean no offense, but there's going to be too much contexts and nuances to be taken into account that it's probably not worth trying for both of us. All I can say is that the problem is not that the pipe characters are given inconsistent width but that non-ASCII characters has all different random widths, and if you need texts with double-width characters like ▶, 漢, ก, etc., to align in a grid, you have to pick a fixed-width(not "monospace") font for the specific language and exclusively use that font for everything within that contiguous text area. Or you can try to fix Unicode so that symbols become variable width so to align to grid or something, but that's going to take a lot of effort.

[vidarh]

No, you don't need to pick a fixed width font for that. You will get the best results with one, but rescaling the glyphs works just fine. I've written a font renderer. It's not hard.

In fact my terminal, using said font renderer, rescales glyphs by default because even a lot of "fixed width" fonts are buggy and not truly fixed, and so enforcing the grid alignment and scaling to fit was the easiest way to ensure consistency.

Mixing and matching fonts for full coverage works fine, especially for wide characters.

[numpad0]

I thought this discussion is more about somehow aligning pipes over multiple lines in existing console emulators(impossible), than about implementing a complete custom graphical text rendering system specific to your app that butcher font files to put glyphs wherever you want?

That feels like cheating since you're not rendering provided font at that point. Besides you might as well just use SVG for diagrams than pretending to be text only.

[vidarh]

> I thought this discussion is more about somehow aligning pipes over multiple lines in existing console emulators(impossible)

I am aligning pipes over multiple lines in my existing console emulator. It's not just not impossible, but near trivial.

> than about implementing a complete custom graphical text rendering system specific to your app that butcher font files to put glyphs wherever you want?

It's not butchering anything. It is using the font data to render them in the way that fits the constraints of the output.

> That feels like cheating since you're not rendering provided font at that point.

Any font renderer makes just adjustments to make the font look as good as possible. That is the entire point of providing a scalable font instead of a bitmap font: That you can render the provided glyphs at any scale suitable.

Fitting the bounding box of the glyph to the bounding box of the cell the text is rendering into is entirely reasonable and the lesser of two evils when faced with a glyph that does not fit the cell, which is a relatively common occurrence, when the alternative is to clip.

It looks awful if you were to render e.g. latin script with a proportional font in a fixed grid, but for many scripts with more uniform widths the variation is a lot less, and so it's butchering things far less than rendering fallback glyphs for missing code points.