Comments (12)
Currently, I see the future of WPF-Math as this (sorry for crappy graphics):
I.e. we may have various renderers, including MAUI.Graphics (but by no means limited to it), and various platform integrations, like with WPF, Avalonia, or some newer ones, like MAUI itself.
Not all renderers support all platforms (MAUI doesn't list Avalonia as supported, right? Only SkiaSharp, and then an integration of whatever SkiaSharp part MAUI supports with Avalonia would be required, even though Avalonia already uses SkiaSharp itself).
Also, note not all users require UI platform integration at all: some will be happy with just rendering the formulae to PNG or SVG images on the server-side, possibly in headless mode without UI libraries available.
Another important point is that MAUI.Graphics doesn't seem to support anything older than netstandard2.0, which would be too limiting WPF-Math applicability: we still have a lot of old school users (who've already been concerned about .NET 4 being dropped earlier), and, as of now, I plan to support .NET 4.5.2 for the known period of extended support (i.e. until 2023-10-10, oh my gosh, provided both myself, .NET, and our modern society as we know it will make it that far).
from xaml-math.
Once we have everything in place to do this, it would be nice to tackle alternative rendering engines like Skia as soon as possible. It would certainly allow me to contribute to the library a bit more, since I'm rarely on Windows these days. :)
from xaml-math.
I think that addition of the alternate render engines will be the next big thing that we'll implement in WPF-Math. So, yeah, we have such plans.
from xaml-math.
I need SkiaSharp for Xamarin. Look forward to using and contributing to wpf-math if/when this is done.
As far as the new proposed renderers go, SkiaSharp is somewhat universal in that if all you had were SkiaSharp you would still have WPF support, and will probably have Avalonia support too if/when that platform progresses to something releasable.
from xaml-math.
Okay, for now we have somewhat independent IElementRenderer
interface (except for usage of GlyphRun
type for text rendering; we'll need to abstract it). It should help in development of alternate renderers such as Skia and DirectX.
from xaml-math.
https://github.com/dotnet/Microsoft.Maui.Graphics could be better than Skia in that it doesn't have the 5MB deployment size.
Replacing the WPF-specific renderer with this would solve the following issues:
#17
#96
#112
#281
#293
from xaml-math.
I see this as another (very viable!) alternative to some of these tasks (e.g. Avalonia and UWP support). We'd still need support for alternate frameworks, though having the new renderer would already be good and useful.
from xaml-math.
You're saying
WPFMath
| - Graphics abstraction Layer (in WpfMath)
| - Graphics abstraction layer (Maui.Graphics)
| - Everything
| - WPF
| - Avalonia
| - UWP
Why not flatten this
WPFMath
| - Graphics abstraction layer (Maui.Graphics)
| - Everything
from xaml-math.
Because then we'll have to write an abstraction layer from MAUI to everything. And I bet somebody will blame MAUI font antialiasing and say that the "native" one for their platform works better.
from xaml-math.
Because then we'll have to write an abstraction layer from MAUI to everything.
I'm not sure if I understand this point, but note that Maui.Graphics doesn't have a dependency on Maui (PR to clarify this).
font antialiasing
Maui.Graphics lists among its WPF "supported abstractions": SharpDX, SkiaSharp, Xaml & GDI. So as long as at least one of these supports the right antialiasing then current WpfMath users should be happy.
CSharpMath is likely to replace its abstraction layer and platform-specific implementations with Maui.Graphics. (link)
from xaml-math.
Also, note not all users require UI platform integration at all: some will be happy with just rendering the formulae to PNG or SVG images on the server-side, possibly in headless mode without UI libraries available.
SVG is the most interesting thing here as that is a case that Maui.Graphics would probably not support. So maybe an intermediate format would be needed:
type DrawableElement =
| Text of text:string * Position * Font
| Line of ...
| Path of ... // hopefully not too many of these
type Drawable(canvasDimentions:..., elements: ImmutableArray<DrawableElement>) = ...
If there were such a thing it could be shared between CSharpMath and WpfMath, along with the Drawable -> Maui.Graphics function.
we still have a lot of old school users (who've already been concerned about .NET 4 being dropped earlier), and, as of now, I plan to support .NET 4.5.2
You guys have it hard in Russia! But unless they are paying you a lot for this support, I would suggest dropping it. The idea that devs want to use updated software but are unwilling to update their systems doesn't make much sense and dropping legacy support is better for everyone, including for complaining devs as it forces them to make better decisions.
from xaml-math.
SVG is the most interesting thing here as that is a case that Maui.Graphics would probably not support. So maybe an intermediate format would be needed:
type DrawableElement = | Text of text:string * Position * Font | Line of ... | Path of ... // hopefully not too many of these type Drawable(canvasDimentions:..., elements: ImmutableArray<DrawableElement>) = ...
We are already halfway there, using sort of intermediate IElementRenderer abstraction. It still relies on certain WPF primitives (GlyphRun
), but the plan is to eventually extract/generalize those.
If there were such a thing it could be shared between CSharpMath and WpfMath, along with the Drawable -> Maui.Graphics function.
I think we were looking into it, and found no common ground, for now at least.
we still have a lot of old school users (who've already been concerned about .NET 4 being dropped earlier), and, as of now, I plan to support .NET 4.5.2
You guys have it hard in Russia! But unless they are paying you a lot for this support, I would suggest dropping it. The idea that devs want to use updated software but are unwilling to update their systems doesn't make much sense and dropping legacy support is better for everyone, including for complaining devs as it forces them to make better decisions.
I disagree. I currently believe that we shouldn't drop support for a bit outdated technologies just because of minor problems with supporting them. If it starts to cause major problems, I'll consider switching it to a lower support level (such as keeping 4.5.2-related stuff in a separate project, a separate package or something), but in the current state of things, I don't think we should get rid of 4.5.2 (or a newer .NET Framework versions) completely right now.
Also, my previous statement was done before the latest announcement of 4.5.2 being obsoleted at 2022. So, we'll be able to switch to 4.6.2 in about a year. What a relief :)
And, no, nobody's paying me for WPF-Math support (or, for that matter, for any of my own open source work not related to my current employment) — which is fine, and I'm just trying to do my best to allow people to use the library for as broad a range of projects as rationally possible. You know there's a lot of GUI development done on outdated tech stacks.
As far as the platform vendor claims to support the technology, I'll try to not drop the support for it, too. This is not related to any new stuff I develop, but related to the libraries which already offer support for these platforms.
from xaml-math.
Related Issues (20)
- Selection highlighting is broken in WPF HOT 1
- The logic in HorizontalBox.Add is broken HOT 2
- Box and derived type should be immutable HOT 1
- How to use SetBackground HOT 3
- Equation with cases
- Changing font has no effect HOT 4
- Crash on typing `\left\{\matrix{}\right\}`
- Allow overriding font for letters in math mode
- Block height for `\text`
- The new update: unknown error HOT 6
- Padding and Background HOT 9
- Size for a matrix doesn't get properly determined on exporting to image HOT 1
- Vectorize the output image (feature request) HOT 2
- Support for WinUI? HOT 1
- Split Fraction HOT 1
- Commutator Diagrams HOT 1
- Align matrix equation HOT 2
- Support for lines between columns and rows in matrices
- Test failures on CI: The process cannot access the file `XamlMath.Shared.net462.tmp.cs` because it is being used by another process
- Matrix should align its items with the baseline, not the total box
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xaml-math.