Updated the changelog after recent features/fixes by @haasjona and
@woutervdub
Re-ran reconfigure to update README's with the updated contributor list.
This stems from the excellent work by @HaasJona in #6421 in which they
requested to double-check the zipper length calculation. Which I didn't
get around to doing in the code review, but was able to now.
Turns out there was a slight issue with it, so this resolves it.
I've also updated the wording to clarify that what we are calculating as
the __maximum__ zipper lenght. Since zippers typically come is standard
lengths, it's typically not possible to find the exact length you need,
so it's IMHO important to make it clear to the user they should always
purchase a zipper that is as close as possible, yet shorter than the
calculated maximum length.
We're using chai-string as it provides the `equalIgnoreSpaces`
assertion which we use in our SVG tests.
However, that package does not seem to be maintained, and lists chai v4
as its peer dependency. We've moved on to chai v5 and this is causes
issues in one of our github workflows as dependencies cannot be
resolved.
So, I've extracted the assertion we need, and dropped the dependency.
This plugin is used to draft designs for high bust rather than full
chest circumference. To facilitate that, we provide(d) a named export
called `withCondition` that checks whether the plugin is wanted, and if
so loads it.
Problem with that is that the conditional loading of a plugin applied
to the entire pattern. And since we support drafting patterns for
multiple sets (and use this to sample) this means that all of these sets
would either get the plugin effect or not, based on the first set.
So, to fix that, we have changed the lifecycle hook used by this plugin
to `preSetDraft` (from `preDraft`) and changed the `withCondition`
method to always return true.
This means that the plugin will always be loaded, and we have moved the
check that used to be in `withCondition` to the lifecycle hook.
In other words, this plugin will now always be loaded and will check for
each set whether it needs to do something.
This allows the conditionality to apply to each set in the pattern,
rather than to the entire pattern.
Note that conditionally loading plugins pattern-wide is still a valid
use-case. It just so happens that for this plugin, it was the wrong
approach.
- Added:
- core:
- Added the `Path.combine()` method
- The `Path.join()` method is now variadic
- The `Path.length()` now takes an parameter to include move operations in the length calculation
- lumina:
- Initial release
- lumira:
- Initial release
- plugin-annotations:
- The `title` macro now takes a `notes` and `classes.notes` as its config, allowing you to add notes
- The `classes.cutlist` config is removed from the title plugin, cutlist info is now included as notes
- plugin-i18n:
- This plugin now supports translation of nested arrays of strings, giving you more flexibility to concatenate translated parts of strings
- react-components:
- This Pattern component now supports translation of nested arrays of strings, giving you more flexibility to concatenate translated parts of strings
- sandy:
- Added a new *panels* option
- tristan:
- Inital release
- Deprecated:
- core:
- Calling `Path.join` with a second parameter to indicate that the resulting paths most be closed is now deprecated and will be removed in FreeSewing v4.
- Fixed:
- brian:
- Take biceps ease into account when calculating armhole depth
- carlton:
- Fixed a stray seam allowance path on the collar
- charlie:
- The back pocket welt (4) and front pocket facing (8) incorrectly indicated to cut 2 instead of 4 in the cutlist. Fixes#5791
- hugo:
- Fix issue that crashed the design when complete is off. Fixes#6006
- Base pocket opening on pocket height, rather than width of the garment. Fixes#6004
- Removed:
- plugin-annotations:
- The `classes.cutlist` config is removed from the title plugin, cutlist info is now included as notes
Shout-out to @woutervdub and @benjamesben for their many contributotions
to this v3.2 release 🙏
Originally, #5999 was filed to report issues with the sleeve on Jaeger
not responding to biceps ease as expected. Increasing the biceps ease
would actually make the sleeve more narrow.
Turns out, this is a side-effect of the way the armhole depth is
calculated in v3. We used to take the biceps measurement (and ease) for
that, but now we rely on the waist to armpit measurements.
In brain, we used this new measurements along with the
armholeDepthFactor option to locate the bottom of the armhole.
This means that when we change the biceps ease, nothing will change in
the briam armhole, which means the total sleevecap length target remains
unchanges.
However, in Jaeger, increased biceps ease causes a taller sleevecap, and
since the total target sleevecap length (inherited from Brian) remains
unchanged, the pattern accomodates by making the sleeve more narrow so
that the taller sleevecap has the same sleevecap length. This is what
results in the counterintuitive behavior where increasing the biceps
ease makes the sleevecap more narrow.
This resolves that by taking the biceps ease into account when
calculating the bottom of the armhole in Brian. As a result, changing
the biceps ease will impact the armhole on Brian, which will in turn
influence the target sleevecap length that Bent drafts a 2-part sleeve
for, and now things work as aspected.
Given that Brian is such a foundational block, making changes to it is a
high-stakes game, but I feel this is a bug, so we need to fix it.
Fixes#5999
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()`
