You designed the collars to match the base patterns. Yes, you can use the neck measurement, but what if it’s a big neckline versus a tight neckline? Perhaps the unstated assumption here is that a any man’s tailored shirt collar will fit any man’s tailored shirt base. But what about fitting a man’s tailored collar-with-a-stand to a man’s loose hawaiian-type shirt? Hmmm. The collar probably wouldn’t fit, the collar stand would be too short to fit the neck line, the collar was designed to be tight against the neck, the hawaiian shirt was designed with extra east at the neck.
Hmmm… Perhaps add an ‘Import .val’ function. Have the user first select a point to base it on, then have a popup that prompts the user to enter formulas for the angle and all measurements referenced in it. (By default, if the measurements are known or have the same name AND value, the formula would contain that name, otherwise the actual value for the original measurement would be the default, if the measurement file can be found. i.e. ‘import:waist_circ’ formula is ‘waist_circ’, matching them.) That way, it wouldn’t matter so much what measurements were used for the imported part. Does that make sense?
The solution is to enable the design of a base pattern which has sub-patterns associated with it. The sub-patterns are options like sleeve types, collar types, etc. The sub-patterns aren’t applicable to any and all patterns, they’re only applicable to the base pattern that it was created for.
1 Like
I was part of the testing group for Dress Shop 2.0 back in the 90’s, and how that worked was you chose your neckline/blouse cut/etc. options, then it produced a complete pattern using those styles. I think that that would be a GREAT feature for LibreFashion 2.0.
1 Like
@KeithFromCanada That is the feature we are discussing here.
Dressmaker implements each option as built to specifics for it’s associated base patterns.
The difference is that our users can create those base patterns and sub-patterns.
We want to implement the suite of functionality which enables each user to create his/her own Dressmaker-type library of patterns.
Does everyone see the difference?
The number of possible ways to make a pattern is almost infinite in Valentina. So it is not possible to create sub-patterns which could match any base pattern. Sub-patterns (defined as .val files) must be built to match a particular base pattern. Which is what Dressmaker does – each pattern has a set of options built specifically for it, the options are not universal.
Valetina users could design their own Dressmaker-like library of patterns, with the same restrictions that DressMaker has – each option is built specifically to work with one base pattern, and each base pattern can have multiple options.
What we need are master patterns which contain the base pattern plus all options.
It may help to distinguish between the pattern designer and the pattern client.
The pattern designer creates a master pattern containing the base pattern and options. The pattern designer generates the base pattern and the option patterns and saves these to the pattern library (local at first, but later a website.)
The pattern client wants a pattern with certain options. The pattern client (or pattern designer acting on the pattern client’s behalf) opens the Pattern Library and selects the pattern and options. They then select a measurement file and generate the layout.
Why to restrict import? If it’s MY pattern library, I would know that this collar is for more fitted shirts (both man’s and woman’s, and shirt-like dresses, and jumpsuits, and whatever else will come to my head) and is not good for Hawaian shirt.
Also may be ok for Hawaian shirt to, if change it here and there after import, still faster than drawing it from scratch.
What you suggest, restricting pattern pieces for one particular base pattern, similar thing can be done right now - I can have a base pattern and 3 different sleeve options in one file and just exclude pieces I don’t need from the layout. It gives no flexibility at all
If we could implement the pattern as a tree (which has been started but not finished: Implement pattern as cycle-free directed graph ) then MAYBE we can change the formulas used to create the points in the options to utilize the points, lines, curves, arcs and measurements from the base pattern and its measurement file.
It remains to be seen that this can be done. I wish it could be done, but we need two things:
-
The pattern file format would have to be structured differently so that it doesn’t crash after certain deletions and other operations (which we’ve all experienced.
-
The measurement file format is changed so that it contains ALL measurements, even though some are zero, this may be accomplished, but the imported pattern at initial import may appear distorted if some measurements that it uses are zero in the base pattern’s measurement file. This can be fixed by the user by entering the correct measurement values.
Additional thoughts: The option pattern at time of import has no relationship to the base pattern – the user can manually update the option pattern’s formulas to match. The idea of an automated process is not one that will work - it is best accomplished by the user making the changes. Also, labels for the points, lines, curves, arcs and increments (pattern variables) will require a postfix to guarantee that they are not a duplicates of objects in the base pattern. And we may discover that a copy of the base pattern is better than using the original base pattern when an option pattern is imported.
1 Like
My earlier messeges are a mess, so I will try to summarize my suggestions again
-
A “minimum working” option. We just put a “random” number for neckline length when making a collar pattern, say, 46 cm. Then, after import, we replace it with formula that gives a sum of all curves of the base neckline.
-
A perfect (for me) option. There is a “preview calculations” tab. It works much like increments, but you can also use values from the pattern in formulas here - length of lines, curves, all sorts of angles. We have “preview calculation” “#neckline_lenght” in both base pattern and collar pattern so that after import a value from the collar’s “preview calculation” table is replaced with corresponding value from the pattern’s table
Yes, we need different measurements files for some combinations. It reminds me of idea with measurements file filters
I updated my comment above.
1 Like
Yes, I understand even the “minimum working” option needs a lot of work if possible at all. Wonder how many people find it as useful as I do
Hmmm… As a number of people have stated that they would be using measurements for more than one person, it would seem a good idea to include a directory of clients, with the measurements for all of the clients kept in that directory. (A ‘.vit’ file could be exported/imported as needed.) A particular pattern instance could be associated with a particular client and that client’s measurements used without needing to load another ‘.vit’ file. I would use xCard + ‘.vit’ format for each user, as a tailor’s client info would need to be more robust.
1 Like
This seems very do-able. It would only need a little message after importing the collar to say that the user should then adjust the formula for a particular object in order to complete the integration.
(As a proof of concept, I can probably knock-up these ideas in the pattern-cloud more quickly than doing it within Valentina. If it proves useful, perhaps after a few iterations of refinement, it could be moved into being a Valentina feature. If it becomes evident that it is not useful then it won’t have wasted any C++ effort.)
3 Likes
@MrDoo -
Before doing that, pleaaase:
1.) Can you fix the problem with the .val files where they crash when the tree is broken? This needs to be fixed prior to implementing the pattern library. Because the pattern library is based on adding new objects into the currently frail pattern object dependency system.
2.) Can you write the code to add the missing measurmements whenever a measurement file is opened?
I know it’s not sexy doing the foundational work first, but we will avoid a lot of pain points.
1 Like
Certainly I will. Generally the changes I’m currently working on are to improve the UI in key areas.
My current focus is improving the entry and management of measurements.
Regarding 1), I have a pool of .val files that I do an automated test on whenever I upload changes to the system. If you have an example of a file that the system fails for then please send it (sorry if you’ve mentioned it already and I’ve missed it.).
1 Like
Fantastic! Do you have Qt for your OS?
Do you need anything from us to help you make the code changes to complete the fix to the crashes in the pattern when deleting and moving objects: (This should be done before we add the function to import one .val pattern into another):
https://github.com/valentina-project/vpo2/issues/182
Yes, I have Qt set up and can build Valentina from source. However, I am nowhere near understanding the source though as I last did C++ at uni (25 years ago) and have been doing mostly Java since. (My first planned C++ change is I hope to add the ability to load an SVG as wallpaper to help migrate existing patterns.)
I’m not sure how the issue ref. you sent through relates to the pattern share system though? I’m happy to record bugs etc. on GitHub and respond to them. Maybe just a little more information about the problem would help me to identify the issue.
If there were one Valentina change that would really be a boost for the pattern share it would be to be ability to invoke Valentina on the server in order to validate definitively that the .VAL and .VIT files I create will load correctly. Is it worth my creating an enhancement request for this?
1 Like
Ok.
Say we import one .val file into another .val file.
And we still have the frailties of the current pattern structure.
We may have to deal with more frequent crashes,
Fix the current problem before introducing new ones.
1 Like
The individual measurements directory was created for that purpose.
Q: Are there XML elements in xCard that you need, that should be added to the .vit XML format? XML is robust, regardless of the elements and namespace used.
Great… how does that help inch users?