.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! :tada:

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]

@Happypig375 alright, your plan makes sense for me.

I'd vote for FuseMath (it sounds cool IMHO), but other ideas such as MixiMath, AtoMath and Mathigrafia are good as well. As a main project author (at least for now), you decide.

About the organizational structure: I agree with @charlesroddie. For now, let's just start a one new repository and start experiments there. I tend to agree in a way with your ideas about future organizational structure, but now let's just start the programming already :)

(And please send us a repository link. I'll try to keep a close eye on your initial development, so I could explore the new Atom structure while you're still working on it.)

Later, when we'll be ready, I'm in principle okay to transfer WPF-Math repo to the new organization (as long as I keep full administrative control* over the said repo).

* Full administrative control is important to me not because I'm plotting something, but because I use it to set up CI and various automation stuff in my repositories; it's just required for my work as a maintainer. You know me, I'm a rational man and it shouldn't be a problem.

[alexreg]

Not a fan of FuseMath, to be honest.

[Happypig375]

@alexreg Is it too edgy?

[alexreg]

@Happypig375 Perhaps yes. I'm just not sure I like the phonetic quality or that it gives it a good indication of what it's about (the "fuse"). I'm being picky though...

[Happypig375]

@alexreg The phonetic quality is what was noted above. "FuseMath" is not about its use, but its history: It started as an atomic "fusion" between the CSharpMath atoms and wpf-math atoms.

[alexreg]

Yeah, but that is kind of obscure. Most users will scratch their heads at that.

[Happypig375]

What about "MixiMath"?

[alexreg]

Better... still not 100% sure though.

[Happypig375]

What could be improved?

[verybadcat]

About merging the projects -- what would CSharpMath gain from a merger?

[alexreg]

The initial idea is just shared object hierarchy for atoms; nothing more, I think.

[Happypig375]

@verybadcat With a limited number of contributors, we can either:

1. Work on two separate projects and duplicate the effort of maintaining the code and developing new features; or
2. Work on one combined project, maintain half of the code, and develop new features once only.

I'd pick 2.

[Happypig375]

Let's conclude...

Name	Voters	Total Votes
MixiMath	@ForNeVeR (0.5), @alexreg, @Happypig375	2.5
FuseMath	@ForNeVeR, @Happypig375 (0.5), @FoggyFinder	2.5
AtomicMath	@charlesroddie, @FoggyFinder	2
Mathigrafia	@B3zaleel	1

A tie between MixiMath and FuseMath.

[FoggyFinder]

I like FuseMath it sounds really cool, AtomicMath also good name

[Happypig375]

Erm... Late vote, but I'll also count.

[charlesroddie]

We can go with FuseMath as the name for the current cooperation project. If the project ends up creating a complete solution usable by end-users and not only by wpf-math and csharpmath, it will need a new name as the fuse term is only meaningful to insiders (same goes for mix). I just created a MathAtom repo but we can use FuseMath instead. Do you want to create the repo @Happypig375 or shall I rename MathAtom?

[Happypig375]

Note: The name itself does not really need to be very meaningful aside from representing the company/project. It just has to sound good, be one word, so it can be memorable. See: Google, Xamarin, Tencent...

[charlesroddie]

I created this yesterday: https://github.com/charlesroddie/MathAtom

Feel free to change the name.

Started to document the Atoms: https://github.com/charlesroddie/MathAtom/issues/2 . Need more info on the CSharpMath MathAtom as there are features that CSharpMath has that don't seem to be represented in https://github.com/verybadcat/CSharpMath/tree/master/CSharpMath/Atoms .

[verybadcat]

I agree that picking up contributors is a wonderful goal, and if someone wants to join the project, they should be encouraged and helped. But my feeling is, don't share code just to pick up contributors. That's just looking for trouble down the line, when a change to support one project screws up the other one. Good reasons to share code would be to include more platforms or to typeset things we otherwise couldn't typeset.

That said, the fact that I started this project should not make my opinion in any way dispositive.

[Happypig375]

That's why I would want to completely deprecate the old projects eventually. It's all or nothing.

By the way, please vote on a project name.

[ForNeVeR]

@verybadcat let's consider that a research project: it will help us to conclude if code sharing between .NET LaTeX projects is possible, and if it is, then at what degree. You aren't obliged to accept the "merge" or any "shared" code, but I think that's still an important research, even if it will eventually fail or be fruitless.

I think the strategic goals were already discussed in this thread: eventually we'd like to merge the best parts of CSharpMath and WPF-Math together, and that (theoretically, at least) should benefit all our users.

[verybadcat]

I'm all for research. And you don't have to persuade me. If you think I'm wrong, just do it. About the name, I don't think the fact of a merger is significant to the name. What about TexNet or MathDraw?

[Happypig375]

@verybadcat TexNet: See 3rd item of Why in this comment. A name like that would discourage supporting e.g. MathML, which I am planning for the future.

MathDraw: Google it and see the amount of name collisions.

[Happypig375]

The fact that the proposed names are inspired by the merge does not mean they are not good names. See the What section of my comment. They are short, concise, memorable, special enough, and does not seem to be reused much elsewhere. The fact that they are inspired by the merge is just icing on the cake.