Semantic dictionary to define object types

[slspencer]

@Stinde wrote: I have some challenges to utilize the colors. The basic problem is that I’d like to use colors for special purpose like measurement line (currently always green). If I use more colors I cannot always remember the meaning.I’d like to name the colors for certain purpose then I can use more colors.The lines are so thin on the screen that it is difficult see the color. The colors should be bright.

@dismine I think this is about Issue #476.

If I read all of this correctly, you would like to have a dictionary of object types. The dictionary is accessible by all patterns, not limited to one pattern. The dictionary allows you to:

• Define object types
• Assign name and meaning to each object type, such as ‘measurementLine’ plus an optional description.
• Assign attributes to each object type, such as color, thickness, dash In Draw mode, when you create/edit an object you could assign an object type to it

Question: How could this fit into a collaborative workflow where patterns are shared with a team?

[dismine]

I don’t know how did you come to this conclusions. Why so difficult?

@Stinde just can’t remember color meaning. Common issue for maps. Don’t you think? This is issue about “map legend”.

Map legend can be part of pattern description.

[slspencer]

Cool beans! Just thinking like a software engineer. Is you point out, it’s not always about software design!

So @stinde, what do you think about the map?

[Stinde]

Yes, the legend is enough for basic use and for remembering. My real need is still classify the line width, type and color for certain use like

• support line ( waistline, hipline …)
• measurement
• Basic block
• Interface line
• Lining line
• Interlining line
• Pattern line
• Optional pattern line
• Pocket line
• Dart line
• Pleat line

It would be easier to select the type of line from a list when addling point, than looking from the legend the type and selecting the right type and color from the drop boxes.

For me the green is enough, but when I’m sharing the designs I would be readable and informative to the others.

[slspencer]

It would be easier to select the type of line from a list

If you want a dropdown list of types then you need a dictionary to define those types and assign name & color & line thickness, etc. The dropdown list is created from the entries in the dictionary.

[Stinde]

Yes, that would be a nice feature in Valentina.

[slspencer]

So the dropdown list of line types is the feature you’re asking for?

[Stinde]

The feature could be

1. User can create his/her own list of types (line type, color and width)
2. User can select the defined line from a drop down list when creating point or line ( this should be possible also for curves)

Comments?

[dismine]

Comments?

Unfortunately yes.

User can create his/her own list of types (line type, color and width)

Do you know any program that supports custom types? And also this mean you should save all custom types inside a pattern file. This brings again problems with scaling this approach. Because i think you want share your styles across patterns.

Color and style maybe, but width 100% no. This is not Inkscape. Such things (width) should be more strict.

[Stinde]

From my point the color and style are informative and needed. The line width is more related to the pattern visual aspect like highlighting something.

[Jonas_Hauquier]

Hi, allow me to chime in here

[quote=“dismine, post:9, topic:587, full:true”] Do you know any program that supports custom types?[/quote] Yes, you don’t need to look far: LibreOffice

Here you see an example where I am adding a style type called “new semantic meaning”. Note how the LibreOffice people implemented this: you add your custom style element as a child to one of the many predefined style types (semantic meanings). In this example, I created a custom type that is a sort of “Emphasis”.

I think you can copy this approach directly: Introduce a list of semantic meanings, specific to pattern making. This will probably be something like: fold, cut, seam, helper, … That way, computers and other software will be able to understand the meaning of each of those. If a user decides to create sub-types for those, eg different kinds of folds they want to use, to somehow put emphasis on certain folds, they can.

Then they can modify any style properties related to that semantic meaning.

And also this mean you should save all custom types inside a pattern file. This brings again problems with scaling this approach. Because i think you want share your styles across patterns.

Yes, I would save styles separately from patterns. A pattern can be loaded in every configuration of Valentina. If you don’t have the same style selected, the file will simply render differently on your screen. This is actually a feature, not a bug. I can imagine myself getting used to one color coding for reading patterns, I’m not interested in the color coding someone else is using, I’m just interested in understanding the pattern. The same goes for a piece of software or a machine that tries to open the Valentina file.

I think a legend is just a patch-up hiding the real problem. If you do consider some kind of legend, ask yourself this question: will another piece of software easily be able to interpret the legend, or is it a visual queue for humans only?

Without having any specific knowledge of Valentina’s file format, imagine that it’s XML, I can see a definition of a line looking like this: <pattern name="pattern1" style="myStyle" author="me"> <line type="cut" custom_type="new semantic" >line data</line> <line type="fold" custom_type="important fold" >line data</line> <line type="fold" custom_type="regular fold" >line data</line>

