Software · Open design · · Deep Quantum Science

How to build a Word ⇄ LaTeX converter: the design of DeepQ Manuscript

The architecture and the algorithms behind DeepQ Manuscript, explained step by step with figures and pseudocode. Free to read, reuse and build upon.

Dieser Artikel ist auf Englisch verfügbar.

DeepQ Manuscript: free trial, 5 conversions each wayWindows 10/11 · runs locally

Scientists write in two worlds. Many collaborators, journals and funding agencies expect Word; most physicists and mathematicians write in LaTeX. Moving a manuscript between the two by hand means retyping equations, renumbering references and rebuilding the bibliography. DeepQ Manuscript automates this, in both directions. In this article we describe how it is built, so that anyone can understand, reproduce or improve the approach. We show the architecture and the algorithms; we do not publish source code.

1. Why naive conversion fails

A document is more than its text. The hard parts are the semantics that the two formats store very differently:

ElementLaTeXWord
EquationsTeX source, user macros (\newcommand)Office Math (OMML) objects
Numberingcomputed at compile time from \labelfields, bookmarks, or plain typed numbers
References\ref, \eqref, \citeREF and citation fields, or plain text
BibliographyBibTeX databasesource records in a hidden XML part
Projectmany files (\input, figures)one container (DOCX = ZIP of XML)

A good converter must therefore understand the document, not just copy text. Our design rests on four principles:

  1. Local first. Manuscripts are confidential before publication. Everything runs on the user's computer; no cloud.
  2. Parse, never execute. A LaTeX file is a program. We read it as data and never run it during conversion.
  3. One neutral representation. Both directions go through the same document tree, so every improvement helps both ways.
  4. Honest output. When something cannot be converted safely, keep it visible and report it, rather than silently dropping it.

2. The pipeline

Pipeline: input, safety gate, pre-processing, document tree, semantic passes, writer, post-processing, check and report
Figure 1. Every conversion follows the same eight stages.

The central object is a document tree (an abstract syntax tree, AST): headings, paragraphs, equations, figures, tables, citations and links as typed nodes. We use the open-source universal document converter Pandoc to read a source into this tree and to write the tree into the target format. Our own work lives around it: preparing the input so that nothing is lost on the way in, enriching the tree with semantics, and repairing the output so that it behaves like a document written by hand.

Algorithm 1 · Conversion

input  source file S, options O
output converted document T, report R

check S with the safety gate                            # Algorithm 2
if S is a Word file:
    plant markers for captions, bookmarks, fields   # Algorithm 6
else:                                               # LaTeX file or project
    flatten the project into one source              # Algorithm 3
    collect user math macros
    build the cross-reference plan                   # Algorithm 4
tree ← parse(S)                                      # sandboxed, no execution
apply semantic passes to tree: math, references, bibliography, figures
T ← write(tree)
repair T in its native format                        # Algorithms 5 and 7
R ← quality checks (+ optional PDF build)
return T, R

3. The safety gate

Word files and LaTeX projects arrive as ZIP archives, and ZIP archives can be hostile: a tiny file that expands to gigabytes, or entries that try to write outside the working folder.

Algorithm 2 · Safe archive

reject if file size > 30 MB
for each entry e in the archive:
    reject if total expanded size > 100 MB or number of entries > 1000
    reject if path(e) is absolute, contains "..", a drive letter or a backslash
    reject if e is a symbolic link
extract into a fresh private working folder

Parsing then runs in a sandbox mode that forbids reading or writing files the parser was not explicitly given, with a time limit. When a PDF is requested, the LaTeX compiler runs with shell escape disabled.

4. LaTeX to Word

Flattening. Real projects split the text into chapters with \input and \include. We merge them into one source, but only inside the project folder, with a size budget and protection against files that include each other in a loop. Commands that could read or write files, or run programs, are refused.

Algorithm 3 · Flatten a project

flatten(file f, visited V, budget B):
    if f ∈ V or f is outside the project root: stop (cycle or escape)
    if |V| > 30: stop (nesting too deep)
    text ← read(f); B ← B − size(text); if B < 0: stop
    remove comments
    reject primitives that touch files or run commands
        (\write18, \openout, \read, \directlua, \catcode, ...)
    for each \input{g} or \include{g} in text:
        replace it by flatten(g, V ∪ {f}, B)
    check that every \includegraphics path stays inside the project
    return text

Cross-references. LaTeX numbers equations, figures and sections only when it compiles. Word has no compiler, so we compute the numbers ourselves, in two passes, for a chosen numbering scope (continuous, per chapter, per section).

Two-pass cross-referencing: assign numbers, then replace references
Figure 2. Pass 1 builds a table from labels to numbers; pass 2 rewrites every reference as the number plus a clickable link.

Algorithm 4 · Cross-references

# pass 1
counters ← 0 for sections, equations, figures, tables
walk the source in reading order:
    on a heading at depth d: increment its counter, reset deeper ones
                             (and the equation counter if the scope says so)
    on a numbered equation, figure or table: increment its counter
    on \label{k}: table[k] ← (kind, current number, anchor)
