-
Notifications
You must be signed in to change notification settings - Fork 9
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
UnTeX
Action
#187
Comments
see #188 for my feelings on this |
in particular i do not see any use case at all for this. notably, this is not a feature requested in anything because there is no use case and i will insist there is no use case |
I disagree; this feature is just reporting information that we already have.
I have wanted to edit formulas/text I've added to qboard many times. This let's us do precisely that. |
okay, sure, that's a use case. and yet, i don't think there's any good ui for this. nothing in qboard currently allows you to edit it once it's placed. change the color of something you drew? idk. maybe. but still |
Just an action is sufficient. The bulk of the work is then #193, which is already solved by #194.
This is precisely #28. If we want to add anything beyond an action (we might not, and I'm personally fine that way) then we'll just piggy-back on that idea, with #28 ideally but not necessarily resolved first. |
i think this is okay now, actually, but i think this is blocked by #28 first |
When an image that was inserted from qboard's tex system is selected, users should be able to run an action that recovers the original tex source. This should also be in the image's context menu (#203; see also #28). This should work even if the file is saved and reopened.
NOTE: while it's good to have it in the context menu, this issue only concerns the action behind it. See #203 for the "full" version of this issue, where we also add to the context menu. That issue is likely dependent on #28;
Solution:
fabric.Image
element. Figure out how to make sure it gets serialized and reinserted.TeXImage
or something so you don't have a bunch of floatingany
s and invalid lookups. The operation that checks whether the image came from tex should be a type guard for this type.Spec decision:
This is again not a security concern because we never render arbitrary tex (except obviously when the immediate user requests that we do so with the tex action).
However, we may want to be mindful that someone may make a fake JSON file where they set the tex data to a wrong value. I think this is fine; the user should always validate their own TeX before running it, but we might want to give a warning that the returned tex is not necessarily correct.
Keep in mind that if you actually do something about this, you also want to cleanse every other SVG added to the board. Also, it is not a valid solution to check the validity of the tex field by running it and comparing the outputs, because the whole security concern is that you don't want to run it (we don't trust mathjax enough to say that it doesn't have an XSS or blocking operation vulnerability). I don't think this is something to worry about, though (just like it's not Google Docs's job to ensure that what someone writes in a comment is truthful).
The text was updated successfully, but these errors were encountered: