.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

[charlesroddie]

MathPrinter or MathRender ?

[Happypig375]

Note: Searching "MathPainter" yields the CSharpMath.Rendering.MathPainter class on GitHub. LOL!

[alexreg]

MathScript? MathScript-net/MathScript.NET? So many good names are already taken, I'm often in favour of appending "-net" or ".NET".

[charlesroddie]

I like MathScript.NET.

[Happypig375]

The website "mathscript.net" is already taken, but I think the name itself is good enough to be behind MixiMath and FuseMath in my favorites list.

"MathDraw.NET", "MathPrint.NET" and "MathRender.NET" are available though.

New nomination: "MathDisplay" (does not collide with other projects even without ".NET"!)

MixiMath and FuseMath are still on my favorites because they look specially enough to be memorable. See Point 2 of the Why section of my comment.

[charlesroddie]

I like MathDisplay.

[alexreg]

I prefer MathScript.NET (we don't necessarily need the domain name). MathDraw and MathDisplay are also decent though. :-)

[Happypig375]

Name comparison table

Name	No. of characters	No. of syllables	No. of Google results	No. of Google results with quotes	No GitHub name collision?	No GMail name collision?
MixiMath	8	3	8	8	✔️	✔️
FuseMath	8	2	33	37	✔️	✔️
AtoMath	7	3	2 630	2 940	❌	❌
MathCore	8	2	592 000	530 000	❌	❌
AtomicMath	10	4	1 760	1 640	✔️	❌
Mathigrafia	11	5	0	0	✔️	✔️
MathType	8	2	1 290 000	1 130 000	❌	❌
MathScript	10	2	59 500	52 500	✔️	❌
TexNet	6	2	369 000	311 000	✔️	❌
MathDraw	8	2	13 700	12 800	✔️	❌
MathPrinter	11	3	114	112	✔️	❌
MathRender	10	3	379	415	✔️	✔️
MathPainter	11	3	500	507	✔️	❌
MathDraw.NET	12	4	14 500	1	⍻	✔️
MathPrint.NET	13	4	37 200	3	⍻	✔️
MathRender.NET	14	5	417	0	⍻	✔️
MathDisplay	11	3	48 900	8 370	✔️	✔️

⍻ in "No GitHub collision?" means that hyphens will have to be used. Not beautiful. Memorizability is not included as it is subjective.

Welp, the rightmost column really takes a lot of names out of consideration.

My current top picks (considering the above table)

1. MixiMath
2. FuseMath
3. MathRender
4. MathDisplay
5. Mathigrafia
6. MathDraw.NET, MathPrint.NET, MathRender.NET

[Happypig375]

By the way, MathRender/MathDisplay -> "It renders/displays math!" MixiMath/FuseMath -> "I don't know what it does. I'll check it out!"

If we constrain the name to "It renders/displays math!" only, users might exclude the possibility of the library being capable of other math-related features, e.g. math evaluation. (Yes, this is planned)

[B3zaleel]

Rendering and evaluation should be kept separate else the repo can become harder to maintain.

[charlesroddie]

"I don't know what it does. I'll check it out!"

That's not how people behave. We should have a descriptive name.

the library being capable of other math-related features, e.g. math evaluation

The current library is to do with layout and the atom is based on the laid out structure. Conversion to e.g. a Math.Net Symbolics expression to evaluate would still be to do with layout, since it is understanding a laid out expression. So most of the descriptive names would still work.

We could think about joining Math.Net. Math.Net Display/Type/... .

[alexreg]

That's not how people behave. We should have a descriptive name.

Agreed.

I'm with Charles on the second point too.

[Happypig375]

@B3zaleel Yea, keeping them separate is easier to maintain, to the point where the popular one gets all of the development attention, and the others bite the dust. See: Math.NET Numerics vs other Math.NET projects.

@charlesroddie, @alexreg https://novanym.com/blogs/blog/16463485-business-naming-six-reasons-why-you-shouldn-t-be-descriptive

TL;DR Stand out from the crowd.

About merging with Math.NET, I'm not sure about that. As mentioned above, Math.NET is kinda numerics-first, symbolics-second. I want to let the new project to be symbolics-first.

[alexreg]

@Happypig375 Fair point about Math.NET. About "standing out from the crowd"... not sure this is standing out for a good reason!

[Happypig375]

Why not?

[alexreg]

Well, obscurity...

[Happypig375]

As mentioned by the blog I linked, people aren't going to be able to search the new project by typing MathDraw/MathPrint/etc., since there would be so much results. Referencing the Name Comparison Table I posted, there are really lots of search results for the descriptive names. In contrast, MixiMath only has 8, FuseMath only has 33.

[ForNeVeR]

@Happypig375 I'm all for merging symbolic evaluation contributions, if any, with Math.NET's symbolics project. It's already somewhat widespread and well-known, and we don't have too much .NET math-based projects around to split our efforts, so I think we should better interoperate with other people.

As a side point, Math.NET maintainers don't mind F# (I've discussed it with them in scope of another project). They are very nice people, so probably you could discuss your plans with them (visit their Gitter chat if you like) and you'll come out with benefits for both your project and for Math.NET.

[Happypig375]

There's also Symbolism but it seems to be dead at the moment.

[alexreg]

Good to hear, @ForNeVeR! I am now leaning towards that. Math.NET Display/Graphics/Draw seems like a good name.

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