QCAD Bugtracker

Something with hatching changed between 3.10 and 3.12; Changelog for 3.11.2 states: “Add support for hatch patterns defined per entity”. That may be?

Attached drawing from an older version; open in current and see a black box where there should be earth. Change scaling of hatch from 10 to 254 and it will be exactly the same it was when saving the file.

Curiously, that is like swapping inches and mm? Looking into prefs, there is a new drop down: “Messsytem für Linien und Schraffuren” and it read “imperial”; making it metric and bingo, my drawing looks as intended!

This is bad, because each drawing has to be changed! I changed the application default drawing setting to metric and the existing drawing still had imperial set…

Probably a heuristic was on order? If the drawing does not specify the new setting, and the drawing units is metric, use metric?

Reading  FS#441  I fired up the Library Browser, which works fine here, RC2 from tgz on Ubuntu 10.04, BTW.

The freedxf.com drawings “horseman” and two “women” claim to be “Creative Commons Attribution-NonCommercial-ShareAlike 3.0”. In my opinion, the “NonCommercial” clause does prohibit distribution in QCAD3, which is a commercial package. For a discussion see http://wiki.creativecommons.org/Defining_Noncommercial

- Draw a rectangle, say 100 x 100 (I use mm unit, but does it matter?)
1
- Turn on print preview
- Turn off print preview
- OK
2
- Turn on print preview
- Set scale 1/10
- Lines are thicker now, this is good
- Turn off print previw
- Lines stay thick in model view, should that be so?
3
- Set layer 0 to use dash as line-style
- Turn on print preview
- Looks OK
- Set scale 1/10
- Dashes hardly visible, looks almost like a continuous line

In the end of 2,3 a way to reset line width display in model view is to cancel scaling in print preview, ie. turn on print preview, set scale 1:1. I suppose this is a regression since TP1: model view always is unscaled.

The line-width scaling is quite accurate now: Draw two lines 10 mm apart. Set line-width 0.5mm. Set scale 1:20 and the lines exactly touch.

Since the launcher batch no longer requests “-style plastique” QT wants to apply the native style of the desktop environment. This fails on a headless system (or where the current user has no graphical shell to connect to) with the message “Gtk-WARNING **: cannot open display: “. Fortunately, QT provides a workaround in addtion to the new “platform=offscreen” flag.

In the tools that set -no-gui, beforehand export these variables into the environment

export QT_STYLE_OVERRIDE=""
export QT_QPA_PLATFORM=offscreen
export DISPLAY=""

PS: QT-offscreen will not find fonts; unfortunately the workaround only allows for a single directory to search them (I need helvetica):

export QT_QPA_FONTDIR="/usr/local/share/fonts/type1"

Maybe that should get reported upstream, so that like LD_LIBRARY_PATH several directories could be specified.

The startup script still forces a QT-style; Getting bored of that one, qcad runs fine with the system default style - probably that was a qt4 thing, that can be removed, so it blends better with the DE?

18c18 /opt/qcad/qcad
< LD_LIBRARY_PATH=”$DIR” “$binary” -style plastique “$@” —

LD_LIBRARY_PATH=”$DIR” “$binary” “$@”

I only noticed today (perhaps they were available earlier?) that there are 64 bit binaries for windows; I suppose these are true 64 bit.

Yet, the installer prompts me to put them into “Programs (x86)”, where all the 32bit software lives, I guess - this seems to be a pure convention though, the application runs just fine.

Maybe the reason is, that the 32bit version was installed before; Maybe it should change? Maybe it should stay, so that there are not two?

In the head of the new task form there is a “search for existing…” link to ribbonsoft.com even though I am browsing flyspray on qcad.org; maybe this can be made a relative link?

QFileDialog should use the DontUseCustomDirectoryIcons flag; not much may be lost, performance should increase orders of magnitude for most – https://codereview.qt-project.org/#/c/54983/

