Clarify stroke dash array ordering #110
Conversation
|
We require contributors to sign our Contributor License Agreement, and we don"t have @b-wils on file. In order for us to review and merge your code, please contact @heathmill or @jcgregorio to get yourself added. |
| @@ -473,6 +473,8 @@ come before them in [[stacking order]]. | |||
|
|
|||
| {schema_string:shapes/stroke-dash/description} | |||
|
|
|||
| A stroke dash array consists of `n` dash entries, `[n-1,n]` gap entries and `[0-1]` offset entries. Dash and gap entries MUST all be in a continuous order and alternate between dash and gap, starting with dash. If there are an odd number of dashes + gaps, the sequence will repeat with dashes and gaps reversed. For example a sequence of `[4d, 8g, 16d]` MUST be rendered as `[4d, 8g, 16d, 4g, 8d, 16g]`. | |||
|
|
|||
There was a problem hiding this comment.
I think it needs to specify how the presence of the offset is determined. Presumably checking the type of the last item? (is offset always at the end?)
There was a problem hiding this comment.
As spec is currently written, offset could be anywhere in the array. Bodymovin seems to always export this at the end and I know Skottie assumes this position as well. The stroke example has offset as the first element which lottie-web seems to handle.
I think restricting offset to always be the last item makes implementations simpler, though I'm not sure if other authoring tools export this in a different position.
There was a problem hiding this comment.
Updated this to specify offset MUST be at end. IMO it's better to be more restrictive to start an we can loosen if there is a need.
|
Also, do we want this for 1.0.1 or 1.1? |
|
@cla-bot check |
|
The cla-bot has been summoned, and re-checked this pull request! |
My thought was 1.0.1 as the feature is already in the spec and this is clarifying the wording. It is a bit more substantial of an edit though, so could see a reason to push this to 1.1. |
This reverts commit 4ff761c.
No description provided.