I have found a double entry in the SeamlyMe database. G12 is entered once completely as expected and again below the former, just reading ‘measurement’. SeamlyMe 2024.1.1.152 on Windows 10
3 Likes
Thank you for noting this. I see it’s the same on mine. I’m sure @Douglas will be by shortly to correct it.
1 Like
Confirmed. It’s been there all along… before any work I’ve done on the apps. I always check first in an old version of the app just to make sure it wasn’t somethig I introduced.
I believe the intent is making “size” the same as the chest measurement… which in many instances that is the case. LIke a size 38 jacket is based on a 38’ chest. In other words it’s the same measurement, just a different name. Problem is we can’t just remove “size” as it will break any existing patterns that use it.
Also it presents no issue… even if you use both. In fact there may evenn be a useful reason to have both:
That being said… IMO it should be the same as the full chest measument G04 bust_crc. We can change the Id number and description, but again we can’t delete it. Changing the id number may? confuse some users that expected size to only be the front chest measurement, but it won’t break the pattern.
3 Likes
Just checking the code and tada:
// size and bust_arc_f are synonyms const QString size_M = QStringLiteral("size"); // G12 const QString bustArcF_M = QStringLiteral("bust_arc_f"); // G12
Does anyone disagree with changing the measurement group id & description to reflect the full chest measurment bust_circ?
2 Likes
Why am I NOT surprised. Nothing is EVER as it should appear with the apps. Digging further we come upon this:
m = translate("VTranslateMeasurements", "size",
"Name in a formula. Don't use math symbols and space in name!!!!");
g = translate("VTranslateMeasurements", "Size", "Full measurement name.");
d = translate("VTranslateMeasurements", "Same as bust_arc_f.",
"Full measurement description.");
InitMeasurement(size_M, m, g, d, "G12");
and following size_M we get to here:
void MainWindowsNoGUI::setSizeHeightForIndividualM() const { const QHash<QString, QSharedPointer > * vars = pattern->DataVariables();
if (vars->contains(size_M))
{ VContainer::setSize(*vars->value(size_M)->GetValue()); } else { VContainer::setSize(0); }
if (vars->contains(height_M)) { VContainer::setHeight(*vars->value(height_M)->GetValue()); } else { VContainer::setHeight(0); }
So, as one might recognize… size_M or “size” is related to multisize patterns. And yes… A01 or the 'height" / height_M is the other part to the multisize variables. Basicslly if you use the size & height measurements, they are used in the GUI to set the size & height variables in the container… which I assume ( 
) does things like set the combo boxes in the status bar when a patten / measurement file is loaded. Which could then explain why I wondered awhile back why the comboboxes were not loading with the box set on the (base?) size, but rather as item 0.
Maybe @Grace has some insight as to why “size” / size_M in multisize patterns would be the front half of the bust measurement? And shouldn’t it represent the full bust measurment?
3 Likes
Nope! I have no idea. All that I do know is that G12 - Bust arc, front is reflecting a formula in your example, which isn’t allowed in multisize files. And (evidently) the EU sizes used in Seamly are based on the bust measurement (in inches) divided by 2 (which, to my pea-brain, doesn’t make sense, anyway), so to have the formula, one will need a size item in the EU sizes, so it was probably easier to give it a special place grouped into the same code as the bust_arc_f code.
I use the size code to set the sizes in which ever sizing system I’m using for use in Increments, so the formula won’t work for me.
2 Likes
Grace, your brain is correct! There is no common denominator for EU sizes being the bust/2 (in inches). My (being a man) shirt is size 40 and this is measured by the neck-circumference. My wifes bra measures 75, which is under-bust-size. EU 38 is bust size 35" and EU 46 is bust size 44". BUT go to a different shop and their sizes my be off by an inch (or 2,54cm) either way and still they will say they follow EU sizes. These are murky waters with not much of common ground. We do not even mention UK sizes which are a whole different kettle of fish. Which makes the use of a common ‘G12 Size’ impractical to say the least.
1 Like
That’s the opposite of what Grace said…“And (evidently) the EU sizes used in Seamly are based on the bust measurement (in inches) divided by 2 (which, to my pea-brain, doesn’t make sense, anyway),”.
The thing is “size” is synomous with “bust_circ_f”… which may or may not be 1/2 the bust circ. Also from myy expereince with dealing with all kinds of military surplus (including Spanish, German, Russian, Japanese, US in various units & size systems)… the “size” of a jacket was always related to the chest size… NOT 1/2 the chest size. So I have no clue why size duplicates bust_circ_f? The original dev did some things that are not standard practice.
That being said… like I have already stated, we can’t remove “size” as it’s required to keep the schema valid, and not break existing patterns. All I would do is change the id num and description to make more sense going forward… if that seems the thing to do?
3 Likes
Ah! Thank you for the confirmation that my brain is still intact 
I was thinking more in the case of cup sizes. If one measures the front arc of the bust line and then the back arc, the 2 measurements should equal the total circumference, but it’s very seldom that the 2 measurements will be equal to the half of the bust circ. So to put in a formula just doesn’t make sense, however, by including the ease in the formula, I guess one could get away with it in most easy-fitting garments.
It’s like I keep saying… The sizes are only numbers that are used to facilitate the increases added to the base measurements when one changes the size of the pattern.
Waaaayyyy back… I seem to recall that size was in the “A” section under the Height measurement and then it disappeared (much to my distress) and when I begged for it back, it came back there. I’m not too sure who actually put it back for me - I didn’t question - I was just too happy.
Yes, removing it will really nullify a lot of my teachings here on the forum, and most of my patterns. Ummm… I don’t mind if you change the ID Number - I would suggest somewhere around the Height measurement since both have an affect on resizing patterns.
2 Likes
Lets (not) get me going on cup sizes. Well a short rant perhaps. (And going majorly OT) Where the cup of a bra 75D may (or may not) be the same as it going one size up in circumference and going one size down in cup measurement. Thus the contents (not the circumference) of a breast cupsize 75D should measure the same as 80C. My teacher would get in a tailspin at this and usually end up by saying: ‘just draw one that fits’ I wasn’t particularly good at bra’s, to much fiddly stuff. I did manage to get my certificate non the less.
ps would changing the ID not be counter productive when all ID’s that follow have to shift one ID number up because of that change?
2 Likes
The id num really only exists as a reference to the measurement in the diagram. The description, while also a reference to the diagram - more specifically how / where the measurement is taken - it carries a bit more weight than the id. Again the question is “what is the size measurement variable supposed to represent - the bust front OR the full bust?”.
As far as putting the size with the height, it kinda doesnt make sense , as the size measurement (be it G12 or G04) is part of the G diagrams not the A.
That being said… what about if we create a new [to be named] group before the A group… create new diagram pngs, and call size - A00, and height - A01? That way it groups those 2 together, which seems to be the intent with using them in multisize measurents.
3 Likes
The id num is hardcoded into the variable… they’re not a row or list number. It can be named anything, and placed anywhere in the list, nothing is going to shift. If we wanted we could give size_M an Id of “SIZE” if we want. Variables are referenced by the variable name… in this case size_M.
InitMeasurement(size_M, m, g, d, “G12”);
2 Likes
Perhaps, since is is actually an arc, it could be renamed G00, then everyone will be happy. I don’t think it actually needs a reference on the image about where the measurement should be taken, since it could be the bust or the neck or just a number (e.g. Size 6) to convert the existing size to whatever size chart one is using.
1 Like
Yeah-yeah! I also tend to just roll the eyes around and wonder why any garment needs to fit so exactly and then one adds ease which tosses everything out again.
Understood. In fact it doesn’t even have to represent a circ or arc… it could be a shoe size, a hat size, etc. It’s really just a generic variable… with the exception that currently it’s hardcoded to the mens GOST cm sizes as far as the GUI is concerned.
If you made a garment fit exactly - ypu could never move. .
Unless of course itt’s a strech fabric pattern such as a bathing suit or leotard.
3 Likes
Has to do with blood flow, stretchmarks (etc) and comfort. 
but I’m sure you knew…
Oh and current fashion has a word to say.
1 Like