Please make sure that you are using the latest Version of QCAD before posting a bug (menu Help > Check for Updates)

Advanced

Miscellaneous

Search in commentsSearch detailsSearch for all wordsTasks I watchTasks not blocking other tasksTasks blocking other tasksBlocker or nonblocker, selecting both filter options doesn't make sense.Has attachmentHide SubTasks

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?

As of TP1, a script once loaded into the runtime, does reflect changes to the file it was loaded from only after a restart of the whole of QCAD. This adds a considerable time overhead to developing scripts. Therefore I want to suggest a reload mechanism, that works kind of like the one known from a web browser.

As there is no clear separation between users custom scripts and ribbonsoft supplied scripts, checking the modification time for every access to any script might prove a performance hit.

Possibly a user script can be written, to invalidate another certain script and have the runtime reload it from file? I could add that to my menu.

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.

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.

I have a nice minimally reproducible bug on QCAD v3.7.4 on Mac OS X 10.9.5 (Mavericks).QCAD will segfault whenever I take the following steps:

1. Open a new document2. Create a leader object (D,E) in the default ‘0’ layer. Leave its style and color defined by the layer, as per default.3. Create a new layer, with a non-default line style or color. The line weight & layer name do not matter.4. Select the leader object previously create5. Open the property editor and assign the object to the new layer just created.Every time, this will cause QCAD to segfault on my machine. The crash report is attached.

Another minimally reproducible path to the same error is to do the following:1. Open a new document2. Create a leader object (D,E) in the default ‘0’ layer. Give it a custom color and line style that over-ride the layer defaults.3. Create a new layer, with a non-default line style or color. The line weight & layer name do not matter.4. Select the leader object previously created.5. Open the property editor and assign the object to the new layer just created.6. Still in the property editor, switch the leader object’s color back to ‘By Layer’.The same segfault will occur.

It seems that the crash is triggered by the action of changing a leader object’s color (and/or line style) in a manner that requires the object to check the containing layer’s default color and style. You can achieve this by either changing the object’s layer, or switching the color and style from being custom defined to ‘by layer’, as long as the selection requires the line’s appearance to change.

- Draw a rectangle, say 100 x 100 (I use mm unit, but does it matter?)1- Turn on print preview- Turn off print preview- OK2- 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.

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

From reading the specs, this looks perfectly valid. I’d say though, that QCAD is not right to expect any extended data to follow this pattern. The extended entity data, that I want to recreate eg, looks like this:

That is: a group code, followed by some string values. Notice that the (limited) typing facilities mentioned in the spec are not used, but the application relies on its own peculiar parsing. The same group code appears in the head of the document as an APPID:

[…]
0
APPID
2
MY_DATA
70
0
0
[…]

Proposed:

I suggest, that QCAD uses APPIDs to group extended data. Otherwise data loss may occur. In order to not have to maintain a table of known APPIDs, that tells how to parse their extended data, I further suggest that QCAD not expect extended data to follow a “key value” pattern but an “APPID entries” pattern. Here too data would be lost, if there was an odd number of entries in the extended table and QCAD insisted on its own approach.

Within the specs, deep trees could be constructed with the use of the control string (code 1002, { and }), and the propertyEditor would become a nightmare;) So I propose, that QCAD might parse only extended data with its own APPID in key value pairs, and data with other APPIDs as just an ordered list of entries. (In ECMAscript an array will have to be used, as object properties do not keep sequence.)

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 SVGspec in QCAD actually produces the same picture – so that should be the way to go.

In DXF world, as far as I know, colour 7 - white - is magic, in that it shows white in model space on a black background, possibly also black on a light background, and commonly black in paper space irrespectively of background colour. In my opinion, SVG should be considered paper space.

I propose, that white entities get rendered black in SVG files exported from QCAD. What do you think?

QCAD 3 TP1 cannot export to PNG (or any other bitmap format). QCAD 2 lets set width and height in pixels of the file to be created. The drawing is then scaled proportionally to fit that. Leaving the height value empty will crash QCAD 2. QCAD 2 will also pad the image with an unspecified value that gets (both absolutely and relatively) smaller when the size increases…

QCAD 2 interface is simple and should meet most users needs. It would be nice to calculate the missing value, if only width or height is set. Some padding might be necessary only when antialiasing is done on export.

Setting scale and DPI instead would require more thinking on users side…

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.

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.

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.

QCAD offers horizontal and vertical alignment choices for text. This is not carried over to PG exported SVGs. Currently QCAD sets the “dy” attribute on text nodes in a way, such that any text in SVG will look like the QCAD vertical alignment was set to “Top” and the horizontal one to “Left”.

Naively one can just omit the “dy” attribute and in SVG this will look like the QCAD vertical alignment was set to “bottom”. At least for single line texts that should be good.

The horizontal alignments can be recreated in SVG with the “text-anchor” attribute for text nodes. The values “start”, “middle” and “end” correspond to the QCAD “left”, “center” and “right” choices.

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.

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.

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:

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.