DEV Community

OMML vs LaTeX: Native Math in Word for IEEE Submissions

If you write papers in Word and submit to IEEE venues, you've hit the math problem: your beautiful equations either survive as native editable math or get flattened into blurry images. The difference comes down to OMML — Office MathML — and most Word users have never heard of it. Let's fix that.

What OMML actually is

OMML (Office Math Markup Language) is Word's native equation format — the stuff you create with Alt+=. Unlike an image of an equation, OMML math is:

  • Editable — click it, change a symbol, done. No re-rendering.
  • Resolution-independent — crisp at any zoom level, in print and PDF.
  • Accessible — screen readers can parse it; they cannot parse your PNG.
  • Searchable — symbols are text, so they survive find/replace and indexing.

LaTeX users get all of this for free with $...$. Word users get it only if their equations are genuine OMML objects — and this is where submissions go wrong.

How equations get destroyed

Three common killers:

  1. Copy-paste from PDFs. You grab an equation from a published paper, paste it into Word, and get an image. It looks fine at 100% zoom and terrible everywhere else.
  2. Converters that rasterize. Some Word-to-PDF or format-conversion pipelines flatten OMML into images "for compatibility." Your source was perfect; the output is mush.
  3. Collaborator chaos. Your co-author "fixes" an equation by screenshotting it, cropping in Paint, and pasting the image back. (We've all been there. Forgive them.)

The practical workflow

Here's what I do for IEEE submissions with heavy math:

  1. Author equations natively with Alt+= from the start. If you must import from LaTeX, use a proper converter — Word's built-in LaTeX-to-OMML paste works surprisingly well for standard notation.
  2. Audit before converting formats. Before running your manuscript through any IEEE format converter, zoom into every equation at 200%. Pixelation means it's an image — replace it now, because no converter can reconstruct math from pixels.
  3. Verify after conversion. Re-check zoom levels in the output PDF. A converter worth using preserves OMML end-to-end; if your sigma turned into a smudge, the pipeline flattened it and you need a better one.
  4. Embed fonts on PDF export. Even perfect OMML can break if the PDF substitutes Cambria Math with something weird. Embed fonts every time.

What about MathType and other equation editors?

MathType equations are convertible to OMML (MathType has a toggle for it), but the default paste behavior in many setups produces images or OLE objects that behave like images. If your document is full of MathType objects, convert them to OMML before doing anything else. Same rule applies to equations pasted from web pages. Normalize everything to OMML in the source document, and every downstream step gets easier.

Why this matters beyond aesthetics

Reviewers zoom. Editors print. And increasingly, publishers run automated checks on submissions — flattened equations can trip accessibility validators that some venues now enforce. Native math isn't polish; it's compliance.

The deeper point: your equations are the densest information in your paper. Treating them as second-class images while your prose gets full typographic care is backwards. Spend the ten minutes to keep them native. Your future self, squinting at page proofs at midnight, will be grateful.

Top comments (0)