QCAD Bugtracker

Text scaling in PG SVG exporter is missing just two small additions: These attributes are not taken care of by now:

font-size, dy

Just use the current value times scale: eg 2.5 * 0.1 to have a scale of 1:10. Looks good here.

Points are not scaled when PG exported to SVG:

Points as crosses are created eg. like this:

d=m 2.5,3 1,0 M 3,2.5 l 0,1

and in SVG look fine like that (scale 1/10):

d=m 2.95,3 0.1,0 M 3,2.95 3,3.05

stroke-width should be left unchanged.

The SVG PG exporter does not scale hatches.

Polylines may consist of lines and arcs. The SVG PG exporter writes them as all straight lines. A better mapping than polyline then was path, as is done with arcs now.

Patch to PG export font styles “bold” and “italic” to SVG. (This only works when a file with the right style is loaded into QCAD, as QCAD will yank such style information upon saving.)

White text gets exported as white text, while it should be exported as black text. Just like it is with lines. Attached patch makes text rendering use the conversion function that is already in the code base.

SVG PG exporter, scaled or unscaled, currently only exports the labels of dimensions. Missing are

ticks, arrows, and lines of the dimension.

It will not be as simple as inkscape does it, wrap it all in a <def>.

Dimension labels in QCAD are (always?) centered on the dimension line, while in exported SVGs the text starts from the center and extends into the writing direction. This can trivially be fixed by adding the attribute “text-anchor:middle” to the respective SVG “text” nodes.

A hatch my have “holes”, if it eg. is made of two forms, an inner form, and and outer form, where the outer form is filled while the inner form appears like a window inside of the fill, that lets the background be seen.

QCAD exports such hatches as two SVG paths in one single entity. But the “hole” is lost in the process. I know of two workarounds, that preserve the original intention of the QCAD drawing, both get the same result most of the time, the second one looking more robust and easier to implement:

# draw the outer form clockwise, draw the inner form counterclockwise
# set the “fill-rule:evenodd” attribute on the fill definition of the entity

Drawing a star like in the SVG spec in QCAD actually produces the same picture – so that should be the way to go.

http://www.w3.org/TR/SVG/painting.html#FillRuleProperty

importing a svg generated by inkscape from a downloaded eps results in all contained arcs drawn in wrong direction

Add support for scale transforms in SVG import.

Original report:

When importing an SVG created with Inkscape, one of the elements (rectangle) is shifted (mirrored?) to the left.
The example (back.svg) is appended. If you open it with Inkscape, you see the rectangle should be above the “USB” label.

My impression is that the sign of the X coordinate is swapped for some reason. At least if I mirror it
using two points on the Y axis, it seems to appear where it should be.

Apart from this, also the dimensions are wrong after import. In the original SVG, the outer shape is 144.3mm wide.
This is also visible in the header of the SVG:

 width="144.300mm"
 height="53.800mm"

However, after importing to QCad, the width is measured as 40.7247. This is a puzzling factor of 3.5433 which doesn’t look
like metric/imperial conversion issue but like a complete misinterpretation of the sizes/units used in the SVG.

Add support for importing units other than defaults (pixels) based on unit given in svg:width / svg:height attributes.

QCAD seems either to mishandle or ignore svg group transformations altogether.

Importing the attached file into QCAD renders the largest polygon (polygon18) to be rotated and misplaced. This is shown in actual.png. The expected result (original Inkscape renedering) is shown in expected.png.

Looking at the code of the original drawing it can be observed there is a transformation applied to the group which polygon18 is in:

 <g
   style="stroke-width:0.35433099;stroke-miterlimit:4;stroke-dasharray:none"
   id="g20"
   transform="rotate(-90,316.66796,298.95141)" >
   <path
      inkscape:connector-curvature="0"
      id="polygon18"
      d="..." />

Removing the ‘transform’ attribute produces virtually identical (erroneous) rendering in Inkscape as well.

The attached file should result in two overlapping circles, it does not, it results in a single ellipse.

The “<circle ... />” directive seems just be ignored in this case, but in other instances I have seen it result in ellipses.

And the “<ellipse ... />” directive should of course result in a circle, when rx and ry are the same.

(I’m running on FreeBSD, but that was not an option in the selection for Operating System)

When importing a SVG file in version 3.7.5, it qcad turns polylines into polygons.

I’m attaching a trivial .SVG file showing this, it should *not* render as a rectangle,
but as a “rectangular upper case C”.

And many thanks for making good quality CAD software available to the FOSS community.

I noticed, that paths are not fully imported into QCAD. I rewrote case “m” of “SvgImporter” like below, that way also straight line segments are drawn correctly. Case “M” should be similar:

      case 'm':
          x = ox = coords[0];
          y = oy = coords[1];
          x0 = x;
          y0 = y;
          for (k=2; k<coords.length; k+=2) {
              x += coords[k+0];
              y += coords[k+1];
              this.importLine(ox, oy, x, y);
              ox = x;
              oy = y;
          }
          break;