As you can see, each line has a semantic type: either a cut or a fold. These are selected from a set of predefined types, and you cannot add new ones. In fact, when the user wants to connect a line between two points, he should select the type immediately: whether it’s a fold, a cut, or some other type of line. They should not select a visual style, but a meaning instead.

The user can select a style set in the options, which gives folds and cuts a specific color and thickness, depending on the selected style. This is up to user preference.

To allow the user some more visual configuration, you can allow them to add custom style types as a child of a semantic type. In this example, the user chose one of his fold lines to have the “important fold” look. Here “important fold” is part of a user style, and it is added as a type of fold. Of course, not everyone will have a style with an “important fold” definition. But that’s not very important, because you have a fallback: if “important fold” is not available, you just draw the line with the style for “fold”, as defined by the currently selected style set.

If you really want, you can choose to also embed the style set used into the pattern. But it should be up to the user to decide whether they want to load the style set that comes with the pattern, or just use the style set that they have configured on their local computer.

This is also important if for example someone has a visual impairment. If for example, I would have daltorism, I would not use the colors green and red to differentiate between fold and cut lines. So I might define my own style set, with good line styles that I can clearly differentiate. Now if I download someone else’s pattern, and that someone was particularly fond of red and green, I would have a problem… Unless I could just choose to keep using my own style set. Because the pattern file clearly says what is a cut and what is a fold line, I will have no problem understanding it, and rendering it the way I want.

Color and style maybe, but width 100% no. This is not Inkscape. Such things (width) should be more strict.

I would not go to great lengths at trying to prevent users from doing something. If the users want to shoot themselves in the foot, then let them. Don’t underestimate them, they will see what the impact is of their style changes and eventually come up with styles that work well.

[Jonas_Hauquier]

To make that a little more concrete, I propose the following change in the gui:

So that a user chooses what the meaning of the line is, instead of choosing the line style.

Then there is a Window > Styles menu where the user can select their style set (in this case Default) and modify it.

[Jonas_Hauquier]

Let’s take a real example:

