Comment by simonw
2 hours ago
There's some surprising stuff in this codebase. For example, https://github.com/xai-org/grok-build/blob/b189869b7755d2b48... is a "self-contained terminal renderer for Mermaid diagrams", which renders a subset of Mermaid chart types using Unicode box-drawing.
I had Fable 5 compile that Rust code to WebAssembly and build a browser-based playground for it, so you can try it out with Mermaid diagrams here: https://tools.simonwillison.net/grok-mermaid
A few more notes on my Grok code explorations on my blog: https://simonwillison.net/2026/Jul/15/grok-build/
I love this kind of stuff (ASCII art, if you will), but it just breaks down too easily as soon as Unicode characters (mainly CJK, as I'm Chinese) and fonts are involved.
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
I ran into this problem recently on one of our blog posts: we used some Claude output which included tables drawn with Unicode line drawing characters. However, our monospace font did not include these characters, and so rendering fell back to another font in our font stack with different width metrics. I fixed it by using a font that had similar metrics and did include those characters with `unicode-range` (to only select characters we needed) and `size-adjust` (to match font width more exactly), and adding it to the stack. It's a little hacky but works pretty well in practice.
I was going to say, perhaps generate a failing test case, but testing for proper unicode rendering might be tricky??