Dear Andrew, this might seem an obsolete feature, though I recently tried to look it up, the man-page ;) So attached a quick shot; please use if you like and do not frown the additional maintenance. (quick test: man -l /tmp/qcad.1)

Starting with 3.7.7 I noticed, that some parts in drawings are missing: affected are some circles and (some) closed splines. These were created with earlier releases of qcad3.

Attached a file that has two circles, only one of them showing at first (drawn in 3.8.0); set line-display “screen” (NL command) to see the other (drawn earlier). From the dxf serialization (dxflib or teigha does not matter) I do not see where that should stem from or how to fix this.

At zero degrees there is a little dot though, and also, only certain dashed line-types “hide” the (outer only) circle.

Filed under Ubuntu, not tested on windows etc.

A regression? In my script I draw stacked dims (depth d):

    var c = RVector.getAverage(a, b); // Zentrum der Messung
    var dim = new RDimRotatedData();
    dim.setExtensionPoint1(a);
    dim.setExtensionPoint2(b);
    c.x = a.x + d * 50 + ( d > 0 ? 50 : -50 );
    dim.setDefinitionPoint(c);
    dim.setRotation(Math.PI / 2);

Curiosly, this would work in 3.7.5 but fail in 3.7.7: the DefinitionPoint would be ignored then, but only in vertical ones, not in horizontal ones!

More curiously still: The DIM gets drawn right as soon as I move the setRotation call before the setDefinitionPoint call!

PS: the debugger proved very helpful again :)

I have aliased qcad to run it from terminal. There is a small glitch when opening a file from a different location using relative path names:

$ alias qcad
alias qcad='/opt/qcad-3.6.0-pro-linux-x86_64/qcad'

$ cd /a
$ qcad some.dwg &
$ cd /b
$ qcad other.dwg

Import Error is shown:
> Can't open file
> /a/other.dwg.
> File is empty.

$ qcad /b/other.dwg # absolute path works

$ readlink /proc/pid-of-qcad/cwd
/opt/qcad-3.6.0-pro-linux-x86_64

Qcad somewhere stores the path, from where it is first launched. The next “launch” will not use the next location but refer to the first one when constructing the full path name of the file name in the argument.

Maybe that can be easily improved (the message is wrong too).

When I export a bitmap from qcad, windows picture preview will not show it, instead print the message: “the file is in use by another application”. Maybe the exporter does not close the file?

A window with a drawing that has unsafed changes gets an asterisk appended to its name in the tab title. When there too many tabs the title gets shortened and the star cannot be seen then.

It was nice, when the star remained visible, after or in front of the ellipses.

Also it was nice, when the “windows” menu would mark files with changes in the same way.

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.

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());

With the 3.0.3 point release (latest available for Linux systems), SVG PG exporter fails to export splines:

Uncaught exception at /opt/qcad-3.0.3-prof-linux-x86/scripts/ImportExport/SvgExporter/SvgExporterPG.js:72: TypeError: Result of expression ‘splineSeg.getDegree’ [undefined] is not a function.
72 var degree = splineSeg.getDegree();

The objects returned from getBezierSegments() do not provide the methods of RSpline.

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;

Whe qcad runs a script from the autostart command line argument, then, if this script ends with an error, the qcad main function should not return 0, but something different, because the return value of 0 is conventionally used to indicate successful operation.

I enter this as a bug, rather than a feature request, because this convention is so entrained (at least in *NIX land), that it breaks fundamental expecations on application behaviour.

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.

Put the asterisk in tab title of modified files in front of the name, so it can be seen, when there are so many tabs, that the names will be truncated.

Multiline text is in the wrong place. Please see patch below:

— SvgExporterPG.js~ 2011-11-04 22:08:57.000000000 +0100
+++ SvgExporterPG.js 2011-12-07 13:01:43.811533803 +0100
@@ -248,7 +248,8 @@

   this.writeStartElement("flowRoot"); // <flowRoot>
   this.writeFontAttributes();
   var bb = this.text.getBoundingBox();