Complete SvgImporter.js and SvgImport.js

1. Implement SvgImporter.prototype.importFile to import the SVG file with the given fileName. Reading only all path data without any attributes or transformations is fine as a first step. SvgImporter.prototype.importFile() currently imports one hard coded path data as proof of concept.
2. Implement SvgImport.prototype.beginEvent() to show a file open dialog that lets the user choose an SVG file to import.
3. Support SVG as file format for part library items through SvgImporter

This should be enough to import any SVG file in library/symbols

Attached sample drawing, that kills QCAD 3.1 beta when exporting to SVG.

The crash happens in line 38 of SvgExporterPG in function SvgExporterPG.prototype.exportPolyline

var pp = new RPainterPath(polyline.toPainterPath());

Somewhere in the 3.1 series the SVG exporter (both precise and PG) started to make lines that are zero (0) width in CAD 0.01 (@scale 1:1) points wide in exported files (0.1 @scale 1:10). I use such lines to constrain exported files to a common size and rather not have them show. In my view, this is a regression, as there is no reason for changing line weight, isnt it? If I wanted the lines to have weight, I’d draw them with a weight.

Hi,

when I export a dxf draw to svg the text objects shows in a bit different place.

QCAD version is 3.21.3.14

In files exported with the (even PG) exporter I sometimes see values like these: 334.99999999999994 or 570.0000000000001 and very often 12 digits of precision.

To safe on file size, I suggest, that QCAD rounds values on SVG export to eg. three places. When viewed in an ordinary web browser, that will result in a precision of 1 inch / 96dpi / 1000 = 0.00026mm, not? Ends should still meet.

When exporting a drawing to SVG, polygons containing arcs (trimmed circles in this case) are converted to straight lines. If the polygon is exploded first, then it exports correctly. Of course, this isn’t useful if closed polygons are required for the program using the SVG file. Solid hatch fills export correctly. See attached DXF and corresponding SVG export.

https://qcad.org/rsforum/viewtopic.php?f=33&t=9731

Quick SVG export of a block reference can lead to unexpected results if the vertical flip option is enabled during the insertion of the block. See above forum thread.

Both SvgExporters ignore the exportPoints setting. Attached patch takes care of that. To be applied from within the “scripts” directory.

Nitpicking in File/SvgExport/SvgExport.js, var properties is meant to be a plain Object instead of an Array, isn’t it?

The SvgExporter opens a “group” for some entities, but never closes that group. The resulting nesting can get quite deep and does not conform to the original. I tentatively patched the script as below:

--- SvgExporter.js-orig	2011-05-23 10:55:17.239998578 +0200
+++ SvgExporter.js	2011-05-23 10:55:17.239998578 +0200
@@ -226,6 +226,11 @@
 //        RFileExporterAdapter.prototype.exportEntity.call(this, this.realEntity
 //                .data(), false);
 //    }
+    
+    // dimensions and block references are grouped, close the group tag here
+    if (isDimension(entity) || isBlockReferenceEntity(entity)) {
+        this.writeEndElement();
+    }
 };
 
 SvgExporter.prototype.endEntity = function() {

There might be a better way, but that is what I came up with on short notice.

Quick SVG Export suggests file name “Untitled 1 [*].svg”

Remove [*] (comes from window title).

If I understand correctly, SVG export uses svg groups to keep QCAD block entities. This in itself is very useful. There is no way to correctly keep layer information, as QCAD blocks can contain elements on different layers, while SVG only knows about groups. That is a deficiency of SVG.

To save on file size, there was some potential to get rid of ever repeating same attributes on entities, eg: style=”stroke:#000000;stroke-width:0.25;stroke-dasharray:2.16,1.08”

To optimize “By Block” is easy: just set the attribute on the SVG group, and omit on below entities styled “By Block”.

To optimize “By Layer” is a little more involved, but might be solved by using css:
- Create a class by the name of the Layer
- add the class attribute to elements styled “By Layer”

Then only individually styled entities would get a style attribute, and filesize of SVG could be halved in most cases.

This just an idea :) Having written this, I now realize, that QCAD can style weight, pattern, color each extra, so the optimazition could only be applied to entities, where everything is “By Layer” or “By Block”. But that should be the case most of the time.

SvgExporter.js uses PrintPreview to parse the scale string, and therefore depends on the qt GUI part. That should not make maintenance harder to call RMath directly there? Results seem to match from a first look.

--- SvgExporter.js~	2011-10-20 14:11:45.527589416 +0200
+++ SvgExporter.js	2011-10-20 14:12:46.277502814 +0200
@@ -1,6 +1,5 @@
 include("scripts/library.js");
 include("scripts/date.js");
