-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
Refactor SVG path parser to accept scientific notation #873
Conversation
Thank you Junology for this pull request! Really cool to see such a quick fix! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great addition! One optional change, for future readability
* 3: on a digit or a sign in exponent in scientific notation, e.g. 3.14e-2) | ||
* 4: on a digit sequence in exponent | ||
*/ | ||
int lexState = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understandable, could it be with a enum instead of an integer? I'm afraid we might lose this documentation at some stage
Note: I updated the #816 placeholder to include @SaumyaKarnwal's Diff and full description |
Yes, but it shouldn't block this PR |
@all-contributors please add @Junology for code |
I've put up a pull request to add @Junology! 🎉 |
Thank you, @Junology , for this PR! A welcome enhancement to Processing's SVG support. |
Refactor
PShapeSVG.parsePath()
so that it now accepts SVG with coordinates in scientific notation such as3.14e-2
.It fixes #870 (and #816 too?).
I added a test case, but I am afraid it may not be enough.
In particular, the behavior of the function might change to some extent especially for 'ill-formed' SVG paths.
Please let me know if you have good test cases.
Thank you.