Wolfram Language Paclet Repository

Community-contributed installable additions to the Wolfram Language

Primary Navigation

    • Cloud & Deployment
    • Core Language & Structure
    • Data Manipulation & Analysis
    • Engineering Data & Computation
    • External Interfaces & Connections
    • Financial Data & Computation
    • Geographic Data & Computation
    • Geometry
    • Graphs & Networks
    • Higher Mathematical Computation
    • Images
    • Knowledge Representation & Natural Language
    • Machine Learning
    • Notebook Documents & Presentation
    • Scientific and Medical Data & Computation
    • Social, Cultural & Linguistic Data
    • Strings & Text
    • Symbolic & Numeric Computation
    • System Operation & Setup
    • Time-Related Computation
    • User Interface Construction
    • Visualization & Graphics
    • Random Paclet
    • Alphabetical List
  • Using Paclets
    • Get Started
    • Download Definition Notebook
  • Learn More about Wolfram Language

Parser

Tutorials

  • Building Language Front-Ends
  • Inside CodeAnalysis - How CodeStructure Parses C
  • Design and Compilation Strategy
  • Implementing the LaTeX Math Parser
  • MaTeX Comparison Showcase
  • The Parser Landscape - a Survey of What Exists Today
  • The Parser Zoo - language front-ends over a shared algebra
  • Parsing BNF Grammars (and bootstrapping a TPTP parser)
  • Parsing GrammarRules Locally
  • A Markdown Inline Parser in Parser Combinators
  • ParsingOpenQASM
  • Parsing TPTP, Auto-Generated from the Published BNF
  • PrattVsPEG
  • The Wolfram Box Typesetting Reference

Guides

  • Parsing in the Wolfram Language

Symbols

  • ASTAddSource
  • ASTAlgebra
  • ASTContainer
  • ASTLeafQ
  • ASTNodeQ
  • ASTStripSource
  • BinaryNode
  • BrainfuckAST
  • BrainfuckGrammar
  • BrainfuckRun
  • BrainfuckSemantic
  • CalculatorAST
  • CalculatorEval
  • CalculatorGrammar
  • CalculatorSemantic
  • CallNode
  • ContainerNode
  • EBNFParse
  • EBNFRules
  • ErrorNode
  • ExportLaTeX
  • GroupNode
  • InfixNode
  • JSONAST
  • JSONGrammar
  • JSONImport
  • JSONSemantic
  • LambdaAST
  • LambdaEval
  • LambdaGrammar
  • LambdaSemantic
  • LaTeXMathParse
  • LaTeXMathParser
  • LaTeXMathStyle
  • LeafNode
  • LispAST
  • LispGrammar
  • LispRead
  • LispSemantic
  • LispSymbol
  • MarkdownInlineParse
  • MarkdownInlineParser
  • MarkdownParse
  • MarkdownParser
  • ParseAction
  • ParseBetween
  • ParseChainLeft
  • ParseChainRight
  • ParseCharacter
  • ParseChoiceLongest
  • ParseChoice
  • ParseFail
  • ParseLiteral
  • ParseLookahead
  • ParseMany
  • Parse
  • ParseNotFollowedBy
  • ParseOperatorTable
  • ParseOptional
  • ParsePartial
  • ParsePosition
  • ParserCombinator
  • ParserCombinatorQ
  • ParserCompile
  • ParseRecursive
  • ParseRegex
  • ParseSepBy1
  • ParseSepBy
  • ParseSequence
  • ParseSome
  • ParseSucceed
  • ParseTry
  • PostfixNode
  • PrefixNode
  • RecCell
  • RecRef
  • SetRec
  • SpannedToken
  • TernaryNode
  • ToCodeParser
  • TPTPExport
  • TPTPImport

Overviews

  • WolframParser

MaTeX Comparison Showcase

What this note covers
Reading the comparison
Gold vs. parser, by tier
See also

What this note covers

LaTeXMathParse
turns LaTeX math into a Wolfram box tree that the front end then typesets. The natural question is: how close is that to what LaTeX itself would draw? This note answers it directly, with
MaTeX
as the gold standard.
MaTeX shells out to a real LaTeX installation and returns genuine Computer Modern output as resolution-independent vector graphics - the actual LaTeX rendering, not an approximation, and not a screenshot. For each expression below it appears in the MaTeX (gold) column. The ImportString column is Wolfram's stock
ImportString[…,"LaTeX"]
importer - what you get without this paclet - shown in the front end's own default math font, exactly as it comes (we deliberately do not restyle it to Computer Modern, so its typeface is part of the contrast too). The LaTeXMathParse column is the front end's own live typesetting of this paclet's boxes, restyled into the same Computer-Modern face as gold, so it differs from gold only in layout, never in typeface. Read each row left to right: LaTeX, then gold, then stock Wolfram, then ours.
The corpus is graded - atoms, operators, sub/superscripts, fractions and radicals, large operators, delimiters, functions, accents, environments, full real-world formulas, double-struck blackboard, and quantum / bra-ket notation - so you can see where the parser tracks LaTeX exactly and where the front end's math engine spaces or sizes things a little differently. Every entry both parses to a non-
ParseError
box tree and renders in real LaTeX, so each row is an honest apples-to-apples read.
MaTeX needs a working LaTeX toolchain (
latex
+
dvisvgm
, or
pdflatex
+ Ghostscript). When it isn't available the gold column shows a placeholder and the
LaTeXMathParse
column still renders, so this note always builds. A companion headless harness,
dev/MaTeXCompare.wls
, runs the same comparison and additionally prints quantitative width-ratio / image-distance metrics for regression tracking.

