.Net LaTeX projects

[charlesroddie]

Over the last year we seem to have a resurrection of https://github.com/ForNeVeR/wpf-math , which is based on JMathTex , and now CSharpMath , which is based on https://github.com/kostub/iosMath .

This is very promising. I am very interested in what the project maintainers think about this, how different these two projects are, and how they might develop.

I started looking at wpf-math and have just begun a port to F#, the main interest being to simplify the code structure to the point where I can add features: LaTeX editing, SkiaSharp, and rendering text + formulas. But this is a very big task, and would end up creating yet another .Net LaTeX project!

I would be keen to talk with anyone interested in .Net LaTeX here or on Skype (my user id is my public email here).

@ForNeVeR @Happypig375

[Happypig375]

One good thing, one bad thing.

Bad thing first:

One concern that I have about using F# is that it is not supported under UWP (.NET Native).

I have tried using this F# library on UWP half a year ago with no success. I tried everything from using the FSharp.Core Nuget package directly to decompiling the binary to C# and referencing it from the project. Either it fails to compile or throws System.TypeInitializationException at runtime.

I ended up calling a JavaScript library in a WebView.
So, sorry to say this, but I cannot use your new library if it is written in F#.

Now on to the good thing.

These two libraries can potentially be merged together.

Both internally use a DrawingContext.
The one in CSharpMath is not cross-platformy enough, with CoreText-like APIs which I could not map to Android/UWP. I don't know about WpfMath though, although it looks promising, and those XAML could be modified a bit to be XAML Standard compliant.

We could have WPF and Xamarin.iOS supported together! Yay! 🎉

By the way, I am also tagging @verybadcat who you missed.

[ForNeVeR]

@Happypig375 re XAML: it isn't actually a big deal for WPF-Math. Our users may create their own XAML controls and use the rendering logic from the library. It's actually the renderer that matters, not XAML.

We're currently developing abstractions to decouple our library from WPF, but there's still more work to do for that.

From my brief look at CSharpMath, it seems that it is highly-configurable, and if you provide all the interface implementations for TypesettingContext, it should work on any .NET Standard-compatible platform; that's brilliant.

Regarding the ways to combine WPF-Math and CSharpMath: at the moment I'm not sure. I can definitely see the CSharpMath potential (e.g. it seem to have implemented the features WPF-Math currently lacks, e.g. matrices) and I'll take a closer look at the implementation when I'll start working on similar features of WPF-Math. Although we'll need to think more about how to integrate our libraries into something bigger and better (if we eventually want to do it).

I'm open for discussion.

[charlesroddie]

@Happypig375 One concern that I have about using F# is that it is not supported under UWP (.NET Native).

Yes unfortunately UWP support for F# is a problem and while it is hopefully temporary, Microsoft does seem to have brushed it under the carpet for now @cartermp. Now that @dsyme is going to work with Xamarin things could change as the problem makes F# somewhat toxic for writing libraries intended for use with Xamarin.Forms. The remaining work on support seems much smaller than it was a couple of years ago, only that there is no-one doing this work.

The main advantage for using F# would be expressing recursive tree structures and parsing LaTeX into these structures can make things much easier than in non-functional languages. However if there is going to be a single C# project that is very well structured I will be happy to avoid multiplication of libraries and will try to contribute to that, albeit more slowly in C# than F#.

The iosMath project that CSharpMath is based on has support for an editor https://github.com/kostub/MathEditor and a port of that could be feasible.

[verybadcat]

I am glad to see this issue.

I had never noticed WPFMath until this issue came along. About different front ends, yes, my intention is that it should be possible to plug them in without altering the base project. The big things you need are a font and a MathTable. The former is what you are going to draw; the latter tells you how much space you need to allow around your glyphs. Presumably WPFMath contains the same information in some form or another.

[verybadcat]

Also, I don't think different languages in the core and front end projects should be a problem.

[Happypig375]

@charlesroddie

only that there is no-one doing this work.

And there is a decent chance that it will never be done.

The main advantage for using F# would be expressing recursive tree structures and parsing LaTeX into these structures can make things much easier than in non-functional languages

I have heard that record types are to be added in C# 8. This should hopefully solve this problem.

However if there is going to be a single C# project that is very well structured I will be happy to avoid multiplication of libraries and will try to contribute to that, albeit more slowly in C# than F#.

Yup, record types should make it easier to structure a library well.

@verybadcat

It does sound like that CSharpMath and WPFMath can be merged together as the information needed
and the methods to draw are very similar.

Also, I don't think different languages in the core and front end projects should be a problem.

Yup. C# projects, F# projects, VB.NET projects etc. can all reference each other. But to distribute an entire library FSharp.Core is still needed to be referenced, which does not work on UWP, due to tail-calling MSIL etc.

[FoggyFinder]

So, as a conclusion after a week of silence. Do we going to see new F# library?

