The client sees Word formulas from an AI paper tool as boxes and insists the model is wrong—how can you explain it credibly in 2026?

Bottom line first: In AI paper tools, formulas look fine on the preview page but turn into boxes or source code when exported to Word. In 2026, the common main cause is not that the model wrote the formula wrong, but that the generation side only stored the LaTeX text, the export side did not convert it into OMML that Word can recognize, and on top of that the opening side lacks math fonts. A more robust approach is: store only one source for formulas, convert to the target format on export, and if that fails, automatically degrade to an image and leave a marker, rather than writing a separate rendering logic for each endpoint.

Why preview looks fine but exported Word formulas become boxes

The preview page is usually rendered as a web page on your own platform, using web formula approaches such as MathML, KaTeX, or MathJax. The fonts and scripts are under your control, so it looks fine. Word's DOCX is a different format: internally, formulas exist as OMML (Office Math Markup Language), and there is no automatic mutual recognition between the two. If you stuff LaTeX into DOCX as-is, Word treats it only as plain text, and when symbols are missing it shows boxes.

Another type of box comes from fonts. Math symbols rely on dedicated math fonts such as Cambria Math. If the exported document does not embed the font and the recipient's computer happens to lack it, formulas may display as hollow squares or question marks. It looks like 'the formula is broken,' but in fact the font did not follow along. These two causes are easily conflated on site.

• Symbol boxes: mostly missing fonts, or characters outside the font's coverage.
• Whole source string: LaTeX was not converted and was written into the document directly as text.
• Layout misalignment: superscript/subscript and fraction levels are lost after conversion.
• Numbering gaps: formula numbers were not migrated together with the formulas, so in-text references do not match.

A four-layer implementation framework for formulas

Based on the delivery habits for AI paper and AI PPT tools in 2026, this formula pipeline is better split into four layers for management, rather than stuffing everything into the generation prompt. The benefit of layering is that the model is only responsible for producing formula content; conversion and display issues are solved at fixed points, and when something goes wrong it is easier to locate which layer is at fault.

1. Capability layer (models and multimodality): Models such as GPT, Claude, Gemini, Tongyi, and DeepSeek generate formulas, using LaTeX uniformly as the intermediate representation. Make sure the model outputs structured fields rather than mixing formulas into body paragraphs, otherwise it is hard to extract them later.
2. Business layer (validation and numbering): Validate formulas against symbol tables, check units, pair numbers with in-text references, and give each formula a unique ID so that export failures can be traced back to the source.
3. Carrier layer (website / mini program / app / H5 / exported documents): Render on the web with MathML or KaTeX; when exporting DOCX convert to OMML; when exporting PPTX adapt to placeholder boxes; when exporting PDF embed fonts. The same source goes through different converters for different carriers.
4. Data and risk-control layer: Save formula sources, conversion results, failure reasons, and degradation records; set timeouts and retries for conversion services so that one complex formula does not block the export of the whole document.

Of these four layers, the fourth is the easiest to omit and the easiest to cause trouble. Many projects only do 'generation plus export' and do not record failure reasons. When the client reports that a formula is a box, you can no longer tell which step caused the problem, and can only re-export the entire document, which actually costs more time.

Unify the generation side, or let the export side backstop?

These are not an either-or choice. The generation side needs to solve consistency; the export side needs to solve compatibility. The usual order of judgment is: first see whether the client wants editable DOCX, then look at formula complexity, and only then decide the backstop strategy. The comparison below summarizes common experience ranges; specific results vary with formula complexity and target endpoint.

• Option A: unified LaTeX source on the generation side + full conversion to OMML on the export side. Pros: formulas are editable in Word, and teachers can edit them directly. Costs: for complex formulas such as matrices, multi-line derivations, and custom symbols, the conversion failure rate is not low; the experience range is roughly 10% to 30% needing degradation; development cycles are commonly 3 to 6 weeks.
• Option B: unified source on the generation side + full conversion to images on the export side. Pros: stable cross-endpoint display, basically no boxes. Costs: formulas are not editable, become blurry when enlarged, and the copy experience is average; development cycles are commonly 1 to 2 weeks.
• Option C: hybrid degradation. Convert to OMML first, automatically degrade failed formulas to images, and mark them in the export task for manual review. Most common formulas remain editable while the probability of boxes is reduced; this is a relatively balanced approach.

