More marker fixes #307
Open
More marker fixes #307
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…due to the angles wrapping around)
… not sure if these scales in the non-viewBox case would ever be needed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following on from my previous PR, I've been working on-and-off on getting the orientation of markers correct, as well as fixing some of their types and sizes. As this is a bigger change than I anticipated, I've made a set of testcases to compare the results of the current repo and my fork on a few test SVGs (the before-and-afters being 'Kozea' and 'AgC/master' in the middle column).
A possible breaking change: instead of different sub-paths being separated by a
Noneinnode.vertices, the sub-paths are now in nested lists within the array. A new sub-list is added toverticesfor everyMorm, and coordinates and angles are appended to the last sub-list instead of the main array. This makes it easier for draw_markers() to handle the difference between closed and unclosed sub-paths, as the former should take the angle of the closing segment into account. I'm hoping the array isn't used in other places (within the library or elsewhere) in a way that would be broken by this change.The diff within the draw_markers() function may not seem that useful, since the main loop has been indented an additional level and the GitHub interface doesn't seem to have the option to ignore whitespace differences like some other tools do. The only parts that have changed there are the determination of the position and angle (lines 32–61 and 131 in the new file), and the size calculation at lines 84–95.