[Happypig375]

No definitive answer as of yet; @charlesroddie supports this idea and I am against it.

Btw, thank you for re-igniting this discussion.

[charlesroddie]

@FoggyFinder There are two C# projects which derive from two OO projects in other languages. So there is a lot of existing OO work. In this context it doesn't make sense to port to F# now, even if it is more inherently suitable. I did start to port wpf-math because I thought I would have to work on the internals in order to eventually implement a LaTeX editor. But CSharpMath has the possibility to port over MathEditor. So my currently strategy is to wait for these things to happen and help where I can. If over the next few months there are roadblocks or I if I have to understand the workings of the libraries to implement a feature, then an F# port will emerge.

[Happypig375]

I will try not to make that port happen ;)

[Happypig375]

Just found this today: https://assetstore.unity.com/packages/tools/gui/texdraw-51426

Someone is charging money for that.

[Happypig375]

One immediate downside of it is the sheer number of non-standard commands it uses.
@ForNeVeR Kinda reminds me of that person who still commit to the master branch of his fork...

[ForNeVeR]

I'm still not sure about what to consider a "LaTeX standard". It's hard to distinct between standard and non-standard stuff in today's TeX installations.

Regarding "that person": I believe that's a good man and we'll improve our project (and, well, the whole ecosystem of LaTeX-related projects) with help of people like that. Even if I have some difficulties communicating my requirements to people not familiar with git, that's my problem, and I will work harder to solve that.

[Happypig375]

By "LaTeX standard", I mean the documentation of it has to be at least searchable on the web.
For instance,

\frac{fraction}{with line}
\nfrac{fraction}{without line}
\lfrac{left}{fraction}
\rfrac{right}{fraction}

No related information can be found about the last three aside from the reference for the asset.

[charlesroddie]

I think it should be a long-term goal to combine wpf-math and CSharpMath.

The place to start is probably the Atom type (called Atom in wpf-math and MathAtom in CSharpMath I believe). I think we should be able to use the same code for this. (Allowing for Atoms that cannot be rendered if one project doesn't support them yet.) Then we can share the LaTeX parser and lexer.

[verybadcat]

Just thinking about libraries I use in my own work, they tend to be descriptively named. So I vote B.

[Happypig375]

A: 2
B: 4

I guess descriptive naming wins.

"MathDisplay.Net" seems to be the name that is the current consensus. Should we format the name as "MathDisplay.Net" or "MathDisplay.NET"? I prefer the latter as it aligns with "Math.NET" and ".NET" in general.

[alexreg]

These days, I tend to use "creative" names for end-user projects (i.e. executables), but "technical" names for library projects, so they would be easier to distinguish for the programmers involved in end-user projects.

I follow this pattern too. It seems most appropriate given whom libraries and programs are targeted at respectively.

[Happypig375]

"MathDisplay.NET" it is then.

[mauler2025]

Just found this today: https://assetstore.unity.com/packages/tools/gui/texdraw-51426

Someone is charging money for that.

@Happypig375 : Did the guy behind TeXDraw use some of CSharpMath libraries (parser, etc)?

[charlesroddie]

I don't believe @willnode is using CSharpMath or WpfMath in any way in his Unity package but he is welcome do to so and keep charging money as the licenses for both projects are MIT.

[mauler2025]

The source code of CSharpMath is not well documented compared to Wpf-Math. It is hard to digest what is going on behind the scene. No vertical spacing also makes it unnecessarily harder. :-)

[Happypig375]

@pstricks-fans What do you suggest to improve documentation? What do mean by vertical spacing?

[mauler2025]

@pstricks-fans What do you suggest to improve documentation? What do mean by vertical spacing?

No empty lines between methods, no enough comments describing the used algorithm, etc.

Suggestion: Provide at least a diagram describing how the execution flows from TeX input to rendered output.

[Happypig375]

No empty lines between methods

With CodeLens turned on, there are effectively empty lines between methods.

When empty lines are further added, there are effectively 2 lines between methods.

That's why empty lines tend not to be added between methods.

no enough comments describing the used algorithm, etc.

Suggestion: Provide at least a diagram describing how the execution flows from TeX input to rendered output.

Will add, thanks

[mauler2025]

It will be nice if you provide us with a description on the main page about how the underlying mechanism used to process the TeX input to render the corresponding output. Which classes can be categorized into the common code base so they can be reused for various targets (Xamarin.Forms, Unity, Blazor web-assembly, and much more). Thank you!

[Happypig375]

@pstricks-fans Added https://github.com/verybadcat/CSharpMath/blob/master/ReadMe.md#major-processes-of-drawing-latex

[mauler2025]

Thank you very much @Happypig375.

[yoshiask]

Is there any update on getting this project ready for Math.NET?

[Happypig375]

@yoshiask At this moment it is just an idea, no concrete plans yet. You can suggest a concrete plan though!