Unify text-mode and math-mode LaTeX parsing

CSharpMath.Atom.LaTeXParser and CSharpMath.Rendering.Text.TextLaTeXParser currently maintain separate scanners, mode transitions, command handling, syntax trees, and serializers. That duplication makes mixed constructs such as math → \text{...} → inline/display math difficult to implement consistently.

This issue is the architecture epic for unifying those parsing layers incrementally. Concrete work is tracked as native sub-issues, beginning with #205 and the shared-token, command-definition, and migration stages below it.

Out of scope:

Merging the Core, editor, rendering, or frontend NuGet packages.
Adding string extension methods as the primary public API; painters remain the discoverable frontend API.
Reintroducing removed iosMath abstractions solely for structural parity.
Redesigning mutable global settings in the same change; that requires separate scope.

Completion criteria:

One documented parsing architecture supports math → text → inline/display math → text transitions.
Shared commands have one registration and serialization definition, while mode-specific behavior stays explicit.
The MathList/TextAtom interoperability boundary is documented and preserves text whitespace, line breaking, and display-math layout.
Existing Core, Rendering.Text, and rendering suites remain green, with mixed-mode round trips and exact errors for escaped dollars, malformed delimiters, nested braces, text styles, colors, and cases-style expressions.
Existing public parser and painter entry points, package boundaries, and independently consumable frontends remain compatible.

This is intentionally a parent issue rather than one backbreaking rewrite; mergeable acceptance criteria live on its sub-issues.

Please can you keep the "Core" of the CSharpMath, out of the need for "Rendering and editor" as this allows it to be used for other frameworks, i.e. Services only.

What are these services and how would CSharpMath be used without rendering?

@charlesroddie

@charlesroddie

.Net Core 2
Used for Verification of the Latex Format (Hence my questions/problems about round tripping)
Then transferred Via the MathList etc. - using internal methods - into different usage and logic trees, dependent on wrapped metadata and context.

Other frameworks can still be used.

Editing capabilities will be baked into MathAtoms.

Streamline the use of CSharpMath APIs.

Very good but not sure about the example. I don't think that we should add extension methods to string! If you are creating object B from A then B.FromA(a:A) is often better because usually A can be defined without reference to B but not vice versa.

Replace mutable global variables with settings objects.

Sounds good.

Reduce legacy boilerplate code from iosMath.

Great.

Simplify the NuGet chain. It's not obvious what CSharpMath.Rendering does based on its name. CSharpMath, CSharpMath.Editor and CSharpMath.Rendering should be merged into one. Typography should be integrated directly into CSharpMath because

That's not a significant problem for users. If the projects have a natural structure where later projects naturally depend on earlier ones, then having things in separate projects enforces that ordering, unlike C# code in the same project. I don't know if this is the case with the current CSharpMath projects though.

@charlesroddie

An update since the original post:

Streamline the use of CSharpMath APIs: Better solved by documentation as in https://github.com/verybadcat/CSharpMath#major-processes-of-drawing-latex. Extension methods would result in pollution as noted by @charlesroddie.
Replace mutable global variables with settings objects: To do. This is required to support \def, \DeclareMathOperator etc.
Reduce legacy boilerplate code from iosMath: Already done as part of the 0.4 update.
Simplify the NuGet chain: Not a good idea as noted by @charlesroddie.

New items:
5. Merge the entirety of CSharpMath.Rendering.Text into CSharpMath.Atom. In LaTeX, \text enables text-mode inside math-mode. With a separate implementation of CSharpMath.Rendering.Text, this is impossible. It is also undesirable to maintain two LaTeX parsers and two LaTeX trees at the same time. Moreover, this results in difference functionality between CSharpMath.Atom and CSharpMath.Rendering.Text, e.g. CSharpMath.Atom supports \colorbox while CSharpMath.Rendering.Text supports \fontsize, when such functionality should be present on both implementations. With #143, the same parser can be reused for both math-mode and text-mode with swappable command dictionaries.

An open question is whether to support (MathList->Text LaTeX) on top of (MathList->Math LaTeX). Math LaTeX seems enough for everyday use.

The remaining items will be done as "Parser refactor (part 2)", blocked on #143.

Note for implementing display math inside text: as seen in http://www.dfcd.net/articles/latex/latex.html, we can add a center environment that helps the implementation.

For frontend packages, the painter object can actually perform some of these conversions automatically. It may be "the" simple API that most end users are able to use. For configurable settings, CSharpMath.Settings is also very simple.

using CSharpMath.SkiaSharp;
var painter = new MathPainter { LaTeX = "1+1" };
var display = painter.Display;
painter.Draw(...);

var painter2 = new MathPainter { Content = painter.Content }; // MathList
var latex = painter2.LaTeX;

Navigation Menu

Repository navigation

Unify text-mode and math-mode LaTeX parsing #58

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Unify text-mode and math-mode LaTeX parsing #58

Description

Activity

Smurf-IV commented on Sep 14, 2019

charlesroddie commented on Sep 14, 2019

Smurf-IV commented on Sep 15, 2019

Happypig375 commented on Sep 15, 2019

Happypig375 commented on Sep 15, 2019

charlesroddie commented on Sep 15, 2019

Happypig375 commented on Jul 14, 2020

Happypig375 commented on Jul 16, 2020

Happypig375 commented on Feb 13, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions