A PDF has no words in it: 'edit one word' is not a string operation

The order of operations is what breaks the estimate. Nothing gets replaced until the logical text has been rebuilt from positioned glyphs, the target located inside that reconstruction, the specific drawing operations that produced those glyphs identified and removed, and something new drawn so that it looks like it was always there ^[4]. Four passes over the page before one character changes.

Then the attributes, each with its own way of going wrong. Size is the clearest trap: the number after Tf is not the rendered size, because the text matrix scales it, so a heading written as Tf 1 inside a matrix scaled by 24 renders at 24pt while a naive read returns 1 ^[6]. Baseline has almost no tolerance; a couple of points high is visible to any reader even when font and size are exact ^[7]. Colour fails specifically on scans, where sampling one page-wide background colour eventually paints white blocks onto cream paper ^[8]. Add the availability check, since a PDF normally embeds only the glyphs the page already used ^[18], and the floor for replacing a single word is five determinations, four of them estimated rather than read ^[1].

The bug the developer describes is the part to carry into your own planning meeting. Serif detection was a substring test for "times" or "roman". LaTeX embeds a Times clone named NimbusRomNo9L: it contains Rom, not roman, so serif documents were classified as sans and replaced with Helvetica ^[13]. Computer Modern's CMR10 and CMBX12 fail the same test ^[14]. The same naming assumption broke weight detection, because Nimbus spells its bold weight -Medi ^[15]. Two comparisons, two separately visible defects in the output ^[2].

What kept it alive was the corpus. The generated test files came from a library that emits clean TrueType with tidy names, so they could not produce the failing case, and the bug was declared fixed three times against them ^[11][16]. One real paper downloaded from arXiv found more than a week of synthetic cases, according to the same account ^[22].

This generalises past one codebase because the format itself records no paragraphs and no lines, and nothing in it marks a set of glyphs as belonging together; the structure a human sees is inferred by whatever software reads the file ^[3]. The estimator is not a shortcut someone took under deadline. It is the permanent centre of the feature, and its accuracy is the feature's accuracy.

Which is why the acceptance criterion matters more than the API surface. "Did the edit apply" is the wrong question ^[24]. The question is what the page looks like afterwards, and answering it needs a renderer or a person, not a return code.