This started out as a fix for #5753 after I felt the approach in #5760
was not the best way to handle this.
The problem lies in the way the cutlist data is added to the pattern by
the title plugin. The whole cutlist thing was added by a less
experienced contributor, and they were a little too focussed on what
they were trying to accomplish, rather than keeping an eye on the big
picture.
In this case, a bunch of points get added to the part to anchor all of
the text for the cutlist. This causes problems when inheriting parts
because points are added per material, and now we don't know what
materials were used and how to remove these points.
I appreciate @woutervdub effort to resolve this in #5760 but as I
mentioned above, I don't love the approach.
Rather than finding a clever way to remove these points, I am of the
opinion that they should never have been added in the first place.
Specifically, all we are doing is adding one or more lines of text. The
idea that you need multiple points for this is an incorrect assumption,
and therein lies the root of this problem.
So, this refactor adds support to the title macro for 'notes'. These
notes will be added below the title. The cutlist info is now just
prepended to the notes. So it stops being something 'special' (which it
never should have been) and instead just behaves like other text that is
placed on the part by the title macro.
The only flanking measure required to make this happen was to add
support for nested arrays in handling text.
This way, you can pass a nested array to concatenate strings in such a
way that each part will still be individually translated.
And as all text in FreeSewing, to force a linebreak, you just use "\n"
as The Dark Lord intended.
This builds on the fix by @woutervdub in #5449 that ensures the
rmcutonfold macro removes the cutonfold info from the store.
However, the same problem applies to the grainline data which can be set
by both cutonfold and grainline.
So I've added that. And while I was at it also created explicit methods
to remove this data instead of having to pass in false which I found
counterintuitive and a throwback to the v2-ways.
In addition, the grainline can be set by both grainline and cutonfold
macros. So when we remove either of them, we should only remove the
grainline info if it was actually set by them. But there's no way to
know that at remove time.
So I've also added the logic to set grainOrigin in the store which will
be `cutonfold` or `grainline` depending on the macro that set the grain.
The cutlist methods were being clever by deducing whether a part should
be cut on the fold from info set by the cutonfold macro.
This is a footgun, because this only works when the cutlist is set after
the cutonfold macro is run.
We can't expect designers to know they should add this annotation before
that annotation so now you need to add it explicitly.
The current keys to pass are:
- cut
- from (used to be material)
- onBias (used to be bias)
- onFold (replaced ignoreOnFold)
