How Many Problems Fit on One A4 Worksheet Page: Font Size, Margins and the Info Bar Rewrite the Pagination

The 90 Problems a Page Figure Is Not Hard Coded

I wanted a weekly mental math quiz for a grade 2 class. The first draft printed at the default 5.2 mm font and filled exactly 90 problems to the page. I had assumed that "how many problems fit on one A4 sheet" was a constant hard coded into this tool; only pushing the font from its smallest setting to its largest and the problem count from 40 to 80 told me otherwise: at 3.4 mm the page holds 105, at 9.0 mm only 39; leave the font where it is and just move the problem count from 40 to 80, and problems per row fall from 5 to 4 while the page total drops from 90 to 72.

This page is the Arithmetic Worksheet Generator, and its opening values had already been overwritten once by the grade 1 preset. The layout settings actually in force were A4 portrait, 10 mm margins, an info bar printed on every page, a row gap of 8, an item gap of 6, a 5.2 mm font and at most 5 problems per row. Measured, each problem claims 30.41 mm of width by 14.34 mm of height, which tiles into exactly 5 columns by 18 rows, and the status line reads "5 problems per row, 90 problems per page".

Move paper, orientation, margins or the info bar one step at a time, keep everything else as the first screen leaves it, and the measured cols x rows come out like this.

The Page Total Is Computed: cols x rows

These pagination lines come straight from the horizontal layout code:

cols    = floor((usableW + colGap) / (itemW + colGap))
rows    = floor((usableH + rowGap) / lineH)
perPage = cols × rows
itemW   = maxSlots × 0.66 × font

Walk the whole chain for the 5.2 mm step. A problem face for addition and subtraction within 20, written "□ + □ =", is nominally 8.86 character slots wide, so itemW is 8.86 x 0.66 x 5.2 = 30.41. On A4 portrait with 10 mm margins usableW measures 190, so floor(196 / 36.41) = 5 columns, where that 196 is usableW plus the item gap and 36.41 is the cell width plus the item gap. Line height takes 5.2 x 1.22 plus the row gap of 8 = 14.34; usableH measures 251.6, so floor(259.6 / 14.34) = 18 rows, and 5 x 18 = 90. What usableH gives up is the top and bottom margins, the 13 mm info bar band with its 2 mm gap, and one safety strip on each side.

Every factor alone can move the page total. Push the font to its minimum 3.4 mm and lineH shrinks to 12.15 while rows grow to 21, so the page holds 105; columns do not follow, because although floor(196 / 25.88) already fits 7 columns, the max problems per row input clamps them at 5. Push the font to its maximum 9.0 mm and itemW grows to 52.63, so columns fall to 3 and rows to 13, and the page holds 39. The margin step and the info bar step are in the table above: setting the info bar to first page only leaves the page total untouched, since those three options only decide which pages draw it, and the height taken off a single page is the same either way.

Figure 1: A4 portrait, items per page as the font size changes

Wider Problems Push Columns Out as Well

The hardest to expect is the width of the problems themselves. At the default step the widest problem takes 8.86 slots; raise the problem count to 80 and two digit entries appear on the sheet, slots climb to 9.86, the cell width grows from 30.41 to 33.84, and 5 columns no longer fit inside the 190 mm of usable width, so cols becomes 4 and perPage drops from 90 to 72. Same sheet, same font, and the page total still moves with how many problems you asked for.

The Layout Is Only the Denominator

In the second draft I kept adding problems and found that the pool runs out long before the paper does. Under the default no repeats rule, where a commuted pair counts as the same problem, addition and subtraction within 20 enumerates 290 distinct problems. Change the rule to comparing problem faces only, so 24+15 and 15+24 count as two, and the pool grows to 380. Tick both must carry and must borrow and only 97 are left. Set the operand limit to 5 for kindergarten and you get 25. When the pool falls short it does not quietly stuff duplicates in: ask a kindergarten sheet for 40 problems and that 25 problem pool loosens the allow repeats option first, with a warning that reads "to fill the requested problem count, allow repeats has been loosened".

Three Hard Limits, Each One Saying What It Dropped

Three ceilings are written in as well: 200 problems for a single horizontal sheet, 80 for a vertical one, and 10 pages. When one of them is reached the tool states it plainly. Generate 200 problems on A5 landscape at the 9.0 mm font and perPage is down to 15, so 10 pages only hold 150 of them and the warning reads "the 10 page limit has been reached, the last 50 problems were not laid out". In a vertical sheet, type 120 as the problem count and it is clamped back to 80 first, with a note that the sheet was generated at 80.

Same Seed Reproduces, a New Set Is Seed Plus One

The generation side is reproducible: keep the seed at 20261028, change nothing else and generate twice, and both the problem faces and their order come out word for word the same, with the first three always "1 + 8", "19 - 4", "13 - 12". What the new set of problems button really does is add 1 to the seed, and the 20261029 version overlaps the earlier sheet by only 7 problems. Shuffling order permutes and changes nothing else: all 40 positions move, while the set of problems does not lose one.

Exported Bytes, dpi and Characters You Cannot Select

Under the default settings a single page PDF measured 205,367 bytes, which unpacks as the embedded JPEG at 204,557 plus 810 bytes of container overhead, and a three page sheet of 200 problems measured 887,532 bytes. The font object count inside that PDF is 0, meaning no font is embedded: every digit on the sheet is a bitmap, so selecting, copying and searching are all out of reach. Resolution runs on two tracks: printing goes at 8 px/mm, about 203 dpi, exporting at 12 px/mm, and the page states 305 dpi. Exporting several pages as PNG packs them automatically, and that ZIP of 200 problems over 3 pages measured 1,253,618 bytes. When a print shop asks for a smaller file, what gets squeezed is only this bitmap, nothing to do with problems per page, and Image Compressor is the route for it.

Every one of the 8 headline figures in the note area of this page survived my retest, and none was overturned. The single deviation is the one page PDF: advertised at roughly 207 KB, measured at 205.4 KB, about 0.8% high, still inside the word "about".

Three Questions That Stuck Me

Q: How many problems really fit on one A4 sheet, can you just give a number?

There is no single value. 5 columns by 18 rows equals 90 only for A4 portrait at a 5.2 mm font with 10 mm margins; at 3.4 mm it becomes 105, at 9.0 mm it becomes 39, A5 portrait gives 36, and raising the problem count to 80 pulls it back to 72. For a figure you can trust, print one version on your own paper.

Q: To fit more problems on a page, should I move the font size or the item gap first?

Move the font size first, but columns have a ceiling. The 3.4 mm step reaches 105 a page because rows grow to 21, while columns stay clamped at 5 by the max problems per row input; that input is clamped between 1 and 8, and until it is raised the 7 columns the width allows never land.

Q: The printed sheet is missing problems, did they drop on the page or in the pool?

Both cases say so. When the pool falls short the warning states how many non repeating problems the current limits allow in total; when the 10 page cap is reached it writes that the last N problems were not laid out, and N is exactly the number lost.

The biggest lesson from this pagination code is not to treat problems per sheet as a table constant: it eats the font size, the margins, the info bar, the row gap and the item gap, and the width of the longest problem too. For paper layout this site already has one older article that measured cell packing square by square, the copybook pagination note, with different controls and a different bill.