A few more notes on my Grok code explorations on my blog: https://simonwillison.net/2026/Jul/15/grok-build/
For example, on your website, any chart or plot involving horizontal arrows breaks down because the assigned font-family (`ui-monospace, SFMono-Regular, Menlo, Consolas, monospace`, which ends up as Consolas on my machine) has no such glyph. Thus, it falls back to Segoe UI Symbol, which does not have the same fixed width (or is not fixed-width at all) as other characters: https://i.imgur.com/d2DPGHE.png
That seems like a glaring omission to me. If you are rendering fixed-width-per-character text and need to fall back, surely it makes sense to keep to the same character grid even if it does mess up the feel of your negative space somewhat (thin characters having a lot of space around them, wide characters butting into those beside them slightly). You've explicitly asked for text aligned to a grid, either by using a mono-spaced typeface, by using a <pre> tag, or with other relevant CSS choices, the browser should be trying to achieve that.
https://biztos.com/hey/thai-mermaid-chart.png
To my surprise, Sublime Text gets it almost right:
https://biztos.com/hey/sublime-thai-mermaid.png
I tried finding a Thai monospace font and using that in the HTML but it was worse, probably didn't have the box drawing chars.
Still a fun tool and useful for lots of ASCII cases!
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|
[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.
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|
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.
That includes if I have to fall back, including fallback to proportional fonts, which will look ugly, but work and remain aligned.
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.
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.
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.
I just thought that MS Gothic(non-P) should be kind of widely supported, have all the symbols you need, while also being a monospace, unlike most monospace fonts that only support ASCII symbols.
I am interesting in having a perhaps standardized ascii art into mermaid diagrams (which I actually just recently found could be imported easily into Tldraw/excalidraw)
Do you have the source code of this available/open-source?, I would like to have a go at it in the opposite direction perhaps.
Trying to monetize Mermaid was disgusting and honestly rings to me like trying to monetize Markdown.