.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.

[Happypig375]

What name should the combined project be?

[charlesroddie]

I don't think that needs a decision now. A shared Atom project would have independent value even if the projects don't fully merge. Combining effort and ideas, simplifying the structure of the projects and reducing maintenance. @ForNeVeR @verybadcat @gsomix @alexreg does this make sense to you?

[alexreg]

@charlesroddie Agreed on the shared Atom structure, yes.

[ForNeVeR]

In principle, I approve the idea. But to give a meaningful answer, I'll need to invest some time into reading CSharpMath sources and researching of its' own Atom (or Atom-like) structures/types.

[Happypig375]

@ForNeVeR I will do the work. After all, CSharpMath's project structure is much bigger than wpf-math's. Please wait for my initial plan. (Will post here.)

[Happypig375]

CSharpMath: road towards 0.1.0

• Subpixel rendering will be re-targeted to after the merger of CSharpMath and wpf-math. (Details below.)
• After fixing the bug that @FoggyFinder raised, 0.1.0 final will be released. (I can't do it right now as I am on a school trip to Taiwan.)

The name of the new project

Why?

I don't think that needs a decision now.

I think it needs a decision these few days if not now.

1. The name is going to be immutable as it directly correlates to the project structure, and changing both will be a breaking change. An initial bad name will stick to the project. An example of a project not following this is Typography.GlyphLayout. The project name is Typography.GlyphLayout but its namespace is Typography.TextLayout. It is hard to figure out where the classes are located without looking at the source.
2. A good name makes a good first impression and is easier to memorize. By enabling developers to memorize the name more easily, they will more likely to come back to the project after first sight. The more recurring developers, the more potential contributors. In the end, the project will be more active.
3. A good name will prevent static mindsets. Current names limit the scope of the projects. "CSharpMath" implies the project is only written in C# (discourages e.g. F# unit tests), and "wpf-math" implies the project is only in WPF (discourages porting to e.g. Avalonia). In the same way, WinForms, WPF and UWP are confined to Windows as implied in their names. By not including specific technologies in the name, the project will not be discouraged to include more technologies.

What

I have brainstormed a few names. Here are my top picks, starting from my favorite:

MixiMath

1. "Mix" of CSharp"Math" and wpf-"math" (With correct ordering - "math" is at the end)
2. Name is short and concise
3. Searchable - Google only shows 8 results - all are irrelevant
4. Memorizable - It contains an alliteration!
5. Pronunciation unlikely to be incorrect as it is easy to pronounce.

FuseMath

1,2,5 still applicable
3,4 is not as great as MixiMath
Con: Brief stop in pronunciation between "Fuse" and "Math"

AtoMath

1: The "atoms" of CSharp"Math" and wpf-"math"
2,5 still applicable
3 is not as great as MixiMath
4: Memorizable - "Atom" is coined with "math"!
Con: "AtoMath" is already taken in GitHub. That means we won't be able to create an organization with such a name. We will have to use the not-so-fair collaborator system or use e.g. GitLab.

MathCore

1: Just like .NET "Core" is the new .NET platform, it is the new CSharp"Math" and wpf-"math".
2,5 still applicable
3 is just not applicable. "MathCore" is already used by other repositories.
4 is not present as well. "MathCore" seems like a conventional and uninnovative name.

How

I am going to create an organization with the final name (MixiMath for example). There will be three repositories initially.
The main repository will be named MixiMath/MixiMath. It will contain the main library.
The second repository will be named MixiMath/Meta. It will contain design notes and moderation information (e.g. rules, contributing guide, warning/ban logs). It will be used for meta-discussion and discussion that do not correspond to other repositories.
Last but not least, the third repository will be named MixiMath/MixiMath.github.io. It will contain documentation and a github website through GitHub Pages.

The people invited will include (rough plan):

Team	People	Subteams
Core	@ForNeVeR, @Happypig375	(none)
Advisors	@charlesroddie, @FoggyFinder, @alexreg, @gsomix, @verybadcat	Core
Collaborators	@B3zaleel	Advisors

Please do comment for improvements.

[charlesroddie]

There is so far no agreement on a merger of wpf-math and csharpmath but there is some agreement in principle about sharing code, specifically Atom/MathAtom, subject to investigating its feasibility.

We can start a new repo to put relevant code/issues/documentation/metaissues in but I would not start three. If we do this now I would suggest for a name AtomicMath if you want something that sounds good, but the namespace should be MathAtom or Atom.

This repo will be for creating a shared MathAtom type and possibly a parser that converts LaTeX math into a MathAtom. This project will be successful if it produces a good MathAtom type that the maintainers of wpf-math and csharpmath want to use. After that, who knows.

The thing I am most interested is a github issue that we can start discussing the Atom type in. Given @Happypig375 's post I'll wait for a new repo to do that in.

[B3zaleel]

What about "Mathigrafia"? (from Greek Mathimatikí typografía aka mathematical typography).

[Happypig375]

@charlesroddie I'll wait for @ForNeVeR's response to feed my thought.
@B3zaleel Isn't that name a bit hard to remember?

[B3zaleel]

Not really

[alexreg]

It's a bit of a mouthful though, I reckon. I would suggest something like MathType or MathScript, but I think they're already taken by reasonably well-known software.

[ForNeVeR]

@alexreg well, I didn't mean that our hypothetical LaTeX-focused project should be a part of Math.NET, but...

Now, when you say that, that actually seems like a decent idea. Although I think that we'll need more certainty on our side before offering to join Math.NET. Let's keep this in mind but don't do any additional steps before we ship something usable.

[Happypig375]

Well, I'll tag @cdrnet for potential thoguhts on this.

[alexreg]

@ForNeVeR Fair enough.

[Happypig375]

@mathnet Would you consider us merging with you?

[cdrnet]

This projects sounds very interesting! I'd be happy to work together with you on this, but we'd need to make sure that I cannot block you, i.e. no task like creating a new release should depend on me (as there may be phases of time where I cannot respond quickly).

(btw: Math.NET Symbolics can also format its expressions in LaTeX)

[Happypig375]

So, let's vote.
A. Creative naming (MixiMath, FuseMath, etc.)
B. Descriptive naming (MathRender, MathDisplay, etc.)

I vote A.

[alexreg]

B for me.

[FoggyFinder]

Hard choice, but my vote for A too.

[charlesroddie]

B with a preference for MathDisplay.Net which could become Math.Net Display in future.

[ForNeVeR]

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.

Consider yourself changing your work and entering a development of a math-based end-user solution. So, your first day at work, and you skim over the package lists to get a first look at what each of projects in your solution do. Probably it would be better for you to see

- MathDisplay.Net
- Json.Net
- Amazon.WpfIntegration

than

- GloryOfSauron
- Mighty.Rhinoceros
- =++Octarine++=

So, for a library project my vote goes for B.

[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.

[pstricks-fans]

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.

[pstricks-fans]

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?

[pstricks-fans]

@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

[pstricks-fans]

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

[pstricks-fans]

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!