I couldn’t find that this idea has come up before, and if it has, I apologize.
For consideration:
Currently Seamly limits the definition of the size code to a series of numbers that are not used in my country (Canada). In order to print the size on my multi-size patterns, I have a workaround that isn’t that great, but attempts to allow me to know that the printed pattern label is size 34, but 34 really means size 8.
If Seamly must keep the size code to the existing series, could the user have the ability to map 34 to 8, so that the label could show 8 automatically, not 34?
This has been on my mind for sometime. Just wondering if this might be a change that could be considered in the future.
Thats due to the fact that the original dev programmed the multisize around Russian sizes… in metric.
It could be, but 1) The sizes are all harddcoded which will require a lot of work to make it dynamic. 2) It possible that the multisize will be completey replaced by something more workable.
Hi @SandraB
Yes this problem has been visited a few times - and I’m the culprit. Let me tell you what I do as a workaround…
I create a Size code. In this case, my base size for my measurements file is size 36, but you can create yours to be size 34 and enter 8 as the base value and increments of 2.
This way, you can keep track of the sizes - mainly just to jog your memory - and you can also use the sizes in formulas and/or the Variables Table. You can read more about how I use the variables on my blog which is very basic, hasn’t been added to for a while and has no affiliate marketing
Thank you for your response Grace. I read your blog. I think I understand why you are using a custom variable. I came across this and didn’t understand what the program logic was to create a custom variable, so I got around the change in increments across sizes by creating groups of sizes with the same incremental change in the measurements. Problem with this is that it results in duplicated size names across the groups. But it is working ok for what I am doing right now.
However, I wanted to explore whether the custom variable could work with the label. I see the size in the label is called “%size%”. If I create a variable called “Size_Code”, could I use the If, Then, Else logic to say if %size%=34?8:%size%=36?10…" etc? But then, I don’t think so bc how do I get the label to print the Size_Code?
Nope, that won’t work. It will give the size that you choose at the bottom, that gets recorded on the label - so it will say “Size 32”. I don’t mind that because I export my patterns to SVG for nesting and adding certain things like the “place on fold” arrow (among other things) and then I change the 32 to an 8.
OK… I got an idea. First can I assume that these are the sizes that hardcoded… and thus get replaced in the label of the pSize placeholer? If so, instead of hardcoding these in the def.h header file, we put them in the preference settings… with these being the default values. The user would then be free to establish their own range of sizes. it would take a bit of fanagling the GSizes enum (and I assume the GHeights), but does this sound like what we’re after?
So instead of the 26 sizes being coded as S22=22…S72=72, it could be S1=8…S26=64, where the size value is variable based on what is in the prefs. Or taking it step further… make the sizes “presets” where you could load a list from any number of saved sizes.
Yes Douglas, this sounds like it might work. For the systems I worked with at the gas company, we defined a user variable that equated to the system value - or something like that - that was back in the 1990’s - LOL. So, yes, if I understand you right, this is what I’m looking for. If you are going to work on this, I might be able to test it with you if you like.
Hi Grace, I figured that. I have exported as a SVG too and worked with the labeling etc. in Inkscape. Inkscape is fantastic. However, the process I was using was time consuming, but fun actually. I was just hoping to find something within Seamly, if possible.
I looked a bit deeper into this… will also have to change and convert the attribute tags in the pattern schema as the “sizes” element is hardcoded as well with s22 to s72.
It’s unfortunate there is so much hard coding…can you comment them out so they’re there if needed down the road? Or if this code is not used, then I agree it doesn’t make sense to hold on to it and to convert it.
For the most part, that’s exactly what a schema is - hardcoded tags that may or may not be required. The < sizes > element has to be there if you’re loading an existing multisize pattern. It determines which size items are displayed in the dropdown box. When I say convert it, if you change the XML schema you have to convert the old schema to the new schema. So for example… if I switched the tags from s22 - s72 to s1 - s26, the conversion routine has to search for < sizes >… then search for “s22” and replace it with “s1”, and so on to “s72”. As far as conversions goes this is pretty straight forward as it’s all within the single < sizes > element.
Hi @Douglas, yes, this could be an option.
Here is a screenshot that I quickly searched for on the net:
It has a few countries sizes in, just for interest-sake.
Ok, so what my experience and thinking is this. Why do we need to be confined to numbers from 22 upwards in increments of 2? In actual working, these are just even numbers and we’re limited to go below 22, and this doesn’t even help when it comes to children’s sizes or dolls. And these numbers are only used to say:
Base size = 32
Increments = 2
If I change the size then the measurement must be divided by the base size and multiplied by the base size + the number of increments above it. Something like that.
So what if we can start a new measurement file and say that this file’s measurements start at 2 and covers the next 6 sizes and the increments are 2. In other words, we choose the start and end of the measurements in the list at the bottom and the steps. In this case, we’ll get 2, 4, 6, 8, 10, 12 - so we won;t be bogged down by miles of list in the choices. And we can choose to say it starts at 1 and increases by 1 over 10 sizes.
This way, the other nations who start their measurements at 00 will be the only ones who will have a problem, everyone else can choose their method of sizes.
In my suggestion above, the older measurement files could be converted to a start of 22, end 72, increments 2, to keep them true to what they were created as.
Grace, great points. There are some children sizes that are not incremented by 2. Eg. child size 6, 6x, 7, 8. Sometimes they’re odd numbers or even. One of the commercial pattern companies Jalie, that I reference uses letters rather than numbers. Canadian are not always the same as US. Zero is common. Plus, regular, petite. So flexibility would be needed. Ideally user defined.
When I use seamly, the combination of height and size determines my net size. Wouldn’t this mean that we would need to make a similar change to the height as well as size?
Yes, children’s sizes are often according to age and the x is probably for tall or a bit heavy for their age. One can never create something that will suite all size charts around the world and across the spectrum, but I think this can be modified to create your own ‘in house’ size charts. I know of some who use alpha, alpha-numeric and others that only use a symbol. I don’t think it’s viable to cater for everyone, but I’m sure we can make it easier for everyone who is learning patternmaking or learning to use Seamly to have a kickoff point that actually makes sense to most.
The height option is very difficult to use, since there are very few patternmaking systems that give you the miniscule increment for height along with the size. Most patternmaking systems for women make patterns for 164cm or 170cm tall ladies - I’m around 162cm, so I always have to make everything shorter. This is where one finds “Increase length here” lines on a pattern, which is normally good enough for me. I totally ignore the Height increment and only use the size increment.
Another anomaly that one must bare in mind is that most patternmaking systems only produce patterns for a B cup bra and it’s very hard to grade the pattern from a B cup to J cup. These are things that you specialize in with your patternmaking. There is no way a measurements file can allow for this automatically.
It’s the same when it comes to plus sizes. Every person who wears a plus size may not be overweight. It may only be that they’re tall, or they’re pear shaped. It’s not easy to create a multisize measurement table for these, either.
I would suggest sticking to the normal height and B cup sizes until you have more experience and then you can create your own measurement charts for the different categories of measurements. Or you can work strictly off the ASTM charts for the different sections. It’s totally up to you, what part of the market you service, what are your plans for the future and then direct your energies to creating your measurement charts to suit your needs. I’ve had a lot of fun with this and now find that I pretty much know my size 34 is an 8, etc. so that I don’t have to flip between the SeamlyME to check what size I need to print my pattern in
It all boils down to “Start off as you mean to go on”.
Unless there’s something I’m missing, this is my understanding of the “sizes” (and the heights, but we’ll stick with the sizes for discussion). There is a list of placeholders - defined in the GSizes enumerator GSizes::S22… GSizes::S72, which are used in switch statements… these could easily be named S1…S26. The enum is also used to fill the dropdown boxes… depending on which sizes you choose to use (and are set to “true” in the XML < sizes >) the code reads the value of the enum and adds it as a dropdown item. So if you use S22, the the first item in the drop down is 22… and so on. If we change the values in the enums - which can be anything - for example lets says we set GSizes::S22 = 999… then if you use S22, the item in the dropdown will display “999”.
Or to put in in spreasheet terms we currently have 26 sizes with
as far as I know the value of the size is not used in any calculations, but maybe the (row) count is… based on the “increment”?
As I 'm thinking this further through, it might make sense that the user defined set of sizes gets embeded in the < sizes > element in the pattern XML… that way the size set stays with the pattern. So we would extend the attributes to be something like
And again… further down the road we could implement “presets” for the size chart… such as in the chart you posted, so a user could simply select from a drop down a preset size set, without having to fill in a set of sizes in the prefs.
I think I might have misinterpreted the use of “height” in the SeamlyME manual. I have incorporated it into how I do my sizes. I had understood that if the measurement was vertical, the increment was to be entered as part of the height, and if it was a width, the increment was to be entered as a size. I am not using all of my measurements, so perhaps this has not caused me a problem yet for that reason.
In the pop-up there is a list of items that I can select to be on the label. Any chance I could define a variable that can be printed on the label? i.e. have a way of converting size 34 to another number/ character, for eg. 8 and printing 8 on the label (could allow a combination of letters/ numbers)? Perhaps in the custom variable field, if size is 34, then “My Size” is 8. Then be able to see “My Size” on this pop-up and select it to be printed on the label??
Well… you’re not going to like my response… the placeholders are also hardcoded. They’re also translated, but that’s neither here nor there. < sigh >
I’m assuming they have to be tied into the schema as well. The issue is programming it so that the placeholders can be embedded with the pattern file, Otherwise if the pattern is shared (which is the BIG picture idea behnd the project), that placeholder and it’s contents has to be visible to whom ever is using the pattern. Saving custom placeholders in a user’s settings won’t work, as not everyone would have your settings.
I guess what I’m getting at, we would need reserved placeholders for custom user defined placeholders. Does that make sense? That being said… I think the better solution in the long run is to figure out how to make the range of sizes user defineable. That way it would all be cohesive between the UI, labels, and XML.
Sigh I see it is not an easy solution. I was hoping there may have been something quick. I think I read that the whole size routine may be re-written at some point? I will wait for that with interest. Thank you for your time Douglas!
I see it is not an easy solution. I was hoping there may have been something quick. I think I read that the whole size routine may be re-written at some point? I will wait for that with interest. Thank you for your time Douglas! 