Legacy .doc: text-box subdocument (ccpTxbx) is never read — documents built around a text box render blank
I've attached a .doc file that doesn't render well.
@extend-ai/[email protected]. Parser-level — reproduces via buildDocModelFromBytes, no React involved. .docx text boxes are fine.
Problem
A .doc WordDocument stream is split into subdocuments, each with its own FIB character count. The parser appears to read only ccpText and ignore ccpTxbx, so a document whose visible content is a floating text box comes back empty — with warnings: [].
FIB from a real failing file (a financial-statement cover page):
ccpText = 5 ← all the parser returns ("JC" + marks)
ccpHdd = 25
ccpTxbx = 169 ← the entire visible page, dropped
Headers are unaffected: another file in our set has ccpHdd = 633 and that text extracts fine, so this looks specific to the text-box range rather than to subdocuments generally.
Repro
Any .doc with body text plus a floating text box (soffice --convert-to doc from an ODF file containing a draw:text-box produces one; happy to attach ours).
const { model } = await buildDocModelFromBytes(bytes);
// nodes=2 warnings=[] runs=["XY"] ← body text only; the 3 text-box lines are gone
soffice --convert-to pdf on the same bytes renders the text box, so the content is readable.
Impact
All 56 .doc files in a real audit corpus, parser output diffed against a LibreOffice render:
| files | |
|---|---|
| Fine (≥95% of reference text) | 47 |
| Minor loss | 1 |
| Near-blank (≤13%) | 8 |
All 8 are cover pages, and every cover page in the corpus is one of them. Cover pages are conventionally a single text box — and they're the first file in every financial-statement binder, so this is disproportionately the first thing a user opens. Blank reads as "corrupt".
Ask
Full text-box support ideally. Failing that, a warning when a non-ccpText range is non-zero and skipped is the high-value fix on its own — it would let us fall back to a download instead of rendering a blank page. Right now nothing distinguishes "empty document" from "content dropped".
Two smaller notes: the same cover pages' border and logo don't survive either (no image runs at all), suggesting the Office Art layer is unread generally. And a .docx whose text box is wrapped in mc:AlternateContent (what Word 2010+ emits) dropped it the same way for us — but our only reproducer there is LibreOffice-generated and no real .docx we sampled used that form, so treat it as a lead, not a confirmed bug.
.doc support in 0.7.0 let us delete a whole server-side LibreOffice conversion service — thanks for that. This is the one gap left. Glad to run a patch against our 56-file corpus before you cut a release.
Source: extend-hq/ui