A hardcoded /Length turns a byte-exact PDF into a parse error

A strict PDF reader does not go looking for `endstream`. It seeks past the `stream` keyword, reads exactly as many bytes as `/Length` declares, and expects the closing keyword at the cursor. Declare 44 over a stream that measures 38 ^[5] and it consumes six bytes that were never part of the stream ^[22], then errors where the keyword should have been ^[7]. Lenient viewers scan instead of trusting the field, which is why the same bytes rendered in a browser and were refused by Acrobat and pypdf ^[6]. The second defect in the same object was quieter: `/Resources << >>` was empty while the content stream drew text with `/F1`, and viewers substitute a font silently rather than complain ^[8].

Both fields are the same category of mistake. `/Length` and the cross-reference offsets restate information the assembled bytes already contain, so the fix is to measure rather than predict, recording `body.length` for each object as it is appended ^[9]. That is a one-line change in the assembly loop, and it is the part of this writeup that generalises furthest.

Where padding may go is not the generator's choice. It is whatever region the format designates as ignorable. For PDF that is after `%%EOF`, which a conforming reader is required to skip ^[10]. For DOCX it is an XML comment before the closing tag, which python-docx and openpyxl both accept while the byte count stays exact ^[12]. For PNG it is a `tEXt` ancillary chunk before `IEND` with a correct CRC-32, because decoders skip ancillary chunks they do not know ^[13]. For JPEG it is `FFFE` COM markers holding up to 65,533 bytes each, chained, placed immediately after SOI ^[14]. That capacity sets the shape of the work: 25 MB of COM padding is at least 401 chained markers ^[23], and every library that walks the marker chain walks all of them. The author reports that padding near EOI decoded unreliably across libraries, that moving it fixed the problem, and that he never root-caused why ^[25]. That is an unexplained workaround, and saying so plainly matters more than inventing a tidy explanation.

The floors table describes one generator's output shape, with numbers specific to it: 69 bytes for JSON, 114 for XML, 170 for SVG, 600 for PDF ^[26]. Those numbers transfer only when your minimum document matches the same top-level structure, the same key or element names, and the same declarations; the failure mode, not the byte count, is what actually carries over to other generators. A 20-byte JSON request sits 49 bytes under that floor ^[27], and the generator quietly emitted whitespace of exactly the right size that failed `JSON.parse()` ^[16]. Rounding up and saying so is the honest answer.

PPTX is where generation from spec stopped paying. A minimal deck needs presentation.xml, presProps.xml, a slide master, a slide layout and a theme, with the master and layout referencing each other, and a small error produces a repair prompt ^[17]. The author now ships a known-good deck as a static asset, clones its blank slide, and patches three files ^[18]. Sizing comes from a binary search on `ppt/pad.xml`, an orphan part covered by the default XML content type and referenced by nothing ^[19]. The byte budget now rests on a reported behaviour: PowerPoint ignores unreferenced parts entirely ^[19].

The through-line is the acceptance test. Every bug listed passed the test the author was running ^[21]. A fixture that only opens in Word is a fixture for a human. The pipeline is run by something else ^[24].