El primer problema está en el archivo de medidas. No es el archivo de medidas que se adjuntó al patrón, asà que no pude corregirlo. Los archivos de medidas antiguos de Valentina ya no son compatibles con V6 Seamly, asà que tienes que abrir tus archivos .vit y .vst y guardarlos como archivos .smis y .smms.
El segundo problema es que los arcos no coincidĂan. El punto A22 tenĂa la fĂłrmula: (@PECHO/2)+(@PINZA/2). Si @PECHO es la medida de la circunferencia del busto, entonces deberĂa ser: (@PECHO/4)+(@PINZA/2). He cambiado esta fĂłrmula y ahora el patrĂłn funciona, pero hay que prestarle atenciĂłn.
The 1st problem is with the measurements file. It’s not the measurement file that was attached to the pattern, so I couldn’t correct it. Old Valentina measurement files are no longer supported in V6 Seamly, so you need to open your .vit and .vst files and save them as .smis and .smms files.
The 2nd problem is that the arcs weren’t meeting. Point A22 had the formula: (@PECHO/2)+(@PINZA/2). If @PECHO is the bust circumference measurement, then it should be: (@PECHO/4)+(@PINZA/2). I changed this formula and the pattern is now working but will need some attention.
What happened when I’d loaded the multisize file is…
I got the 2 errors connected to the 2 arcs that were diverted to the point of origin and then the wheely-thing rotated a bit as if it was loading the pattern and then the pattern just closed. It did this every time I tried to open the pattern.
The 1st arc said that it couldn’t place the point at 179.???° so I tried adjusting the arc start to 170°, but this didn’t work. I changed the arc’s length formula to +3 instead of +1, but this still didn’t work. I changed the formula back to +1 and noted that the formula referenced A22, so I checked point A22 and noticed that the formula was Pecho/2. I changed it to /4 & the pattern loaded without any other loading problems, although the armscye is a bit strange, which is probably because of the formula that I changed.
I hope this helps you to see what happened from my perspective.
Technically I assume it would be the “chest” measurement as in “pectoral” muscles. In women the chest is a different measurement than the Busto (bust) measurement. In this case the measurement file has 3 measurements - @Busto, @CBUSTO, and @PECHO all with the same value.
And I just thought of something that may solve the issue of having alias names for the measurements… which would allow patterns to have the translatable Known measurement names AND non translatable custom user alias names. Known measurements make it easier for reading a pattern in one’s native language, where as custom names make it easier to match certain pattern systems. My soultion… add an alias name column to SeamlyMe like Ive previously discussed, but along with a user “Pref” to be able to switch between the known name or the alias in Seamly2d. The pattern would always be saved with the known names in English. Think of it as the app is either translating the measurement names from the translation files or from the alias names.
Wow! Amazing!!! So we could have a measurement, either Known or Custom, and we’ll be able to give it an alias and assign a language to the alias. So…
In the case of M&S, we can have the custom measurement @BG in English and the alias abbreviation @Bu in German and, in the pattern, if the language is set to English, it will show @BG and if it’s set to German, it will show @Bu.
No, I realise that, but if we can manually assign a language to the alias, perhaps from a dropdown that has the same languages as the Seamly app… Then it won’t be translated in the .ts but the app will automatically select the alias if the app language is changed. (Time travelling again )
Ah… Ok. YES. This could work. Especially if we allow duplication of the Known measurements in the name and alias column… where Custom measurements would have English “names” and Alternate language “aliases.” If the selected app language is English, both the Known and Custom “names” would be used… if another language is selected then Known “aliases” would automatically be translated, while the Custom measurements would just use the “aliases” that are in what ever language used. There could be a tag set in the SeamlyMe for the alternate language… and since a language change signal is emitted whenever the language is changed (this is how the GUI knows to update the translated texts) - SeamlyMe could be connected to the language change signal, and if the now selected language matches that set In SeamlyMe, it now uses the aliases. Of course one could have multiple SeamlyMe in different languages for the aliases.
Hola. Disculpa la demora en responder. Gracias por tu ayuda.
Descargue los archivos que arreglastes para mi, pero me sigue dando error. Me envia el mismo mensaje anterior. No lo puedo abrir.
En cuanto al primer problema que mencionas, no se como pero, puedo abrir patrones con los archivos de medidas .vst en Seamly2D incluso en la ultima version.
Pero seguire tu consejo de guardarlos como .smms
Encuanto al segundo problema que me indicas no lo puedo corroborar porque el archivo no se me abre. Me esta pasando con varios de los archivos que intento abrir. Aunque con otros no.
Ok, aqui está o seu padrão que @grace corrigiu… que eu adicionei o lineColor às ferramentas cutSpline. Isso deve corrigir o arquivo e ele pode ser aberto.
Ok here’s your pattern back that@grace fixed.. that I added the lineColor to the cutSpline tools. This should fix this file so it opens.
Now… I think I may know what the issue is. Since it looks like you’re on Windows… if possible can you open up the .ini settings file and search for the setting “defaultLineColor” and if it has an = some color name?
The ini file is located in : C:\Users\username\AppData\Roaming\Seamly2DTeam\qt6_seamly2d.ini
If you can’t find it… then open Seamly2D and save your default pen setting in the Pen Toolbar, then try to open the unfixed pattern file. If it opens then I know what the issue is, and I already have a fix in the works for it.
I was more interested in seeing what the defaultLineColor setting is in the ini file as I was thinking it may be a similar issue to the background color coming up with a black background if the setting has an empty value. An issue I fixed, but since @Damay is showing defaultLineColor=black that does not seem to be the issue here. So I’ll have to dig deeper why the Point on Curve is not implicitly writing lineColor=“black” to the file in the case where the color has been left to the default black.
I didn’t get the lineColor error (with the same app version as @Damay) either. Which is why I was thinking along the lines of the default settings. But… I think it is fixed… because I fixed the backgroundColor.
bear with me… when parsing the CutSpline tool (Point on Curve) it first reads:
For one the default value should be lowercase “black”. 2) The default setting we should be looking at is the pointNameColor… not the defaultLineColor. 3) Unbenownst to me - when you call Settings->value(), if the key exists, but the value doesn’t, then value() does not return the default “black”, it returns “”. Value only uses the default if the key doesn’t exist. So when parsing the pattern it’s trying to validate the lineColor with a value of “”, which is not a valid color in the schema.
So… to summarize… since I fixed the prefs to always return the default for color prefs, the issue of a tool lacking a lineColor attribute should no longer be an issue. Fingers crossed.