Suggestions for the improvement of exportation to SVG.

QCAD Professional QCAD Suggestions and Feedback
1

After making a geometry in QCAD, I have played with SVG exportation options to know what they do because most options do have not any documentation. Once I have understood what these options do, I am able to give some feedback to make some improvements in the exportation process.

Option: Export QCAD SVG layer attributes.
This option may be misunderstood as the user might believe that if not checked, the style of lines defined in the layer will be loosed.
This option will add QCAD declared prefixes that are useless outside QCAD, and this way to add metadata is discouraged by the HTML specification. The way defined by HTML to add metadata was named Microdata by it, but Inkscape does not use this way to add metadata either.
Inkscape does have layers as QCAD, but an exported QCAD drawing with layers will not be understood by Inkscape to have them. Inkscape marks a layer by grouping all entities of the same layer using the g SVG’s element, then it appends Inkscape-specific attributes to the element to mark that the group is a layer.
The concept of the layer in Inkscape has no restrictions to entities in it as in QCAD, which they need to share the same style of line. This restriction needs to be considered to import Inkscape layers to QCAD.
My preferred way to add metadata to SVG is to declare the use of the HTML namespace with a prefix to enable the use of Microdata. In the future, the declaration may not be necessary if the SVG adds this vocabulary to its namespace.

Option: Preserve Geometry.
I don’t understand what is the need for not preserving the geometry. I believe this option should always be checked in the exportation. When I tested leave the option not checked, I found that a polyline of segments was exported to a path with many more nodes than the vertices made by the segments.
Even with the option checked, the polyline is converted to a path of straight lines, despite the existence of an SVG element named polyline. This could make sense because Inkscape does not yet give support to edit polylines and QCAD polylines are different from SVG ones in that the latter can only be formed by straight lines. But it would be nice, an option to target to preserver as much as possible in the exportation to SVG instead of just what it is supported for edition in Inkscape.

This is all my feedback on the current options. I am going to continue with what, I believe, is missing in the conversion.

Depending on the font face you choose, the exportation process will not be able to keep the original font face and the SVG render engine will switch automatically the used font face with its default font face. It would be a good option to check the font faces used in the drawing and ask for a URL of the source file to include them in the style attribute of the document SVGs root element. Today, font manipulation on browsers is much richer than in QCAD, so QCAD can give users better flexibility with text by changing its font render engine with one used by browsers.

The complete drawing is not exported to SVG, only visible layers are exported. This is nice because you may have multiple SVGs files by one original drawing. But visibility is a property supported by SVG and an author may want to export all layers to choose on the SVG file which ones are visible.

2

Point coordinates in SVG differ from the coordinates in QCAD in the sign of the y coordinate. The QCAD’s exportation process, instead of changing the sing of all y coordinates, will group all entities to apply a transformation that changes the sign of the y coordinates. By working like that, all SVG files will have a group of entities that the user have not declared in the source file. I believe, exportation processes should export as much information as possible from the source file and should avoid adding in the destination file any information that it is not included in the source file. Inkscape will not allow you to group the drawing entities into different layers until the group made in the exportation is undone.

3

Thanks for your thoughts. Please post unrelated ideas each to a separate topic in the future to keep separate discussions separate and avoid confusion. Also, this is in the wrong place as it seems unrelated to the QCAD part libraries. I will move the topic accordingly.

We have customers who are using this attribute for further processing.
I don’t understand the connection between HTML and SVG, please elaborate or point to the specification, provide an example, etc.

Not preserving the geometry has the advantage that the SVG file is rendered almost exactly identically to the CAD drawing in QCAD. Since SVG is first and foremost a presentation format, this is the default setting. Think about SVGs of technical drawings for a publication or book. Indeed, we use this setting for our own QCAD book.

Feel free to post a feature request at:

Again, a feature request would be the right place for this.

4

This is a design choice, indeed to the effect to keep coordinates in the output identical to the ones in the input, making life a lot easier for those who need to further process the SVG file in one way or another.

5

Sorry about the misplacement, as all my feedback was about the exportation process to SVG, seen SVG on the title made me fool myself.
For me, as all suggestions are related to the exportation process, all the ideas were related. I was not requesting any feature, I am fine with the software as it is now.

Here I was doing two suggestions:
First is about not adding an attribute for all entities of the draw (lines,paths) with the layer name. Example:
<line x1=“0” y1=“0” x2=“140” y2=“0” qs:layer=“layer 1”/>
<line x1=“0” y1=“0” x2=“153” y2=“50” qs:layer=“layer 1”/>
Instead, group entities of the same layer and add the layer name attribute to the group. Example:
<g transform=“scale(1,-1)” qs:layer=“layer 1”/>



With the current notation, not QCAD aware programs will not know any relation between the two lines, For example, Inkscape will not select both lines together and the user needs to select both and ask the program to group them.
Of course, if QCAD clients have a good reason to not change this notation, leave it as it is.
If the drawing would be made with Inscape, the code would be:
<svg:g
inkscape:groupmode=“layer”
id=“layer2”
inkscape:label=“Dibujo”
style=“display:none”
transform=“translate(0,-137)”
sodipodi:insensitive=“true”>



