Path pattern fills #7280
Path pattern fills #7280
Conversation
test/image/mocks/pattern_bars.json
Outdated
| "bgcolor": "black" | ||
| } | ||
| } | ||
| }, |
There was a problem hiding this comment.
I'd like to keep pattern_bars.json as it was before.
Please duplicate the mock and name the new mock zz-pattern_bars-path.json.
This is wonderful feature.
Thanks @alexcjohnson for the PR. 🏆
We may introduce new features like this one in v3.1.0 not v3.0.0; even though one may argue that it's a low risk feature. BTW it requires extra testing on the python side, etc.
cc: @gvwilson
There was a problem hiding this comment.
OK - personally I think the mocks are getting a little excessive, and we'd be better off testing as many things as we can in one mock, which is why I just added this to one of the existing mocks. But I've made the change.
| ( | ||
| (nestedSchema.coerceNumber && valIn !== +valOut) || | ||
| (!isArrayOrTypedArray(valIn) && valIn !== valOut) || | ||
| (String(valIn) !== String(valOut)) |
There was a problem hiding this comment.
Because we're comparing the original data array to something we coerced off a deep copy, arrays that make it here will never be ===
Arbitrary fill patterns! For example geologists have all sorts of standardized patterns they know and love, and this lets you create any pattern you want. It still has the constraint of two colors (foreground and background) and a square unit cell, but now any svg path string is accepted to define the foreground color area.
I chose to do this by adding a new attribute in the
patterncontainer,path. We could instead put the path into theshapeattribute - in fact we only accept one (shapetakes precedence) and for drawing I combine them into one anyway. And this is what we do forline.dashfor example, there's an enumerated set but you also have the option of providing an arbitrary string in the same place. On the other handlayout.shapeshas apathattribute fortype='path'shapes and other attributes for other shapes. Alsoline.dashis somewhat awkward to describe (astringattribute that nevertheless listsvalueslike an enum?) andshape='<path string>'is a bit funny to read. I don't feel strongly about this though - if others would prefer to add this into theshapeattribute that would also be fine.