- var pos = this.text.getPosition();
+ var pos = this.text.getPosition(); always (0,0) ?
+ var pos = bb.getCenter(); // still not right, but closer

   var x = this.convert(pos.x);
   var y = this.convert(pos.y);
   var a = 360 - RMath.rad2deg(this.text.getAngle());

RC1 is lazy in saving appearance to config. I noticed, because it always started with default window size. Maximizing was not carried over, also the panels were consistently reset.

Only when eg. dragging the handle to change cad-toolbar width not from preferences it would write an “appearance” section to the config file.

The appearance section should be written rather sooner than later.

In RC1 text in PG SVG will be in the wrong location. The position passed from native code to the SvgExporterPG.prototype.exportEntity is wrong:

Instead of the actual place of the text it gets the position of the surrounding block entity, or, for text that is not in a block, “0,0,0”.

Dimension labels are not affected by this. Also HAlign and VAlign are not passed correctly for text in the model-view block.

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();

The capability of running headless, ie. without GUI, is a very welcome addition to QCAD. I suggest one more improvement:

When an exception occurs in a script (running from autostart) and no-gui was opted for on the command line, QCAD should not try to bring up the debugger ever (regardless of any preferences), but print the message of the exception and possibly a backtrace instead.

Otherwise all errors will produce the same message…

The labels of dimensions in PG exporter are moved half text-height. Thats a bit much, and actually, no such movement looks more true to the display of same in QCAD itself.

--- SvgExporterPG.js.orig	2011-10-15 18:57:29.994666881 +0200
+++ SvgExporterPG.js	2011-10-15 18:57:39.284666834 +0200
@@ -434,7 +434,7 @@
         //debugger;
         var angle = this.text.getAngle();
         //this.text.setAngle(entity.getAngle());
-        var offset = RVector.createPolar(this.text.getHeight()/2, angle + Math.PI/2);
+        var offset = RVector.createPolar(0, angle + Math.PI/2);
         this.text.move(offset);
         this.textColor = entity.getColor();
         this.exportText();

Starting qcad Beta 3 with command line argument -always-load-scripts will bring up debugger:

Uncaught exception at /opt/qcad-3.0.0-beta3-prof-linux/scripts/library.js:2: RangeError: Maximum call stack size exceeded.
2 include(”sprintf.js”);

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.

A polyline or polygon created from segments always ends up in layer 0, shouldn’t it stay in the same layer as the segments have been?

Chat from  FS#194  singled out, so that can be closed.

Dash patterns in BETA2 are very much out of proportion. BETA2 always PG exports 1:1 and only scales strokes so that in the final rendering they match what a technical drawing would show. As dash patterns depend on stroke, both current stroke and final scale have to be brought in accord.

The patch below also restores the alignment of dashes, so that dashed lines do not end in a gap, at least in most occasions.

