Resource packages for the formula parser

[B3zaleel]

If an end-user wants to use the formula parser with a different default settings like predefined color values and/or formulas, formula settings, allowed symbols, font files and their metrics. Having a package that suits his/her needs would be very convenient.

[Happypig375]

If each package can define default settings, does this mean only one package can be active at a time? If not, how will conflicts be handled?

[B3zaleel]

Yes, only one can be used. The extraction directory would be emptied before the package is extracted. Just like installing another version of the same program in Windows.

[Happypig375]

Then that would definitely limit its usefulness. We cannot create all possible packages for users to choose from. The user will have to resort to using custom code to customize the settings and fonts.

[ForNeVeR]

Well, that's a route I'd like to go eventually.

People are constantly arguing about what LaTeX feature / formula definition / command should go into WPF-Math and what shouldn't. Before now, we were solving these quesions manually, by either including or not including some stuff such as colorbox.

And now, imagine TeX, LaTeX, XeTeX and everything-else-tex users could create their own packages for WPF-Math that will add their own syntax to the library without any troubles. That's great!

By adding optional "packages" we could solve that. And if we allow our users to add their own definitions on top of the defaults, the users will be happy. Somebody could add their own syntax for standard commands etc.

As a first step, I'd allow to add new XML and font definitions on top of the defaults. User would instantiate some WpfMathEnvironment that contains XML and font definitions (we should migrate our static stuff there), and then execute all the operations in scope of that environment.

When multiple packages define the same entity (command, character, formula etc.), we could either allow the last added package to replace it or generate a conflict. I believe that we should be robust enough to let our users to decide what to do in that case. Probably we could wire some IConflictResolutionStrategy as part of our Environment?

Each package should not (re-)define the default settings, although they could do that. I think that we will provide default package and (maybe) some additional ones, and the user will decide what to enable at runtime.

And now for the distribution part: I believe that we should provide an interface to maybe load the package contents from some generic Streams and cover that with interfaces. E.g. IFont { string Name; Stream Content; }. That will allow our users to load the contents from ZIP archives, from resources, network streams and generally any source they want.

[Happypig375]

I am really confused by this comment.

1. Will a custom format like this gain any traction? Will standard NuGet packages building on wpf-math not suffice?
2. If the TeX/LaTeX/XeTeX users want to add functionality without any trouble, then wpf-math will need to support the full TeX infrastructure to interop with existing CTAN packages. Are you going down that rabbit hole? If not, why would those users even want to create such a package just for wpf-math?
3. By only allowing XML files as font information sources, are you ruling out the use of Typography in wpf-math?
4. This whole system is a big learning curve for new users. Would you go through the hassle of thoroughly documenting the whole system? What would the benefit in learning this system?
5. Conflict resolution strategies? How are you going to help reduce subtle bugs that may be introduced by these?

[ForNeVeR]

That's actually okay. It is a big topic, and it's hard to describe it in one post. I'm glad you've formulated the questions and I will try to provide answers from my point of view. Remember that this is a discussion, and any decisions I state are not absolute; you may reassure me and I may change my opinion later. I may not have a complete view on every nuance, though currently I feel like I know enough to discuss the implementation details.

1. You'll be able to do it both ways. You can either pack your resources in form you want and inject them into WpfMathEnvironment, or you could download (NuGet?) packages prepared by other people and use them in the same way. I imagine it could be done with a builder methods (like in ASP.NET Core), something like that:

   var environment = WpfEnvironmentBuilder.Create()
       .Default() // and it'll be possible to use `Empty()` instead of `Default()`.
       .AddResourcesFromCurrentAssembly(formula: "MyAssembly.MyXmlFile.xml", font: "MyAssembly.MyFont.ttf")
       .AddIResourcePack(SomeNugetPackage.ResourcePack)
       .AddNuGetResourcePackAsExtensionMethod() // cool!
       .Build();
   var parser = environment.CreateParser();
   // where IResourcePack is like `interface IResourcePack { Font Font; Stream FormulaXml; }`

   We may choose to register the stuff globally if we want though. I heard (from Avalonia devs) that Service Locator "anti" pattern is actually not that bad when you create a GUI control library: in that case, possibility to create stuff using constructor and then inject everything from static locator may be important.

2. No. We aren't going to support any additional infrastructure, I'm not that crazy (well maybe a little bit crazy but not that much). I was talking about cases when e.g. XeTeX users have some command (e.g. \Alpha), and users of other packages don't use it. Or maybe we'd like to add some additional fonts for them. You know, different TeX distributions have different packages enabled by default, and we could try to create multiple command sets for these users. Although it was just an example. I'm not that aware of LaTeX to choose the commands we want to support and the commands we doesn't. I'm just brainstorming here.

3. No, I don't. I want to use Typography (or other font information generator) for the stuff we can generate. But we can't generate everything. There's TexPredefinedFormulas.xml, for example, and that file isn't based on the font information. It contains manually prepared formula instructions. And it's the kind of info we could put into a "package".

4. I don't think that it will create so many troubles. The defaults should "just work" for new people. And if people want to do "strange" things (such as adding their own commands and replacing the standard fonts) — we will allow them to. It is also important that we'll be able to move the default fonts out of main package: some people won't be using them and will be using their own instead, so they won't have even to download the unused resources.

5. What bugs are we talking about? I think about things such as:

   • we have a \bigsum operator defined in main package
   • user has provided a package with its' own \bigsum operator
   • what should we do? Ignore the default one? Ignore the user one? Throw an exception?

   The same goes about e.g. font resources: if two packages provide one font, someone of them should win. Who decide that? I call that entity a "conflict resolution strategy". We'll maybe provide a default simple one, and users will be able to redefine it. E.g. their own strategy could merge the fonts and operator defs and generally do crazy things users usually want to.

[Happypig375]

Thanks. This issue is really settings-per-parser instead of a "package" (as in a CTAN LaTeX package). I misunderstood the words.