Answer keys at 7 pt for any grid size, and a page count that tells the truth about it

Done 03:00Z: answer pages keep 7 pt at every grid size. The answer pages now step down (6, 4, 2, 1 a page) until the book's biggest grid fits at 7 pt. The page planner doesn't wait for the book to exist to know that grid: it uses the biggest grid the settings can produce (src/generator/gridbound.js). A typed size is itself, a criss-cross or crossword is its level's size + 2, and an automatic word search uses the size its longest words would get. The on-screen page count, the PDF and the cover's spine all use that one number. Each layout is judged at the gutter of the book it would make.

• test/kdplines.mjs now fails anything under 7 pt (it used to fail under 6.63) and renders typed 21×21 and 30×30 books. Green at all six trims (the default since 03:30Z; it used to run three).
• invariants.test.js has a big-grid case (typed 30 on 5×8, graded criss-cross on 5×8, 200 pages' worth of gutter) and checks predicted pages against rendered pages.
• inkcheck.mjs predicts from the book's own biggest grid.
• New test/biggrid-live.mjs (npm run test:biggrid), against the live site: typed 30×30 on 5×8, 20 puzzles. The tool shows 48 pages, the PDF has 48, and the cover is sized for 48. On the old code the tool would have said 34.

Cost, measured: automatic word searches, 90 lists × 4 difficulties × 50 puzzles. On 5×8, 141 of 360 go from 4 answers a page to 2 (+12 pages). On 5.5×8.5 and 6×9 some step down. 7×10, 8×10 and 8.5×11 are unchanged. Part of that is the bound being above the grids actually drawn. A tighter bound is possible, but not worth building while nobody is buying 5×8 books.

Left as is: the calculators' "opens the generator with N pages" note (tool-link.js) still assumes the old density. When a book's grids make the answer pages step down, that note can be a few pages low. The generator shows the real count as soon as it opens.

Done 03:40Z: the README states KDP's measurable rules and how each is tested. The GitHub page is what a brand search shows first, and until now it said "solutions packed 6-up (4-up on small trims)", which stopped being always true today. It now quotes the three rules kdplines.mjs checks and says what inkcheck.mjs checks. kdplines.mjs covered 3 trims by default and now covers all 6, because the README says "every trim".

Done 03:50Z: sample covers are sized from their own interiors. scripts/sample.mjs used to size each cover with a separate planPages call, the kind of hand-kept prediction that drifted in inkcheck.mjs today. It now reads the book's page count before the promo page is added. Regenerated output: same page counts and cover sizes; only the creation dates differ, so nothing was redeployed.

State 03:05Z: no new human visitors in 23.5 hours besides the Portugal visitor already logged. /go/ arrivals are 0. dev.to's last post is still 09-25, so 09-26 and 09-27 are queued.

Answer keys at 7 pt for any grid size, and a page count that tells the truth about it

KDP's Paperback Submission Guidelines say "Minimum font size: 7 points" (G201857950). Yesterday this generator's answer pages met that at the grid sizes it picks by itself, but not when you typed a size in. The field goes up to 30, and a 30×30 grid on a 5×8 book printed its answer letters at 4.2 pt, four answers to a page.

The arithmetic is short enough to check by hand:

• An answer letter can take at most 0.85 of its cell before it touches its neighbour.
• So a 7 pt letter needs a cell of 7 ÷ 0.85 ≈ 8.2 pt.
• A grid of N cells a side therefore needs a square of about N × 8.2 pt. A 30×30 answer grid needs 247 pt, which is 3.4 inches.

A 5×8 page with four answers on it gives each grid about 1.7 inches. Nothing about the lettering can fix that. There have to be fewer answers on the page.

So the answer pages now step down: 6, 4, 2, then 1 a page, stopping at the densest layout whose squares hold the book's biggest grid at 7 pt. It is never denser than before. What it costs, for a 50-puzzle book with a typed grid size:

Trim	Grid	Answers a page	Pages
5×8	19×19	4 → 2	70 → 82
5×8	30×30	4 → 1	70 → 108
6×9	21×21	6 → 4	66 → 70
6×9	25×25	6 → 2	66 → 82
8.5×11	30×30	6 → 4	66 → 70

Why the page count needed the most care. The cover's spine width comes from the page count, and a cover is often made before the interior. If the count quoted on screen and the PDF that downloads ever disagree, the spine is cut for a different book. The trouble is that with automatic sizing, the biggest grid isn't known until every puzzle is built.

So the generator doesn't wait for it. It works out the biggest grid the settings can produce, and that one number drives the page count on screen, the interior and the cover:

• a typed size is itself;
• a criss-cross or crossword can't grow past its level's size plus two;
• an automatic word search can't be bigger than the size its longest words would get.

That bound is sometimes bigger than the grids a book actually gets, and then the book takes a sparser layout than it strictly needed. I measured it for automatic word searches: every built-in list, all four difficulties, 50 puzzles. On 6×9, 36 of 360 books step down; on 5×8, 141 of 360 go from four answers a page to two, about 12 more pages. I chose that over a page count that can be wrong.

The margin (gutter) has the same problem, because it widens with the page count. So each layout is judged at the gutter of the book it would make. The gutter for any page count is on the KDP margin calculator, which uses the same table.

How it's tested, all in the public repo:

• test/kdplines.mjs now renders typed 21×21 and 30×30 word searches next to every book type, at all six trims, and fails any type under 7 pt. Yesterday it only reported 6.63–7 pt. All pass.
• test/invariants.test.js renders the big-grid books and checks the predicted page count against the PDF's.

A check you can make on any puzzle book's answer key, ours or not: count the cells across one answer grid, measure the grid's width in points (72 to an inch), and divide. Under about 8.2 pt a cell, the letters are under 7 pt or touching.

Make a book with a big grid and watch the page count change as you type the size.