DOCX and PDF are not interchangeable containers when a document contains equations. A DOCX must preserve editable Word structures. A PDF must preserve the visible printed result. AIText2Doc initially treated PDF as a secondary conversion problem; testing showed that the PDF engine is part of equation correctness.
This case study records the approaches tested during development and why the current workflow uses browser-generated DOCX output and headless Chromium for PDF.
The requirement
A successful export had to preserve:
- Fractions with a visible horizontal line.
- Superscripts and subscripts on the intended symbols.
- Chemistry charges and molecular indices.
- Isotope mass and atomic numbers before the element.
- Bullet and numbered list types.
- Page margins, repeating footers, and page numbers.
- Accented French text.
- Editable equations in Word.
The same source text had to look structurally equivalent in preview, DOCX, and PDF even though each output uses a different rendering engine.
Why the DOCX path worked first
The browser already had the parsed document structure and equation representation. Generating the DOCX on the client allowed the converter to package headings, paragraphs, lists, and OMML equation objects directly.
This provided two important properties:
- The pasted text did not need to be sent to the server for DOCX generation.
- Equations remained editable rather than becoming screenshots.
The Word file therefore became the editable source of truth. Users could change an equation, apply heading styles, add comments, and use Track Changes.
The PDF requirement was different. Printing the DOCX on a Windows machine produced a visually correct PDF, but a shared-hosting Linux server does not have Microsoft Word's equation renderer.
Experiment 1: generate PDF directly with mPDF
mPDF is useful for conventional HTML documents, but the first equation-heavy tests exposed limits.
Observed problems included:
- Raw LaTeX appearing where the HTML did not contain a supported mathematical structure.
- Superscripts and subscripts becoming plain baseline characters.
- Fractions rendered as linear text.
- Chemistry expressions losing the distinction between molecular indices and charges.
- Complex expressions requiring custom HTML reconstruction.
We added targeted HTML structures for some cases. This improved simple scripts and units but created a maintenance problem: every additional mathematical command required another approximation. A fraction built with HTML tables might look acceptable in one example and fail when nested inside another expression.
mPDF remained useful as a fallback during development, but not as the high-fidelity engine for the product's main promise.
Experiment 2: create a DOCX and convert it with LibreOffice
The next approach matched a common server workflow:
- Generate the correctly formatted DOCX.
- Open it headlessly with LibreOffice.
- Export it using the Writer PDF filter.
A unique LibreOffice user profile was created for each conversion to avoid profile locks when multiple requests ran at the same time.
This approach preserved ordinary paragraphs, headings, and lists. Equations were the problem. The server used LibreOffice 6.4 on Linux, while the source equations were OMML structures designed for Microsoft Word. Some expressions became readable linear text, but more complex scripts, chemistry, and fractions differed from Word.
Observed failures included:
- Charges attached to the wrong token.
- Unexpected characters inside equations.
- Chemistry symbols split into separate italic variables.
- Fractions flattened or rearranged.
- Correct DOCX output producing an incorrect server PDF.
The lesson was important: generating a temporary DOCX does not guarantee that another office suite will print it exactly as Word does. The converter and the PDF printer still need compatible equation models.
Experiment 3: print MathML with headless Chromium
The browser preview already rendered the mathematical structure users expected. Printing that same structured HTML with Chromium avoided translating Word equations through a second office suite.
The server installation used headless Chromium on ARM Linux. The first command-line print tests produced a PDF, but native browser headers and footers added the date and local document path. Multi-page documents also needed stable margins and a custom footer.
The production workflow moved to Puppeteer controlling the installed Chromium binary. This allowed the PDF request to specify:
- A4 page size.
- Top, right, bottom, and left margins.
- Background printing.
- Custom footer text.
- Page number and total page count.
- Disabled native URL and date headers.
Chromium's MathML rendering preserved the fraction bar, scripts, isotope layout, and chemistry notation much more closely to the browser preview.
Why the PDF is not converted from the DOCX
The current PDF uses the same logical document as the DOCX, but it is not a printout of the DOCX file.
DOCX output follows the Word path:
AI text → parsed blocks → MathML structure → OMML → DOCX
PDF output follows the browser path:
AI text → parsed blocks → HTML and MathML → Chromium → PDF
Both paths share detection and normalization rules. They diverge at the final renderer because Word and Chromium require different native structures.
This decision avoids making LibreOffice responsible for interpreting Word equations and avoids asking mPDF to recreate a complete math layout engine.
A fraction that exposed the difference
The following reaction quotient was a useful regression case:
Q_{r,eq}=\frac{[\mathrm{H_3O^+}]_{eq}[\mathrm{CH_3CH_2COO^-}]_{eq}}
{[\mathrm{CH_3CH_2COOH}]_{eq}}A successful result needs more than correct characters. It needs a stacked numerator and denominator, a visible fraction line, chemistry subscripts, charges, and equilibrium indices.
The browser preview displayed the intended fraction. Early PDF approaches displayed the numerator and denominator linearly or omitted the line. Chromium preserved the structural fraction, making this expression a permanent regression case.
Multi-page footer testing
Equation correctness was not enough. Long documents revealed that ordinary HTML footers could appear in document flow rather than at a fixed distance from each page bottom.
The final PDF configuration reserves bottom margin for every page and uses the PDF engine's header/footer template. The footer contains AIText2Doc branding and page X of Y pagination.
This avoids:
- Content colliding with the footer.
- Branding appearing in the middle of a page.
- Native file paths remaining selectable in white text.
- Different footer positions on short and long pages.
When users should choose DOCX
Choose DOCX when you need to:
- Edit equations.
- Apply Word templates.
- Use Track Changes or comments.
- Reorganize sections.
- Build a table of contents.
- Reuse a worksheet or report later.
The DOCX is the best archival source because its semantic structures remain editable.
When users should choose PDF
Choose PDF when you need to:
- Print the document.
- Send a final non-editable version.
- Preserve pagination across devices.
- Attach a stable worksheet to a learning platform.
- Review exactly what students or readers will see.
For important documents, download both. Keep the DOCX as the source and distribute the PDF.
How we test both outputs
The AIText2Doc regression pack contains headings, bullets, decimal commas, units, fractions, chemistry, isotopes, and prose containing inline equations.
For each release, representative cases are checked in:
- Browser preview.
- Microsoft Word-compatible DOCX output.
- Chromium PDF output.
The compatibility matrix records current expectations and known limitations. A format is not marked supported merely because it renders in one output.
Current limitations
Chromium PDF output is visually stable but not an editable mathematical document. DOCX output is editable but may use different line breaks and fonts depending on the installed Word version and document theme.
Neither path currently exports Markdown tables, embedded source images, footnotes, or LaTeX packages that define custom commands. Worksheet-style arrays are intentionally blocked because they require a document-layout conversion rather than an equation conversion.
The practical conclusion
The correct export format depends on the job:
- DOCX is a structured, editable document.
- PDF is a stable rendered document.
- A reliable equation workflow should create each format through the renderer that understands its native structure.
The failed mPDF and LibreOffice experiments were useful because they showed that “convert the generated file again” is not the same as preserving mathematical meaning. Chromium solved the PDF problem by printing the same MathML structures already validated in preview.
For the complete user workflow, read the tested AI-to-DOCX guide. For equation internals, see the LaTeX, MathML, and OMML reference.