Tracking issue for WpfMath parity

[Happypig375]

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-\text gap 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 (\hline and \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 \not after 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.

[charlesroddie]

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]

Updated section headers to clarify

[Happypig375]

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.