-
Notifications
You must be signed in to change notification settings - Fork 106
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
Extract WPF-dependent code into a separate project #63
Comments
Yep. An abstract rendering API might take a bit more thought than simply refactoring, but I am all for this! |
I thought we could use visitor pattern to abstract this. We already have very similar code in The parser still use some WPF features (I think fonts), so we should abstract those, also. |
OK, this is next huge step after #93 got merged. |
We'll definitely need to discuss that. Now I have a bit of insight on how our code works, so I could probably provide a useful advice. |
@ForNeVeR, hello! Do you update the 17-avalonia branch yourself? Or can I make edits to this thread without updates? P.S. I have no goals yet. I'm just eyeing :) |
I would accept a pull request to that branch. |
Can we replace bg / fg |
Yeah, this seems like a right course of action. We'll lose some flexibility though (e.g. it won't be possible to create a texture background and such). Could you think of a better solution, which will preserve ability to pass arbitrary |
It seems that we only need to know the color information: |
Yes, I'm not talking about defining texture backgrounds from LaTeX code. I'm talking about providing an externally-defined |
There weren't any colors in the predefined formula arguments anyway.
Custom IElementRenderers may use it.
Custom IElementRenderers may use it.
As part of #18 and #17.
The text was updated successfully, but these errors were encountered: