New Feature: Separate semantics from visualization

Issue #476 new
Jonas Hauquier created an issue

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)

  1. Former user Account Deleted

    as a subset/sidebar to this we need to figure out what the set of line "types" is in detail (maybe limit this to ENGLISH just to narrow the list to a useable set).

    also the export to SVG (or whatever format) could have an option to filter different line types out (if the export is for 3d use some line types are just "noise")

  2. Susan Spencer

    Yes. Valentina can have a picklist of line styles with default definitions.
    The users can re-define the headings/line types so that they can share their patterns and introduce difficulties in reading patterns.
    So we would have a picklist of seam types:
    'Neck curve'
    'Side seam'
    'Shoulder seam'

    Each of these would have a line type associated with it.
    Like 'Heading' settings in LibreOffice
    Line type + thickness + font

    This picklist of 'line style' is available in tool options.

  3. Susan Spencer

    Jonas expressed his interest in this issue, specifically about "the priority of the issue about semantic line meaning vs styling...It's quite important for exporting to other applications, and for integration with for example a 3D clothes pipeline, or textile printers. Even if it's not fully implemented at first (eg you don't see much of it in the GUI), I think it's very important to have this information in the file format. Especially if you're building a large library of designs in this file format, it would be quite tedious to convert a large library at a later time rather than doing it right the first time."

  4. Log in to comment