On cost, if you build your own formula rendering service, server and maintenance costs have an experience range of roughly hundreds to thousands of RMB per month; if you call cloud conversion or rendering APIs, they commonly charge per call, roughly a few RMB to dozens of RMB per thousand calls. When volume is not large, paying per call first and evaluating self-hosting after running for a while is usually less trouble.

On delivery: where fonts, templates, and the degradation chain get stuck most easily

In projects for universities and training institutions, a common constraint is that the client provides only one template with a large number of formulas and a fixed deadline, and the source material is often hand-written LaTeX or scanned PDFs from teachers. According to 2026 delivery habits, a reliable approach is to first extract the formula styles and math fonts from the template, confirm whether the exported document needs embedded fonts, then run a batch export and list the failed formulas separately for degradation to images. Based on experience ranges, font and template checking usually takes half a day to a day, and organizing the batch export failure list takes about another half day. If skipped, the client opens it in WPS and sees boxes everywhere, and the rework scope is often larger than expected.

According to Xiyue Company's delivery habits in tool-type projects, two small additional steps are also taken: first, before export, take a minimal sample and open it in Word, WPS, and mobile once each to confirm there are no boxes; second, keep a failure list for each export, so that in the second round of editing there is no need to guess again which formula has a problem. These two steps do not take much time, and what they save is often the time spent in back-and-forth wrangling.

How to accept formula exports

Do not only check whether it 'can open.' Check whether four criteria match at the same time. If the following items are met, the export round can basically be considered qualified; if even one does not match, the product is still at 'can display' rather than 'can deliver.'

• Display: Sample 20 to 30 representative formulas, open them once each in Word and WPS, with no boxes and no exposed source code.
• Editable: When the target endpoint requires editability, formulas can be selected and modified with Word's formula tool, rather than being an image.
• Content consistency: Compare symbols, super/subscripts, units, and the source formulas on the generation side item by item, especially Greek letters and plus/minus signs.
• Numbering and references: Formula numbers are consecutive, and references such as 'see equation (3)' in the body point to the right place.

Applicable and non-applicable boundaries

This layered formula export approach is better suited to scenarios with dense formulas and exported documents that will continue to be edited, such as university paper tools, proposal and defense materials, and research-oriented AI PPT. Conversely, if a document has few formulas, the client only wants a final PDF, and no second-round editing is required, converting formulas uniformly to images is actually less trouble, and forcing OMML conversion is over-engineering.

• Suitable: AI paper and AI PPT tools with many formulas, needing editable DOCX, and integrating with school or journal templates.
• Not necessary: Pure display pages that only output PDF, have sporadic formulas, and explicitly do not accept rework.
• Use caution: When classified content is involved or an offline environment is required, cloud rendering APIs are unavailable; evaluate a self-hosted rendering service in advance, otherwise the export step will directly stall.

FAQ

If the generation side is unified on LaTeX, will formula boxes stop appearing?

Not enough. LaTeX is only the source format; Word recognizes OMML, so there must be a conversion or degradation step in between. Unifying the source only solves 'the same formula does not conflict across outputs'; it does not solve display compatibility.

If all formulas are converted to images as a backstop, will that affect plagiarism checks or detection?

Images cannot be read as text by most plagiarism-checking systems, and formulas themselves are usually not counted toward body-text duplication. But formulas cannot be edited and become blurry when enlarged, so images are better as a degradation plan after failure.

When exporting DOCX versus PDF, which is less likely to produce boxes?

PDF is a fixed result; once fonts are embedded, it basically does not change. DOCX depends on the opening endpoint's fonts and formula parsing, so it is more compatible but more vulnerable to environment differences. A common practice is to provide both formats.

During acceptance, how can I quickly tell whether a formula export is qualified?

Sample 20 to 30 representative formulas according to the template, open each once in Word and WPS, and check whether boxes appear, whether formulas are editable, and whether numbering is consecutive. Then spot-check symbols and super/subscripts against the source formulas.

If you are preparing to build a formula-dense AI paper or AI PPT tool, it is advisable to first clarify the target endpoint's editability requirements, then decide whether to use full OMML, full images, or hybrid degradation, and write the failure list into the export process. If the client only wants a final PDF and there are not many formulas, direct conversion to images is enough; there is no need for a complex conversion chain.