The discussion in #5976 is whether `Path.join()` should use a line
segment to close any gaps in the path caused by move operations, or by
differences in the end and start points of paths being joined.
The answer is yes, that is the intended behaviour, but people who read
_join_ might expect differently.
So I have made a few changes to clarify this:
- The new `Path.combine()` method combines multiple path instances into
a single instance without making any changes to the drawing operations
- Since `Path.combine()` is variadic, I have also updated `Path.join()`
to be variadic too, since that is more consistent.
- The old way of calling `Path.join(path, bool)` is deprecated and will
log a warning. Calling `Path.join()` this way will be removed in v4.
- Related to this change is how `Path.length()` should behave when there
are gaps in the path. Currently, it skips those. So I've added a
parameter that when set to `true` will include them.
- Added documentation for `Path.combine()`
- Updated documentation for `Path.join()`
- Updated documentation for `Path.length()`
The data returned by `Pattern.getRenderProps()` was not serializable as
we were returning `this` all over the place, thereby including marcors,
log methods, cyclic object references, and so on.
This commit changes that by implementing a `.asRenderProp()` method on
all of the various objects (stack, part, path, point, snippet,
attributes, svg) and only including data that can be serialized.
In addition, we no longer include the logs in the renderProps because
they are not related to rendering the pattern.
Instead, the new method `Pattern.getLogs()` gives you the logs.
A path that has no drawing operations or only a move operation causes
problems with the path offset code.
This will cause Path.clean() to return false in such a case, which in
turn will cause Path.__asPath() to return false when called from the
offset code.
We check this return value in the offset code and do not push this
segment to the offsetted path.
This fixes#3038
This closes#3056
This is a fix for bug #3038 which was investigated by @BenJamesBen
who also proposed a fix in PR #3056
However, after discussing the matter, we agreed it would be better
to have a generic method in core to guard against the issue of
spurious drawing operations.
This commit adds the `Path.clean()` method that does exactly that,
as well as its documentation.
This moves resolving of the config from the pattern constructor to the
init() method. The idea is that adding a part to a pattern is exactly
the same as adding a part to a design. In other words, late-stage adding
of parts would be no different as the config gets resolved after that.
This is currently broken in many different ways, but the unit tests
particular to this new way of resolving the config do pass.
