Splitting a word can change the task of an English worksheet. Reading the actual PDF generator led me to prioritize word preservation and detectable layout failure before the visual appearance of a paragraph.
Character count is not rendered width
Equal character counts do not imply equal width: narrow and wide glyphs occupy different space. The source uses font-based string measurement before placing the next word. I extracted that decision into wrap while accepting a measurement callback, separating the rule from its font integration.
Pure tests use a simple length function to inspect boundaries; the actual PDF uses Helvetica metrics. Those are different evidence. One explains the algorithm, while generation and rendering inspect the finished output. Another language or font requires another review of measurement and segmentation rather than inheriting the same layout claim.
Move the oversized word after existing text
Checking only an oversized first word misses the case where a short word precedes it. The new function checks every word’s own width before line assembly. Moving a word to another line cannot make that word narrower, so the later oversized word still fails.
This example never splits a word arbitrarily. A teaching task requiring syllabic or other segmentation needs an explicit policy. Failure means that the current frame, font and content cannot satisfy the contract, not that the sentence is inherently wrong. The author can then choose a wider frame or revise the wording deliberately.
Do not discard instructions to meet a line limit
A generator can succeed while silently losing the remainder of an instruction. Wrap raises when max_lines is exceeded, and baselines raises when the final text baseline crosses reserved bottom space. Horizontal fitting and vertical placement are independent checks; neither substitutes for the other.
Changing a font can change the line count, so the result must be regenerated. The example declares leading and baselines without measuring every glyph’s actual height. A generous frame and actual rendered inspection complement the numeric checks. Someone still needs to read the finished page after automated geometry validation.
Leave an actual PDF as evidence
The new single-page PDF contains an original English instruction and circle, square and triangle. It imports no worksheet sentence, image or lesson photo. Creation requires an explicit destination, while the records runner writes no PDF. This separates document authoring from the viewer’s behavior after download.
Extraction confirms the instruction and notice remain present, then the entire page is rendered and visually inspected. Heading, body, shapes, cutting guide, footer and numbering are separated. Actual printer scaling and physical use were not checked; the result description preserves that boundary instead of converting a screen inspection into a print claim.
Keep the adaptation questions visible
Twelve tests passed in source and fresh extraction, including word preservation, long-word position, line limits, bottom bounds and dash endpoints. PDF creation requires ReportLab 4.4.9; pure geometry tests use the standard library. The download also includes the actually inspected synthetic PDF.
Adapting another worksheet requires asking whether shortening a sentence changes its learning purpose. Forcing content into a smaller font is not an automatic solution. I want a generator to preserve meaning and make necessary layout decisions visible, rather than merely produce a successful-file message.
Return a useful failure to the maker
A stopped generator should tell the operator which constraint failed. A long word and too many lines suggest different remedies, such as revising content or changing the frame. The example errors are developer signals rather than finished visitor-facing copy. A real authoring screen should translate them into understandable guidance while preserving the constraint, giving the next editor a reasoned decision instead of silently exporting an incomplete file.