New Feature: Separate semantics from visualization

When drawing lines in Valentina, the user can choose a drawing style for that line, but that style is not explicitly linked to a certain semantic meaning. This way, a computer will probably have difficulties discerning a fold line from a cut line from a helper line. This will become an issue in the future when maker applications are being used with Valentina. A fabrics cutter, for example, will need to know what lines to cut, and what lines not to. It's a lot better if the creator of the pattern specifies this when making their pattern instead of having to do this at a later stage.

This is actually very similar to how for example LibreOffice document Writer separates representation from semantics. Style options are separated from the semantics, the user can setup once how they want their document to look, eg font and size of titles, subtitles, quotations, paragraphs, and then when creating the document, simply indicate what type that text is, without directly choosing the layout ad-hoc.

This has the advantage that the representation is not fixed, but can be customized by the user according to their preferences. Eg if I share my pattern with the community, and have a certain methodology for drawing my lines, this might be completely non-standard and not understandable by other users that download my pattern. It could cause confusion, and it means that if I go on the internet to get other people's patterns, I will always have to bother with learning the creator's pattern.

I propose to have a settings panel where the user can choose the drawing style for all types of lines, separate from the line properties, like the style settings of LibreOffice. Then when creating patterns, not allow a style selection, but offer a "line type" selection. It can still show the style visually in the drop down box, but it should mention the line style in text next to it as well.

The file format of Valentina should then not store the draw style of the line, but the semantic meaning of the line instead. So that it is exportable to other tools (and those tools can understand the format, instead of only drawing it).

Optionally you can devise a file type for storing style preferences, perhaps even embed those in the pattern file, allowing users to choose to use their own style preferences, or take those from the pattern.

The important thing is that a machine can understand the pattern.

I think it's important to tackle this early on, to avoid having to port a large collection of templates to the new format later on.

Comments (9)