Storing custom measurements and pattern system measurements


Storing custom measurements and pattern system mmeasurements into each customer measurement file results in multiple measurement files per customer (multiply each designer x each patternsystem), and creates patterns that can be used only by the original designer.

This breaks the Valentina shareable patterns and sharable measurements model. It removes Valentina’s special sauce. Sharability is the very foundation of this project.

The pattern system measurements should be stored as macros. When a designer selects a pattern system, and has a measurement file selected, the calcuated custom measurements should be available in the meaasurements list, but are not permanently stored. Similar approach for custom measurements that a designer has created.

The current ‘increments’ approach works perfectly for pattern-specific measurements, as these are stored in the pattern. Designer’s custom measurements should be stored in the pattern as well. Pattern system measurements should be availalble in Valentina, so no need to store them in the pattern.

For ‘increments’ that


I understand your idea about using only known measurements and agree with it. This is very important for sharing patterns. But still forcing designers to use only knowns measurements will not work for all. Not all of them want to share own patterns.

It is like programming. Language one, but not all programmers cares about code style, documentation etc. For me problem you described lies in different layer. We declared that we do not tied to any pattern system. This mean all we can do here is to make recommendation about good practises if people want to share patterns. And make checking. For example like Debian do for own packages.

We can’t create flexible system and at the same time force user to use only known measurements.

I don’t agree.

You made good explanation about the nature of custom measurements

Custom measurements are designer-specific, pattern-system-specific, and pattern-specific.

Pattern itself is good place for storing only pattern-specific measurements. But different story for designer-specific and pattern-system-specific measurements. This is data about customer. Pattern should not contains information about this data inside.

Instead of one place you propose create two places where user will store data. This creates problem if you want edit this data. It easy to forget to do it.


No, this does not force designers to use only known measurements.

CUSTOM MEASUREMENTS: The designer creates custom measurements in a manner similar to increments. The designer can add custom measurements to custom measurement sets (eg. - ‘Overcoats’ or ‘Lingerie’). The designer can select custom measurement(s) or custom measurment set(s) in a pattern. The designer can choose default set(s) of custom measurement set(s) to auto-trigger whenever a new pattern is created. When manually selected or auto-triggered, the custom measurements are calculated and the values are accessible in the Measurements list. When the pattern is saved, the custom measurements are stored in the pattern.

PATTERN SYSTEM: The designer can select the pattern-system to use in a pattern. The designer can choose a default pattern-system to auto-trigger whenever a new pattern is created. The pattern-system measurements are accessible in the Measurements list. The pattern system name is stored in the pattern.

NUMBER OF MEASUREMENT FILES PER CUSTOMER: I’m working on creating patterns for over 50 pattern systems. I have 3 mannequins and 2 dolls to use to test patterns, plus myself and my friends. Let’s consider the mannequins, dolls, and friends to be customers. The number of measurement files I have is, potential worst case: 10 customers * 55 pattern systems = 550 measurement files. Let’s say I will only use 3 measurement sets to test any given pattern from a pattern system, so best case: 3 customers * 55 patterns systems = 165. Let’s say I am a normal patternmaker. I have been asked to create patterns from size 2 to size 12 (10 sizes). The patterns I have been asked to create are found in 3 patternmaking books. 10 x 3 = 30 measurement files

Data management becomes a problem very quickly.

Storing easily derivable values isn’t good data design. Also, storing these derivable values results in additional files so it’s even worse than just bad data design, it results in bad data management.

There should be ONE measurement file per customer, not many.

PATTERN SHARING: The current design breaks the ‘sharism’ culture that we’ve told the world that we are building. Measurement files and pattern files should be shareable. Doesn’t mean they have to be shared. All knitters don’t share their patterns, yet is successful.


Sorry @slpencer, but i am strongly against your idea.

Okay, i see. That’s good.

As i told you before rules of good design say that any customer data should be separated from pattern data.

So, in short your main problem is [quote=“slpencer, post:3, topic:548”] There should be ONE measurement file per customer, not many. [/quote]

And then you saying[quote=“slpencer, post:3, topic:548”] 10 customers * 55 pattern systems = 550 measurement files [/quote]

Very weird. Because when i want to try new pattern making system i just switch one setting and do not create new measurement file. Don’t you forget that for us do not exist such thing as pattern making system. We don’t care about this. We have been supporting pattern making system only on the level of names. This will make using the app more native for pattern makers. And that’s all.

