Stopping orders that can't be made, before production — a deterministic rules engine that reads a font's cmap

With engraved, embroidered or printed goods, the text a customer orders can't always be made as is. The character may be missing from the shop's font, the method may not handle that character type, or the requested date may be out of reach.

Find that out just before production and the choice is to remake, or to contact the customer. Move the check to the moment the order arrives and both happen less. I wanted to build that in a form where shop staff can follow the reasoning.

1. You can't tell by looking whether a font has a character. The screen quietly substitutes another font, so text can look fine and still be unusable for engraving.
2. Text is all exceptions. Vendor-specific characters, CJK compatibility ideographs, full-width versus half-width, variations in romanisation.
3. There is no public delivery-time data. Major Japanese carriers don't provide transit-time tables, and rebuilding one from their search forms to redistribute could breach their terms of use.
4. Order data is personal data. The order CSV contains names and addresses.

No generative AI. An inspection tool has to give the same order the same answer every time and explain in one line why it stopped something.

The checks are split into side-effect-free rules, and any rule that did not run must report itself as “not evaluated”, with the reason. A check skipped because the font isn't registered or delivery days aren't entered must never pass silently as OK.

For delivery days, no guessed table is bundled. The screen states that the data isn't there and asks the shop for its real transit days.

What I gave up: completeness of automation. Filling gaps with guesses would let me write “everything checked automatically”, but that sells false reassurance.

It reads the font file's cmap — the table mapping characters to glyphs — to check that each ordered character has a glyph and that the rendered width fits the area. Romanisation is checked against Hepburn rules, and CJK compatibility ideographs and vendor-specific characters are flagged.

Rakuten order CSVs are decoded in the browser, with the character encoding detected there, and stripped of personal-data columns before checking. Screens that handle order data drop the site itself from the CSP connect-src, so the browser refuses any upload to the operator's server.

Those screens do load analytics (GA4 and Clarity). Because Clarity records on-screen text, every region where customer text is drawn — the results table and the like — is masked element by element, and a test that compares against the actually rendered DOM catches any region someone forgets to mask.

The paid annual plan uses a licence key signed with ECDSA P-256 and verified with WebCrypto. Verification needs no network call.

The site is statically exported and served from S3 and CloudFront, with the CSP enforced at the edge.

122 commits (excluding merges) between 2026-08-31 and 09-18. 10 rules — 8 per text line and 2 per order. 127 TypeScript test files and 5 Python test files for the research scripts.

9 architecture decision records, including the move from Vercel to AWS and the decision not to bundle a delivery-days table, each with its conditions for reversal.

Post-order inspection, internal rule checks, pre-flight checks on submitted artwork. When a step people do by eye is replaced by rules that can explain themselves, a design that never hides what it didn't check matters as much as accuracy.

Processing CSVs full of personal data in the browser, without uploading them, carries over directly too. Reading a font's cmap to check glyph coverage and rendered width is written up with code in checking which characters a font supports in JavaScript.

I take on business tools for e-commerce operators as business-efficiency and e-commerce system development.