--- SvgExporterPG-orig.js	2011-09-15 23:11:40.000000000 +0200
+++ SvgExporterPG.js	2011-10-07 13:28:04.085376719 +0200
@@ -384,32 +384,29 @@
         continuous = true;
     }
     if (!continuous) {
-        //p.scale(this.getPatternFactor());
-        p.scale(1/this.scale);
+        // dash and gap lengths are to be proportional to line weight
+        // beware: line weight unit is 100 times millimeters, convert to current unit
+        // beware: the viewer scales lengths differently from weight
+        p.scale(RUnit.convert(this.weight / 100.0, RS.Millimeter, this.svgUnit) / this.scale);
         var num = p.getNumDashes();
-        var str = "";
+        var str = [];
         for ( var i = 0; i < num; ++i) {
             var len = Math.abs(p.getDashLengthAt(i));
-            // see FS#192:
-            //len = this.convert(len);
-            str += "" + len;
-            if (i < num - 1) {
-                str += ",";
-            }
-        }
-        additionalStyles += "stroke-dasharray:" + str;
-        
-        // does more harm than good
-//        if (isShape(this.shape)) {
-//            var length = this.shape.getLength();
-//            if (isNaN(this.offset)) {
-//                this.offset = this.getPatternOffset(length, p);
-//            } else {
-//                var num = Math.ceil(this.offset / p.getPatternLength());
-        //                this.offset -= num * p.getPatternLength();
-        //            }
-        //            additionalStyles += ";stroke-dashoffset:" + this.offset;
-        //        }
+            str.push(len);
+        }
+        additionalStyles += "stroke-dasharray:" + str.join(",");
+
+        // center dash-array
+        if (isShape(this.shape) && isFinite(this.shape.getLength())) {
+            var length = this.shape.getLength();
+            if (isNaN(this.offset)) {
+                this.offset = -this.getPatternOffset(length, p);
+            } else {
+                var num = Math.ceil(this.offset / p.getPatternLength());
+                this.offset -= num * p.getPatternLength();
+            }
+            additionalStyles += ";stroke-dashoffset:" + this.offset;
+        }
     }

Sometimes the text of a dimension (that is in a block - just a suspicion of mine) will not get rotated. I do not know why this.text.getAngle() sometimes returns a wrong value, but there is a simple workaround: always rotate the text with the dimension:

--- SvgExporterPG-orig.js	2011-09-15 23:11:40.000000000 +0200
+++ SvgExporterPG.js	2011-10-07 13:07:03.715374911 +0200

@@ -428,9 +427,7 @@
         // dimension entity: export text:
         this.writeEntityComment(entity);
         this.text = entity.getTextData();
-//        var angle = this.text.getAngle();
-//        var offset = RVector.createPolar(this.text.getHeight()/2, angle + Math.PI/2);
-//        this.text.move(offset);
+        this.text.setAngle(entity.getAngle());
         this.textColor = entity.getColor();
         this.exportText();
         this.text = undefined;

It was nice to specify the default Format for saving files. 2010 is too young for distribution to unknown users, better use 2004 or so...

One can draw in print preview. If one does, QCAD starts acting confused, the model view gets restored with a fullbright white background.

Maybe best is to just disable all drawing and measuring in print preview?

When many tabs are open, the name of contained drawing is not fully shown. One way that some mdi applications do, is to append the name of the active tab to the top window title, which is also useful in other ways. At least a tool tip with the full name of the file on the tab top was nice.

Select → Contour (T, C) and click into empty space, will cause an exception, REntityPointer being a null pointer (0×0) and not false, undefined or something like that.

Snap defaults to auto. Auto snap gets slow in areas where there are many places it can snap to.

DWG files created with QCAD display really fine now in autocad. There are only two minor issues for ACAD users:

1) ACAD complains, that they were not created with a licensed application. One may not be able to work around that one...

2) ACAD complains, that the file does not specify a codepage. For this one, there should be a way around, shouldn’t it?

I am very happy with the compatibility in the new QCAD. Thank you very much for all the efforts that went into it!

Peter

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?

I noticed like this:

in a block pasted from the library, text would be under differently coloured lines, although it should be above them, and this does not look nice.

Drawing order inside of a block should not be changed by a paste operation, not?

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.)

Font styles “bold” and “italic” are not saved to file.

According to http://docs.autodesk.com/ACD/2011/DEU/filesDXF/WS1a9193826455f5ff18cb41610ec0a2e719-7a4d.htm it is saved in dxf as group code 1071 and according to http://www.autodesk.com/techpubs/autocad/dxf/dxf2002.pdf page 20 its type is “Extended data 32-bit signed long”.

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.

In print preview lines are correctly scaled to stay the same width when printed, ie 0.25 or so mm thick. Print preview shows that very good.

But the round line-caps mess up the display, as in small scale the line-caps start to meet and make the line look like a continous one.

Print preview should not only correct line weight but also line patterns, so that the distance between dashes increase by scale.

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>.