So, in the end this is only changing translation and mapping names to selected pattern making system.

So correct calculation is not so bad

10 customers * 55 pattern systems = 55 measurement files

And i don’t see why to create new measurement file each time you want to try new pattern system. The measurements stay the same in any case. Pattern system is not about measurement name, it is about way of thinking, way of describing body.

Of course this will work good only for supported systems and measurements.

And in case of trying not supported system you still will use known measurements, but without native look. And all you need is to map names manually. And people actually do it when map customer data to new system. Then if you care about this system you should go to us and make a proposal to make it officially supported.

You do not expect Apple to support hardware they do not officially support. :wink:

Custom measurement exist for supporting measurements we do not support yet or won’t to support. And of course level of comfort in this case is very low.

You did not prove me this. :slight_smile: All i see is wrong using the tool.


I think the missing measurements the designers ask for fall in two categories:

  1. can be computed from existing Valentina measurements
  2. cannot be computed from existing Valentina measurements

Category 2 measurements are obvious candidates for adding them to the list of Valentina’s measurements. Right or wrong?

Category 1 measurements are trickier in the sense that, as long as the measurements needed to compute them are taken, they feel redundant. Is that the case you’re thinking of, @slpencer?

This is really a standardization conflict:

  • People prefer to use the measurements they know from their pattern drafting systems (be it the ones they learned or the ones they developed themselves).
  • When a pattern system measurement can be computed from two measurements that Valentina knows, I don’t think people generally want to take two measurements instead of one, even if that means their individual measurement files become less “generally usable”. Exception: people know that they want to use these individual measurement files with different drafting systems. In this case, they’d prefer to take only two measurements (the ones from which the third one can be computed), instead of three.
  • There are Valentina users who are not very much into pattern sharing (and thus, don’t care a lot about standardization and shareability), but rather into finding an affordable solution to replace “overengineered battleship software” where a license costs 3000$ (and upwards).

What one could do on an open source pattern sharing site:

  • Require (and check programmatically) that all patterns can be drafted using only Valentina’s measurements. This ensures that the people who download can get by with their individual measurement files that have all the Valentina measurements filled in.

@dismine I’m not up to date on how exactly individual measurement files work. Am I right that you can always add more measurements to a file? As long as there is no naming conflict between custom measurements, you’d be able to add values for all the custom measurements required by all the patterns you use to your individual measurement file?

If so, I think the main issues are

  • how to avoid naming conflicts and
  • over the time of using an individual measurement file, “garbage” will accumulate (i.e. data that is only applicable to one pattern that is never used again subsequently).

I suspect we need something like “Measurement set files” that allow to create a measurement set consisting both of Valentina measurements and custom measurements. If that doesn’t already exist. Then we could distribute files that contain, e.g. a “Mueller & Sohn measurement set” to get everyone who uses the Mueller & Sohn pattern making system to use the same measurements, i.e. having the measurement files for Mueller & Sohn be compatible across designers. (Same for any other popular pattern making system.)

I certainly think the body measurement app should come with preinstalled measurement sets for the popular pattern making systems. That will both make it easier to set up for people who use the particular systems and it will increase shareability of patterns since everyone is guided towards using the same measurements.

How do people currently deal with pattern-drafting-system-specific measurements?



All custom names begin with ‘@’.

This is price to use only one file per client.

Already exist.

This is exactly what i propose.

100% agree.


All custom names begin with ‘@’.

Yeah, that nicely excludes the possibility of naming conflicts between Valentina and custom measurements. The problem people using patterns from multiple sources will eventually face is naming conflicts between different custom measurements, I suppose.

I also think that the “garbage problem” isn’t really a problem since you’d probably recreate measurement files every now and then, anyways - due to changes in body shape. It would be rather strange to keep some old measurements around, then you never know when they were taken.

[“Measurement set files”] already exist.

Cool! Didn’t know that. Sounds like I need to look into how exactly they work.


And what did you expect? They used custom measurements (read not standard) and now complaining about conflicts. This is common thing. Going outside of standard is always dangerous.


So far, I think, no one’s been complaining about conflicts. And I agree it’s nothing that Valentina itself should be concerned with. That would be far out of scope for pattern drafting software.

I think it’s a matter for a pattern sharing community around Valentina to solve. As in, educating people to not use the same names, or by providing a central registry where people can “register” their custom measurement names so that no one else in the community uses them.


