-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API Redesign #58
Comments
Please can you keep the "Core" of the CSharpMath, out of the need for "Rendering and editor" as this allows it to be used for other frameworks, i.e. Services only. |
What are these services and how would CSharpMath be used without rendering? |
|
Editing capabilities will be baked into MathAtoms. |
Very good but not sure about the example. I don't think that we should add extension methods to
Sounds good.
Great.
That's not a significant problem for users. If the projects have a natural structure where later projects naturally depend on earlier ones, then having things in separate projects enforces that ordering, unlike C# code in the same project. I don't know if this is the case with the current CSharpMath projects though. |
An update since the original post:
New items: An open question is whether to support (MathList->Text LaTeX) on top of (MathList->Math LaTeX). Math LaTeX seems enough for everyday use. The remaining items will be done as "Parser refactor (part 2)", blocked on #143. |
Note for implementing display math inside text: as seen in http://www.dfcd.net/articles/latex/latex.html, we can add a |
Is your feature request related to a problem? Please describe.
Currently, the APIs for CSharpMath are not intuitive at all.
For example, to convert MathList->TeX, one has to call
MathListBuilder.MathListToString
which is a static method (not easy to discover), and its name doesn't imply anything about the result being a TeX string at all.Describe the solution you'd like
Replace mutable global variables with settings objects.
e.g.
CSharpMath.Atoms.MathAtoms
contain multiple dictionaries that act as hidden dependencies. They should be made obvious.Reduce legacy boilerplate code from iosMath.
e.g. Why do some math atoms have their respective interfaces? It's not like MathAtoms will have alternate implementations, they are just data containers. If they are to be extended, they can be inherited.
e.g. Reduce boilerplate folders. They scare new contributors. Most folders in
CSharpMath/
contain few files anyway.e.g. Remove CSharpMath.Enumerations.MathAtomType. Use pattern matching on types instead.
Simplify the NuGet chain. It's not obvious what
CSharpMath.Rendering
does based on its name.CSharpMath
,CSharpMath.Editor
andCSharpMath.Rendering
should be merged into one. Typography should be integrated directly into CSharpMath becauseSource: https://github.com/Jolg42/awesome-typography#c-2
It's not like there is or will be any other implementations for font reading of math fonts.
Describe alternatives you've considered
Continuing the current API and result in a degraded user experience.
Difficulty: How difficult would it be? (Trivial, Very Easy, Easy, Moderate, Hard, Very Hard, Tedious, Backbreaking)
Very hard. A lot of time will be needed to achieve this.
Additional context
#57
The text was updated successfully, but these errors were encountered: