Grok Build is open source
github.com572 points by skp1995 a day ago
572 points by skp1995 a day 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.
Claude Code with Opus 4.8 is also bad at aligning boxes with content in French (with accentuated letters such as "é" which are multibyte in UTF-8).
> Thus, it falls back to Segoe UI Symbol, which does not have the same fixed width
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.
Interesting. Thai characters can also blow it out, I imagine because of the difficulty mapping glyphs to width:
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 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|
[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.
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|
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.
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.