Now i think i know why so many pattern making application support so few systems. It is a pain in an ass.:confounded:


Haha, any case, I think the way you solved it in Valentina does make sense. That Valentina includes the most common measurements also makes sense, since then there’s overlap in measurements between the different systems. The situation would be rather sad if everyone was making custom measurements for their pattern drafting system. :slight_smile:


Ok, I looked areound a bit more, and I now think there’s two different things that are currently being called “custom measurements”:

  • actual measurements that are supposed to be taken on a person or object
  • computed variables that should be available in any pattern that uses a given pattern making system (e.g. Aldrich’s cuffs). These don’t feel like they belong into an individual measurement file, but rather into the pattern (or some kind of “pattern making system” file that is linked to the pattern). Though, currently, the only place to put them is in the .vit file (and, I suppose, it’s not the worst place to put these since, this way, as long as you’re using a measurements template for the correct pattern making system, the patterns will work)?

I do get that the situation is really quite complex. A pattern making system seems to consist of

  1. a set of Valentina measurements plus custom measurements (names + descriptions)
  2. a set of measurement variable definitions using the measurements above

Please correct me if I’m writing nonsense.

ETA: ok, I was mistaken again, there’s another case of custom measurement:

  • custom measurements that are taken on a person or object and that are related to an existing Valentina measurement in an obvious, back-and-forth-convertible way (e.g. Aldrich’s “Half Back”).
  • custom measurements that are taken on a person or object and that are related to more than one existing Valentina measurement in a non-back-and-forth-convertible way


@Sabine_Schmaltz You understand the situation very well.

From a design perspective: Storing generated data is always a bad idea. It takes complicated data relationships and makes them even more complicated. The simple elegant approach is to calculate them when needed.

From a user perspective: Please use Valentina. Create several measurement sets from body measurements, and make patterns for each from several different patternmaking systems, and add some custom measurements to the patterns as well. Put yourself in a patternmaker’s shoes and make an evaluation based on the ease of usability, how logically it can be made better.

From the project perspective: Valentina has advertised itself to be more than a hobbyist or small-volume patternmaker tool.


Did you try Increments? They work like individual measurements inside of pattern.


A system similar to increments is what I’m proposing.


The changes I’m proposing will allow us to upgrade to a measurement database in future if needed.


If I understand this right, the issue is that:

When the pattern maker selects a pattern making system for a pattern, it would be convenient if Valentina could automatically add the increments that were defined for the pattern making system to the pattern?

The main point of using .vit templates for pattern making systems seems to be that one doesn’t want to repeat adding the same measurements all the time when creating a new pattern using a given pattern making system. Instead, people want to set up the pattern making system once and for all and get the relevant measurement info added to their patterns automatically?


When the pattern maker selects a pattern making system for a pattern, Valentina would automatically calculate the increments that are defined for the pattern making system in temporary memory. The increments would be visible in the Measurements list, similar to the current method. The pattern system measurements begin with @.

One record is added to the pattern file – this record contains the ‘pattern system name’.

The pattern file will typically be opened by:

  • The original designer
  • Other designers that work with the original designer
  • Managers of the original designer
  • Someone who has purchased the pattern from the designer
  • (occasionally) The sewist/manufacturer who will print the pattern or send it to a cutting table

When the pattern file is opened, the correct pattern system will be selected and those calculations will be made using the ‘measurement file name’ stored in the pattern file.


The proposal doesn’t change this approach. The user won’t see much difference other than the number of customer files, and whether customer files and patterns can be shared by members of sewing co-operative businesses. I’m proposing a change to the data design.


If only possible to implement as you see it.

One question. Now i have one file with all known and custom measurements i need and connected it to 10 pattern files. When i use your way measurement file will contain only known measurements right? Custom measurements are inside patterns. What should to show Tape app when i open the vit file? Data from which of 10 patterns it should take? How can i store customer data if i need rewrite them with data about another customer?

The user will not see, probably, but i see huge amount of work we don’t need at all.

and whether customer files and patterns can be shared by members of sewing co-operative businesses.

This is organizational issue, not Valentina’s issue. I agree with @Sabine_Schmaltz in this case.

This sounds good, but who will create and manage all this rules? And this will not help you with custom pattern making system. I’d rather do not make such difficult system and allow pattern makers to set up environment themself.