-include("scripts/File/PrintPreview/Print.js");
 
 /**
  * File exporter implementation for the SVG format.
@@ -116,7 +115,7 @@
     this.svgUnitAbbr = ret[1];
 
     // scale
-    this.scale = Print.parseScale(this.scaleStr);
+    this.scale = RMath.parseScale(this.scaleStr);
 
     var bb = this.doc.getBoundingBox();
     var size = bb.getSize();

Points in hatch patterns are exported as empty path elements in the exported SVG.
Therefore, the hatch patterns “DOTS” and “AR-SAND” are not visible in the exported SVG.

• during the start up
• last info from splash screen: LibraryBrowser: Directory: metric

./qcad: line 5:  2321 Segmentation fault      (core dumped)
LD_LIBRARY_PATH=/home/martin/opt/qcad-3.0.0-tp1-prof-linux /home/martin/opt/qcad-3.0.0-tp1-prof-linux/qcad-bin $*

(gdb) bt
#0  0x03180194 in __strncmp_ssse3 () from /lib/libc.so.6
#1  0x08c7741e in __xmlParserInputBufferCreateFilename ()
#2  0x04333e04 in xmlParserInputBufferCreateFilename ()
   from /usr/lib/libxml2.so.2
#3  0x043bc9c0 in xmlNewTextReaderFilename () from /usr/lib/libxml2.so.2
#4  0x041fde98 in ?? () from /usr/lib/libgnomevfs-2.so.0
#5  0x041fe381 in gnome_vfs_mime_get_value () from /usr/lib/libgnomevfs-2.so.0
#6  0x041fbb38 in gnome_vfs_mime_get_icon () from /usr/lib/libgnomevfs-2.so.0
#7  0x040d0ab6 in gnome_icon_lookup () from /usr/lib/libgnomeui-2.so.0
#8  0x040d1037 in gnome_icon_lookup_sync () from /usr/lib/libgnomeui-2.so.0
#9  0x0240ee92 in ?? ()
   from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtGui.so.4
#10 0x026a0658 in QFileIconProvider::icon(QFileInfo const&) const ()
   from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtGui.so.4
#11 0x025cd467 in ?? ()
   from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtGui.so.4
#12 0x025c2f89 in ?? ()
   from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtGui.so.4
#13 0x025c3ba4 in QFileSystemModel::index(QString const&, int) const ()
   from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtGui.so.4
#14 0x025c7289 in QFileSystemModel::sort(int, Qt::SortOrder) ()
   from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtGui.so.4
#15 0x025bc86c in ?? ()
---Type <return> to continue, or q <return> to quit---
   from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtGui.so.4
#16 0x025c6d68 in QFileSystemModel::qt_metacall(QMetaObject::Call, int, void**)
    () from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtGui.so.4
#17 0x08881dc2 in RFileSystemModel::qt_metacall(QMetaObject::Call, int, void**)
    ()
#18 0x02cd3c83 in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtCore.so.4
#19 0x02cdede6 in QMetaCallEvent::placeMetaCall(QObject*) ()
   from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtCore.so.4
#20 0x02ce09a0 in QObject::event(QEvent*) ()
   from /home/martin/opt/qcad-3.0.0-tp1-prof-linux/libQtCore.so.4
#21 0x025c07c3 in QFileSystemModel::event(QEvent*) ()

That would ease this task:
https://www.qcad.org/rsforum/viewtopic.php?f=32&t=8000

Correct surface area included.
CVH

See RDwgEllipseImporter::import

It would be nice if the OS X Pro version could support the standard OS X full screen pattern in the same way as native OS X applications.

With this I mean that applications in full screen will create a temporary new desktop as long as they are in full screen mode.

There is one important ACAD feature that I would really like to see supported in QCAD3 and that is “Layouts”

Looking at the block lists, it seems to me that it can’t be too much extra work to support it, since the model space and different paper spaces are already shown there - and one can edit it.

QCAD draws infinitely easier than ACAD and drawing layouts is a primary feature of ACAD. With this in QCAD I can hardly see why anyone that does 2D work would need ACAD at all.

Support drawing linetype scale factor (LTSCALE)

E.g. if a block reference has its color set to ‘red’ and the block reference has an attribute with color=’ByBlock’, the attribute should be displayed in red.

I very much like the new middle mouse button zoom in/out and congratulate Andrew for implementing it so quickly but there’s an annoying delay that is necessary between successive zoom in/out actions. This is easily understood by comparing it to zooming in/out with the +/- keys. With the keyboard you can repeat zooms as quickly as the keyboard repeat rate allows; with the middle mouse button quick zooms are not possible.

Draw a horizontal dimension. Stretch (S S) it. The label remains in place. It should instead go to the new center. (Unless it was manually positioned perhaps...)

Workaround: Pick one extension and drop it to where it was, label gets centered.

Stretching hatch entities results in broken hatches.
Regression introduced in QCAD 3.1.5, bug still present in 3.2.2.