This is an example pattern file saved by Valentina: <?xml version="1.0" encoding="UTF-8"?> <pattern> <!--Pattern created with Valentina (http://www.valentina-project.org/).--> <version>0.2.4</version> <unit>cm</unit> <author/> <description/> <notes/> <measurements/> <increments/> <draw name="Pattern piece 1"> <calculation> <point type="single" x="0.79375" y="1.05833" id="1" name="A" mx="0.132292" my="0.264583"/> <point type="endLine" typeLine="hair" id="2" name="A1" basePoint="1" mx="0.132292" lineColor="black" my="0.264583" angle="168.406" length="5"/> <point type="endLine" typeLine="dashLine" id="3" name="A2" basePoint="1" mx="0.132292" lineColor="black" my="0.264583" angle="235.984" length="2"/> </calculation> <modeling/> <details/> </draw> </pattern>

The only way to differentiate between lines is their hard-coded styles: typeLine=“dashLine” and lineColor=“black”

From a machine readability or semantic point of view, this is a disaster. A program can’t open this file and know what these lines mean. As a matter of fact, a human cannot open this file and know what the lines mean, because everyone has their own conventions.

What I propose, is to make the file look like this: <?xml version="1.0" encoding="UTF-8"?> <pattern> <!--Pattern created with Valentina (http://www.valentina-project.org/).--> <version>0.2.4</version> <unit>cm</unit> <author/> <description/> <notes/> <style name="my style"> <semantic name="cut" color="black", typeLine="hair"/> <semantic name="fold" color="black", typeLine="dashLine"> <substyle name="important fold" color="red' typeLine="dashLine"/> </semantic> </style> <measurements/> <increments/> <draw name="Pattern piece 1"> <calculation> <point type="single" x="0.79375" y="1.05833" id="1" name="A" mx="0.132292" my="0.264583"/> <point type="endLine" semantic="cut" id="2" name="A1" basePoint="1" mx="0.132292" my="0.264583" angle="168.406" length="5"/> <point type="endLine" semantic="fold" substyle="important fold" id="3" name="A2" basePoint="1" mx="0.132292" my="0.264583" angle="235.984" length="2"/> </calculation> <modeling/> <details/> </draw> </pattern>

As you can see, lines now do have a meaning: I know that the first line is a cut line and the second is a fold line. The pattern file also comes with a style definition, but this is optional. I can choose to render the file with my own style settings instead. Substyle is optional, and perhaps does not even have to be implemented.

The same format for styles can be used for saving styles to a separate file: <?xml version="1.0" encoding="UTF-8"?> <!--Style file for Valentina (http://www.valentina-project.org/).--> <style name="my style"> <semantic name="cut" color="black", typeLine="hair"/> <semantic name="fold" color="black", typeLine="dashLine"> <substyle name="important fold" color="red' typeLine="dashLine"/> <substyle name="important fold" color="black' typeLine="dashLine"/> </semantic> </style>

The reason why I pressed on this issue being very high priority, is that until you implement this, files saved with Valentina have no meaning. One does not know what a fold is and what a cut is, and has to rely completely on conventions (that we know people will break). And other software cannot read the files.

Once this is implemented, all the libraries of patterns that currently exist for Valentina will have to be converted to this new format. If there are already large quantities of pattern files, such a task can be very painful and time consuming.

That is why I urge the Valentina developers to make this change as soon as possible (if possible, in the next release), to minimize the damage of legacy file formats. If this were my project, I’d give this one top priority, but of course I’m not

Edit: damn it, for some reason I lose the indentation on the XML examples…

Edit2: This also solves your problem of sharing patterns with a team. Well defined types are used for your lines, standardized ones that everyone in the tailoring business understands (cut, fold, … you guys probably know better which ones are needed). Everyone can share their patterns with each other without imposing a certain visual style onto each other. Everyone can just choose their own conventions, configure them once, and then see them for all patterns, even for those they received from someone else. Or they can choose to view the pattern with the same visual style as the user that originally created them. The choice is theirs. By adding sub-types to the style, users still have the freedom to go beyond the standardized set of types that are fixed. They do need to choose one standard type to attach their sub-type to, however (that will help with portability and help a computer make sense of the meaning of each line). Most likely, this is all the customization your users will ever need (you can ask them, of course)

[dismine]

@Jonas_Hauquier, you did great work. I like your proposal very mach. Very good and very clear in describing your thoughts.

Yes, you don’t need to look far: LibreOffice

Yes, you are right this is very close to what we need. Good starting point.

Yes, I would save styles separately from patterns. A pattern can be loaded in every configuration of Valentina. If you don’t have the same style selected, the file will simply render differently on your screen.

Another configuration file? I have enough pain with measurements file. Your proposal is good in this part only if we really should not care about different rendering. I don’t have answer on this question yet.

This is actually a feature, not a bug. I can imagine myself getting used to one color coding for reading patterns, I’m not interested in the color coding someone else is using, I’m just interested in understanding the pattern.

You are people too soft. Here is an example for you.

Valentina already have almost all we need to repeat this. And here we are talking about colors. People became too lazy to think this days. In past you had one color (black), several line styles, one or two widths.

Style in LibreOffice and style here has different meaning. LibreOffice has a lot more variations of options. And this is logical to gather them into groups. Also visual part not so important for them. How many styles you can recognize just by looking at them? But for Valentina a story is different. A patternmaker should read pattern only by looking on it.

The same goes for a piece of software or a machine that tries to open the Valentina file.

I heard about this idea previously. But. Before do something i should know which kind of information a machine need. Right now i don’t know anything about this abstract machine. So, predicting what it really will need is pointless.

I think a legend is just a patch-up hiding the real problem.

Many solutions fix this issue. Some of them are complex, some of them are small and easy. And some of them are wrong.

If you do consider some kind of legend, ask yourself this question: will another piece of software easily be able to interpret the legend, or is it a visual queue for humans only?

I am speaking about human only issue. Where did you find anything about “another piece of software”?

I would not go to great lengths at trying to prevent users from doing something. If the users want to shoot themselves in the foot, then let them. Don’t underestimate them, they will see what the impact is of their style changes and eventually come up with styles that work well.

This is pattern making application, not a sandbox for children. A pattern is very important part of documentation itself. Our goal is to lead people through process of creating patterns. And trying to make it less painless as possible. I should see a real engineering purpose for editing width. Not just let them.

From a machine readability or semantic point of view, this is a disaster.A program can’t open this file and know what these lines mean. As a matter of fact, a human cannot open this file and know what the lines mean, because everyone has their own conventions.

You see disaster where i don’t.

The reason why I pressed on this issue being very high priority, is that until you implement this, files saved with Valentina have no meaning. One does not know what a fold is and what a cut is, and has to rely completely on conventions (that we know people will break). And other software cannot read the files.

Once this is implemented, all the libraries of patterns that currently exist for Valentina will have to be converted to this new format. If there are already large quantities of pattern files, such a task can be very painful and time consuming.

That is why I urge the Valentina developers to make this change as soon as possible (if possible, in the next release), to minimize the damage of legacy file formats.

Look, i see this issue differently. This is far from disaster as you said.

• A user just complain about possibility to remember all combinations he uses.
• And really, such a list can speed up working speed and free people memory.
• No one said about machine reading or human reading a pattern file itself.
• Such a list will never help you to read pattern without clicking on a line if you don’t know a legend.
• Current implementation has not much style options and this mean combinations of them, to say it is super big problem. Skilled user know how to read, newbies always don’t know.
• Yes, such style information is good addition for self documentation. Must have.
• Legacy code is not so big issue for us. We have nice convertor.

I think starting from this days i will repeat this words again and again. There is only one rule here “Let the best code win”. This mean any good proposal is nothing compare to code. A proposal without code is nothing. For example i can develop for this project and can implement ideas i propose. This by default make my ideas better. And i judge all ideas from outside based on my skills and knowledge. Because i am the person who will probably implement your proposal. And if i don’t like it i just don’t like it. Maybe i am stupid, selfish, blind or lazy. No matter. You are helping me, making an advise or proposal. But this is not enough if i don’t like it. So, i will say no as many times as need before i will like the idea or your code that proves that you are right.

So, i apologise if my words wounded you. You must understand i have a lot proposals i don’t like these days. And fighting with them do not make my day better.

[Jonas_Hauquier]

I’m not wounded by your view on this.

My point of view stems mostly from the ideas discussed at our meetup at Libre Graphics.

My main concern is this: we export a .val file with a template from Valentina, and we want to convert it to 3D clothes. For example we create a Blender plugin that will read the file and convert it to 3D and fit it onto an avatar. What information will it need? I think, that in the first place it will have to know what are the outer lines of the pattern, those lines who define the polygons. Then it will need to know the difference between fold lines and cut lines, and know which lines to ignore (eg helper lines). Where can we read that information from the file format? How will we do this?

You’ll probably need additional annotations on your pattern, for example defining which vertices or edges have to be stitched together. But perhaps this is information the user can add in the 3D plugin.

My proposal is just a way of realizing this. Perhaps you have other ideas of how to realize it, or perhaps it’s already possible as it is.

[dismine]

@Jonas_Hauquier, oh, now i see what you are trying to achieve, but your way is wrong as i see it.

My point of view stems mostly from the ideas discussed at our meetup at Libre Graphics.

Yes, i remember.

My main concern is this: we export a .val file with a template from Valentina, and we want to convert it to 3D clothes. For example we create a Blender plugin that will read the file and convert it to 3D and fit it onto an avatar. What information will it need?

I think this approach is bad idea.

• Opening our format mean repeating almost all features we support.
• Format is complex.
• We do not provide any library for reading a pattern.
• The format doesn’t contain raw data. It’s only recipe, a lot calculations Valentina does itself.
• In this thread we are talking about Draw mode, you need data from Detail mode.

I think, that in the first place it will have to know what are the outer lines of the pattern, those lines who define the polygons. Then it will need to know the difference between fold lines and cut lines, and know which lines to ignore (eg helper lines). Where can we read that information from the file format?How will we do this?

This is right question. You cannot just open a file and get this data. Our format more like a script. And you know what this mean. You should run it through interpreter. This is pain in an ass for someone too stupid to try repeat support our format without knowing what he is doing. There is no quick solution in this case because we do not provide any library for working with the format.

Instead better to try ask Valentina return all data you need in format you need. This is the best way for now because:

• A plugin now care only about own format.
• The format now contains only information you need.
• First we will call Valentian each time we need the data from a command line. Easy and cheap solution.
• If all will be fine, probably we will find a way to create stand alone library for parsing the pattern format.

it will have to know what are the outer lines of the pattern, those lines who define the polygons.

Yes, it’s easy to understand what is what even right now.

Then it will need to know the difference between fold lines and cut lines

I don’t understand why do you need this.

and know which lines to ignore (eg helper lines).

For example in export format you will not get such lines, so no need to ignore them.

You’ll probably need additional annotations on your pattern, for example defining which vertices or edges have to be stitched together. But perhaps this is information the user can add in the 3D plugin.

Yes, this is interesting part of the task. But each tool should do own task. And for me pointing vertices a user want stitch together is task for a plugin. But i need more information about implementation. Maybe i am wrong in this case.

My proposal is just a way of realizing this. Perhaps you have other ideas of how to realize it, or perhaps it’s already possible as it is.

For example we had tried export to .obj pieces. This is very good start. But idea about special export format will have more space for moving. I think trying exclude Valentina from pipeline is far from optimal.