Word-exported PDFs can silently
drop equations

The failure

Papers written in Microsoft Word with the legacy Equation Editor 3.0 (or with equations pasted as OLE objects from older documents) can lose those equations during PDF export. Two failure modes:

• Blank space. The equation area is empty, or contains a 1–2 pixel sliver image. The equation number sits alone on its line: (3) with nothing to its left.
• Glyph garbage. The equation renders as punctuation soup: E!"#$= y+…. The glyph IDs survived but map to the wrong characters.

Every standard check passes, which is what makes this failure dangerous. pdffonts reports all fonts embedded because it inspects only font objects, and the missing equation is not a font problem; the content never made it into the PDF's content stream. Acrobat opens the file without warnings. Print preview matches the broken PDF exactly, so print and screen fail identically. The author, who usually checks their export by scrolling past page 1, ships it.

For the volume editor, the problem multiplies with every paper, and nobody reads a hundred-plus papers equation by equation before printing.

Why repair is not possible

The equation content is absent from the PDF. There is nothing to fix in the file. The only remedy is a corrected export from the author's source document, usually after converting the legacy equations to Word's current equation format (or exporting via a different route, such as a PDF printer driver). This means detection has to happen while authors are still responsive: at submission, not the week the volume goes to print.

Detection recipe

Fully automatic detection produces false positives, so the recipe is: cheap automatic screening, then a targeted visual check of the flagged spots, which takes minutes per volume instead of days.

Step 1: Find orphan equation numbers

Extract the text and flag lines that consist of only an equation number:

$ pdftotext paper.pdf - | grep -nE '^[[:space:]\-–—_;,.]*[\[(][0-9]{1,2}[\])]$'

This over-flags: a real equation often extracts to a separate line from its number, depending on how the extractor orders the text. Treat hits as candidates, not verdicts.

Step 2: Measure ink where the equation should be

For each flagged line, render the page and measure the non-white pixel fraction in the band left of the equation number. mutool draw -F stext gives you the line's bounding box; mutool draw -r 150 -o page.png renders the page:

$ mutool draw -F stext -o layout.xml paper.pdf 4   # bbox of the flagged line
$ mutool draw -r 150 -o page4.png paper.pdf 4      # render to measure ink

An ink fraction below about 0.005 in the equation band, with no plausible glyphs, means blank. Short real equations can land at 0.005–0.01, so crop the borderline bands and stack them into one image for a single visual pass. Confirming 20 crops takes a minute.

Step 3: Sliver images

Broken OLE objects sometimes leave a degenerate image behind. List images and flag any with width or height ≤ 4 px:

$ mutool info -I paper.pdf

Step 4: Glyph garbage

The second failure mode is greppable as long runs of punctuation in the extracted text:

$ pdftotext paper.pdf - | grep -nE '[!\"#$%&'"'"'()*+,./-]{4,}'

What to tell authors

When a paper is flagged, the fix on the author's side is usually one of: convert legacy equations to Word's current equation format (open the .docx in a current Word, which offers the conversion), re-insert the equations, or export through a different PDF path. Ask the author to visually compare every equation in the re-exported PDF against their source, because the export can succeed for nine equations and fail on the tenth.

Screening a whole volume

The recipe scripts cleanly across a folder of papers, and that is how it should run: as an automatic screen at upload time, when the author is still there to fix it. Ready.Pub is building this equation-integrity check into its upload compliance pipeline alongside page-size, margin, and font-embedding checks. See the proceedings page for the full workflow.