# pass 2
for each \ref{k}, \eqref{k}, \autoref{k}:
    if k ∈ table: replace by its number (in parentheses for \eqref) + link
    else: write "??" and list k in the report

Mathematics. Each equation is converted to Office Math. Before that, user macros are expanded (with a depth limit, so a recursive macro cannot hang the program) and unusual environments are mapped to standard ones. If an equation still cannot be converted, it is not dropped: it stays in the Word file as clearly marked LaTeX text, and a file EQUATIONS_TO_REVIEW lists each one with the reason. This "graceful degradation" is what makes the tool trustworthy on real manuscripts.

Numbered equations in Word. Word has no built-in equivalent of a centred equation with its number on the right margin. We build it from an invisible three-column table whose width is computed from the page margins and columns of the current section.

A numbered equation laid out as a borderless three-column table
Figure 3. Spacer, centred equation, number: the classic layout of a numbered display equation, rebuilt in Word.

Algorithm 5 · Number display equations in Word

for each display equation E in the Word XML:
    W ← page width − margins, divided by the number of text columns
    n ← its number from the cross-reference table (or the next number)
    replace E by a borderless table with column widths
        (c, W − 2c, c), c ≈ W/12:  [ empty | E centred | "(n)" ]
    no borders, no cell margins, row may not split across pages

5. Word to LaTeX

The difficulty in this direction is that the parser keeps the visible text but forgets much of the meaning: which paragraph is a caption, which bookmark a reference points to, which citation field belongs to which source. We solve this with markers.

Algorithm 6 · Recover Word semantics with markers

P ← a random prefix (so markers cannot collide with real text)
for each caption, bookmark, REF field, citation field in the Word XML:
    insert an invisible text marker P+id before it
    record id → {kind, label, field instruction, source key}
tree ← parse(modified Word file)
for each marker found in the tree:
    look up its record and rewrite the node:
        caption   → figure or table caption + \label
        bookmark  → \label on the heading or equation
        REF field → \ref or \eqref
        citation  → \cite{key}
remove all markers; report any that could not be resolved
bibliography ← Word source records converted to a BibTeX file

Word's own bibliography list is removed when its source records are available, because those records are the authoritative data; otherwise the list would appear twice.

6. The round trip

A frequent workflow: the author writes in LaTeX, a co-author comments in Word, and the text comes back to LaTeX. Some LaTeX information has no place in Word (label names, BibTeX entries, the numbering scope). We store it in a small hidden manifest inside the Word file (a custom XML part, which Word preserves when the document is edited). When the file is converted back, the manifest restores labels and bibliography.

Round trip LaTeX to Word to LaTeX with a hidden manifest
Figure 4. The hidden manifest carries what Word cannot represent.

7. Figures and the optional PDF

  • Single-page PDF figures, common in LaTeX, are rendered as images at up to 300 dpi for Word.
  • In the other direction, images can be exported as PNG, JPEG or PDF; PDF output embeds the pixels losslessly (it does not invent vector graphics, and the report says so).
  • On request, the exported LaTeX project is compiled to PDF (several compiler passes plus BibTeX). The compiler log is translated into readable diagnostics: missing packages, undefined references, overfull lines.

Algorithm 7 · Quality report

R.counts      ← equations, figures, tables, citations in source and result
R.math        ← normalised, coloured, numbered, failed equations (with reasons)
R.references  ← resolved / unresolved labels
R.pdf         ← compiler passes and parsed diagnostics (if requested)
R.warnings    ← everything that needs a human look, without duplicates
write R as CHECK_REPORT.txt and report.json next to the result

The report explicitly states what the checks do not guarantee: they detect structural problems and compiler messages, but they are not a measure of visual or mathematical fidelity. A careful human review remains part of the workflow.

8. The desktop application

Desktop window, local service and conversion engine
Figure 5. A native window displays a local web interface; a local service runs the engine.
  • Interface. A small native launcher opens a window with an embedded web view. The interface is ordinary HTML, which makes it easy to design and translate.
  • Local service. The engine runs behind a service that only listens on the computer itself (127.0.0.1) and requires a secret token created for each session, so other programs or websites cannot use it.
  • Self-contained. The installer ships its own language runtime and converter, so users install nothing else. Every third-party component is downloaded once and verified against a known checksum before it is packaged.
  • Licensing without servers. A licence key is a small signed statement. The application contains only the public key and checks the signature offline; the private key never leaves the issuer. The free trial is a local counter of 5 conversions per direction.

9. Limits and lessons

  • Legacy equation objects (old Equation Editor, MathType OLE) are not editable math and are reported rather than converted.
  • Tracked changes are accepted during conversion; page references are not supported.
  • New installers are flagged by Windows SmartScreen until they build a reputation or are code-signed: distribution is part of engineering.
  • The most valuable feature turned out to be the report. Users forgive a converter that tells them exactly what to check; they do not forgive one that silently changes their science.

We hope this blueprint helps others build better tools for scientists. If you build on it, we would love to hear about it.

Licence. The text and figures of this article are released under the Creative Commons Attribution 4.0 licence: you may copy, adapt and reuse them, including commercially, as long as you credit Deep Quantum Science. The conversion relies on the open-source Pandoc project, whose authors we thank.
← All articles← Alle Artikel