So, by adding Inscape attributes to XML g element, the layers made in QCAD will be visible in Inscape.

The second suggestion is about the way to add information to the file when SVG has not specified a way to do it. For example, in SVG there is not such concept as layers and that is why software needs to define a way to express the information carried on them by adding new vocabulary to the document.

XML, as an extensible markup language, allows you to add arbitrary new vocabulary by using a prefix that references a defined vocabulary. The set of all words in the vocabulary is called a namespace, and we refer to this namespace unambiguously by using a unique URL.

However, HTML specification does no longer specifies a schema for conformance of HTML documents using XML syntax. XML syntax is seen by the specification as an optional legacy characteristic that had to be given support:

Since SVG specification is a member of the HTML family, and it is meant to be possible to embed SVG documents inside HTML documents. That is why there is a conforming document fragment that does not need to conform with XML syntax specification:

The specification does not specify how an SVG document fragment should be serialized because it allows to host those fragments on any document. The specification of the document that host SVG document fragment is the one in charge of specify de serialization to be able to parse the fragment to form de DOM.
To make it harder to understand and fool people, the specification does specify the serialization when the whole document is a stand-alone SVG document. Thus, phasers are not allowed to specify a serialization, and we are forced to honor two sets of possibly no compatible restrictions in our documents. On stand-alone SVG documents, we need to honor XML syntax specifications.
To have a grasp of how difficult it is to honor both sets of restrictions at the same time, I recommend a reading of:

That is why most SVG stand-alone documents cannot be embedded as they are in an HTML document, and a manual refactor is needed. Of course, an author could choose the legacy XML syntax for HTML, but this would drive him to deal with many limitations that only apply to XML syntax.
One of the most missing features of HTML syntax is the ability to declare custom namespaces by using prefixes, and this forces users to refactor SVG markup to honor HTML syntax restrictions when they embed an SVG.
The HTML specification asks to ignore silently many of the violations of its rules, and this keeps authors making the same mistakes caused by their lack of understanding of the specification.
The HTML specification has a namespace that includes namespaces of SVG and MathML. This allows users using XML syntax to only declare the HTML namespace and make it the default of the document. But this cannot be used in stand-alone SVGs because HTML-unaware software will be fooled.
My suggestion for stand-alone SVGs is to declare the SVG’s namespace as the default of the document and add the HTML namespace as an auxiliary vocabulary. This way, we are allowed to add the HTML’s Microdata feature to these documents and use it to add all the information needed in the document not covered by the SVG’s vocabulary.
By following my suggestion, it is only needed to delete the HTML prefix from attribute names and element names of the stand-alone SVG to be able to embed the image in the HTML document. No violation of the HTML syntax rules will occur because of a namespace’s prefix occurrence.

I still don’t understand why QCAD software and SVG software draw the same geometry differently. I have found that just a polyline of line segments has different SVG markups depending on this option. For example, a rectangle is a polyline of segments; why, if we draw a rectangle with the same side sizes using QCAD and Inkscape software, the printer output or the screen’s image will be different?

I don’t need it, I use Inkscape to insert text in an SVG, and then I edit it as text to add the font references’ URL.

I don’t need it either, it is just a suggestion for people less knowledgeable that would use the output in Inkscape.

6

It is fine for me, I see that clients want to draw SVG as if it were a DWG.

7

Please note that layers in Inkscape are different from layers in CAD. Layers in CAD have no relation or control over drawing order. Entities on the same layer may be rendered with completely different drawing orders. Entities on the same layer can be in different groups (block references). Therefore, using a group for layers would break the drawing order and is also not semantically correct as layers are not groups.

Adding a namespace (as QCAD does) is the standard way of mixing information from different standards to XML files. Quite frankly, I don’t see the connection between HTML and SVG. HTML is a document markup language. SVG is an XML dialect for vector graphics. While SVG can be embedded into HTML using the tag, I wouldn’t see it as part of the HTML family but rather a standalone vector graphics format that exists outside of the realm of HTML (just like PNG exists as a standalone bitmap format outside the HTML context).

If I understand you correctly, you want QCAD to output SVG that can be directly embedded (copy/paste) into HTML. This is a valid use case but is not one covered by the QCAD SVG export. It would need a new SVG export option “create SVG for HTML embedding” or something similar.

I don’t understand this question. Yes, there’s more than one way to export the same geometry to SVG. How is the screen output / printer output different? Maybe you could attach an example DXF with exported SVG and SVG from Inkscape.

8

Dear Andrew,
Thanks for all your answers. We have different opinions on this matter, but I still think that the software you have created is magnificent. Thank you very much for your work.
I hope my suggestions will help others better understand the export result.

About my question, I can’t think of another way to formulate it to make myself understood. I will always have the preserve geometry option checked because when it’s not checked I don’t understand what it’s doing. For me when the option is checked it is when QCAD outputs to SVG file which I am expecting it to do based on what I have drawn in QCAD.

Knowing what the software does when the option is unchecked would allow me to choose not to check the option when I saw fit. However, if you don’t understand the question, it’s okay, especially if I’m the only one who has it.