Repository navigation
Tracking issue for WpfMath parity #145
Description
This is a meta-issue, not a general conversation: it tracks selected WpfMath/xaml-math functionality and accepted related proposals through concrete CSharpMath issues. Native sub-issues are the source of truth; the original manual checklist remains in edit history.
Active native work
- Unify text-mode and math-mode LaTeX parsing #58 — shared text/math parsing architecture. Its children include nested inline math, shared tokens/commands, migration, and the raw-underscore-in-
\textgap from upstream issue 141. - Implement the remaining LaTeX command backlog #81 — focused LaTeX command backlog. Its children cover arrows,
\not,\middle, font shapes,\udots,\longdiv,\lbrack/\rbrack,\mathrel/\joinrel, and relative size declarations. - Complete rule and spanning-cell support in math arrays #195 — explicit table rules and spanning cells (
\hlineand\multicolumn).
Related specialized work stays in its own tracker rather than duplicating checklists here, including multiline equation bounds in #239.
Verified or queued
Already on master:
- SVG export is demonstrated by the SkiaSharp and VectSharp examples.
- Escaped
\_is supported as a literal underscore.
On the current pull-request queue:
- Port iosMath 2026 commits to CSharpMath #264 adds extensible macros,
\idotsint, thin-space commands, amsmath modulo forms, package tags, arrows, table rules, and other iosMath parity work. - Support the \\not relation command #280 adds
\notafter the control-word boundary fix in Respect TeX control-sequence boundaries #276. - Document the GitHub-native contribution workflow #295 updates contributor/review guidance.
- Support the rising diagonal ellipsis command #308 adds
\udots.
Proposal boundary
Several entries in the old checklist are proposals that WpfMath itself has not shipped, rather than parity gaps: MathML input, a simple arithmetic input language, resource-package design, and a general atom-tree snapshot harness. They should begin in the Ideas Discussion category and become issues only after maintainers accept a concrete scope and compatibility contract.
Windows-only DirectX rendering remains out of scope for this cross-platform library. Replacing the editor's mutable MathList model or attaching LaTeX source ranges to rendered boxes also remains out of scope unless a separately approved design changes those constraints.
Completion criteria
- Every accepted parity gap is represented by an actionable native child (directly or under an existing child epic), with no duplicate manual status checkbox here.
- Close this tracker only when its native children are completed or explicitly closed as not planned.
- New WpfMath-inspired ideas go to Discussions first; reproducible defects and accepted implementation scopes go directly to focused issues.
Activity
charlesroddie commentedon Jul 17, 2020
I think the title of this should be "interesting WPF-Math proposals", as these are not implemented or even necessarily planned WPF-Math features. WpfMath parity would refer to implemented WpfMath features not supported by CSharpMath.
Happypig375 commentedon Jul 17, 2020
Updated section headers to clarify
Happypig375 commentedon Aug 30, 2026
Retained as a meta-issue rather than converting to a Discussion. Native sub-issues now connect the concrete CSharpMath parser and command work, so progress is visible without status labels.