Gold vs. parser, by tier

Out[1]=

Reading the comparison

◼
  • Structure is the parser's job. Whether a fraction stacks, a subscript binds to the right atom, a matrix lays out as a grid, an integral carries its limits - that is what
    LaTeXMathParse
    builds, and it should match the gold column row for row.
  • ◼
  • Display style is forced on both sides. MaTeX typesets display math, so the parser column is rendered at
    ScriptLevel->0
    to match:
    \sum
    /
    \prod
    /
    \bigcup
    /
    \lim
    carry their limits stacked above and below (the parser emits
    UnderoverscriptBox
    /
    UnderscriptBox
    ; the front end only stacks them in display style, putting them to the side inline),
    \int
    keeps its side limits, and fractions render full size. The same boxes in an inline
    $…$
    context would correctly show side-set limits and smaller fractions.
  • ◼
  • Typeface is matched in shape. Italic letters use Latin Modern Math - the OpenType math font whose italics are the very
    cmmi
    letterforms MaTeX renders, reached by remapping each
    "TI"
    letter to its math-alphanumeric codepoint (so variable shapes match, not just the upright glyphs). Double-struck
    \mathbb
    uses
    MSBM10
    - the AMS
    msbm
    font (what MaTeX's
    \mathbb
    is) converted to OpenType and remapped to the Unicode double-struck codepoints - so the blackboard letters match gold's exactly rather than the FE's own design.
  • ◼
  • Stroke weight is the one thing that can't match, and it's the render engine, not the font. Measured at identical size and resolution, the front-end column carries ~1.5× (italics) to ~1.8× (dense upright caps) the ink of the LaTeX column - and that ratio is identical whether the FE font is Latin Modern Math or the FE default, so no font choice changes it. MaTeX is a resolution-independent LaTeX vector; the parser column is front-end-rasterized text, which is simply heavier. Equalizing it would mean rendering both columns through the same engine - which would make them identical and defeat the comparison. It reads closest in light appearance.
  • ◼
  • The ImportString column is the stock Wolfram importer, shown for contrast - it is what
    ImportString[…,"LaTeX"]
    gives without this paclet (math-wrapped in
    $…$
    , since bare snippets return
    $Failed
    ), drawn in the front end's own default math font rather than restyled to Computer Modern, so you see it exactly as it comes - typeface included. It handles the easy structural cases - superscripts, fractions, radicals, sums - but watch where it diverges from both gold and ours:
    \mathbb{R}
    comes back a plain
    R
    with no blackboard,
    \begin{cases}
    loses its enclosing brace,
    \overrightarrow{AB}
    misfires into a stray ring, and Greek letters are left upright rather than math-italic. That gap is the reason
    LaTeXMathParse
    exists.
  • ◼
  • The fifth column is the raw box tree
    LaTeXMathParse
    produced (InputForm), so you can read the structure that drives the rendering -
    FractionBox
    ,
    UnderoverscriptBox
    , the bracketing-bar characters, the
    "TI"
    italic tags, and so on.
  • ◼
  • Where the two diverge is the front end's automatic math-spacing engine versus TeX's: the gaps around binary operators and relations, and how aggressively a delimiter grows around tall content. Those are rendering-side, not parse-side - the box tree is faithful; the FE just spaces it by its own rules. See
    WolframBoxTypesetting
    for the levers that tighten this.
  • The code cell that builds this table is collapsed by default (
    #| collapse: true
    ) so only the comparison shows; click the closed group's bracket to reveal the code. The MaTeX column is recolored with
    LightDarkSwitched[Black, White]
    so it stays legible in both light and dark front-end appearances.

    See also

    ◼
  • LaTeXMathParserImplementation
    - design and implementation notes, and the KaTeX-corpus coverage benchmark
  • ◼
  • WolframBoxTypesetting
    - how the front end renders boxes, and how to control its math spacing/fonts
  • ◼
  • LaTeXMathParse
    - the symbol reference page
  • ◼
  • MaTeX
    - the gold-standard LaTeX-to-graphics package used here
  • RelatedGuides
    ▪
    Parsing in the Wolfram Language
    RelatedTechNotes
    ▪
    LaTeXMathParserImplementation
    ""

    © 2026 Wolfram. All rights reserved.

    • Legal & Privacy Policy
    • Contact Us
    • WolframAlpha.com
    • WolframCloud.com