Follow-up to #11. The satori renderer registers latin, latin-ext, cyrillic, cyrillic-ext, greek, greek-ext and vietnamese subsets of Source Code Pro, which covers a lot — but not everything.
What happens
Rendered a fixture with mixed scripts through dev/render.js:
| Script |
Result |
| Latin |
✅ |
| Cyrillic |
✅ |
| Greek |
✅ |
| Japanese |
❌ tofu boxes |
| Chinese |
❌ tofu boxes |
| Emoji |
❌ tofu box |
It affects the footer too, not just code: a handle containing CJK renders as a row of boxes next to the avatar.
Why more subsets won't fix it
This isn't a missed registration. @fontsource/source-code-pro ships exactly these subsets:
cyrillic cyrillic-ext greek greek-ext latin latin-ext vietnamese
Source Code Pro has no CJK or emoji glyphs at all. Every available subset is already registered, so the fix has to be a different font — something like Noto Sans Mono CJK and Noto Emoji — registered as fallback faces behind the mono family.
Why it matters
satori fails silently. No error, no warning, no log line — just boxes in an image that gets shared to Twitter, Slack and LinkedIn. Nobody will notice until a user reports it, and the S3 write-through means a bad image gets cached and served indefinitely for that URL.
Given how many tracks and how international the user base is, CJK in comments and string literals seems likely rather than exotic.
Notes for whoever picks this up
satori_renderer.js has a long comment above monoFaces() explaining how satori resolves families and styles. It is fiddly — registering all subsets under one family name silently loses everything but the first, and one-family-per-subset breaks italic fallback. Read it before adding fonts.
- Watch the image size. Full CJK fonts are large, and this ships in the Lambda container. A subset covering common ranges is probably better than the full set.
dev/render.js --fixture <path> renders locally and is the fastest way to check. Worth committing a mixed-script fixture alongside solution-go-tabs.json so this stays regression-tested.
- Emoji may want its own treatment — colour emoji fonts (CBDT/COLR) aren't universally supported by satori/resvg, so it may render monochrome or not at all even once registered.
Follow-up to #11. The satori renderer registers
latin,latin-ext,cyrillic,cyrillic-ext,greek,greek-extandvietnamesesubsets of Source Code Pro, which covers a lot — but not everything.What happens
Rendered a fixture with mixed scripts through
dev/render.js:It affects the footer too, not just code: a handle containing CJK renders as a row of boxes next to the avatar.
Why more subsets won't fix it
This isn't a missed registration.
@fontsource/source-code-proships exactly these subsets:Source Code Pro has no CJK or emoji glyphs at all. Every available subset is already registered, so the fix has to be a different font — something like Noto Sans Mono CJK and Noto Emoji — registered as fallback faces behind the mono family.
Why it matters
satori fails silently. No error, no warning, no log line — just boxes in an image that gets shared to Twitter, Slack and LinkedIn. Nobody will notice until a user reports it, and the S3 write-through means a bad image gets cached and served indefinitely for that URL.
Given how many tracks and how international the user base is, CJK in comments and string literals seems likely rather than exotic.
Notes for whoever picks this up
satori_renderer.jshas a long comment abovemonoFaces()explaining how satori resolves families and styles. It is fiddly — registering all subsets under one family name silently loses everything but the first, and one-family-per-subset breaks italic fallback. Read it before adding fonts.dev/render.js --fixture <path>renders locally and is the fastest way to check. Worth committing a mixed-script fixture alongsidesolution-go-tabs.jsonso this stays regression-tested.