QCAD Bugtracker

I've tried several times to try to see what the "surveyor's units" option of the Angular Dimensions format in the UI preferences will display as, but all it ever seems to do is cause the angle measurement to become blank. No angles are displayed whenever this mode is selected.

Indeed, I cannot figure out what the setting actually does besides causing angles to never be displayed.

Is there a way to make this setting do something meaningful or is it just broken?

I found an old forum thread from 2016 about this same issue and it sounds like the same things is still happening since then.

I'm not a surveyor so I have no actual practical use for these units that I can yet see, but I just figured I'd add an report to the bug tracker here in case any developers aren't aware that the bug still seems to exist.

Does the setting do anything besides changing the displayed units in the status bar?

In my current QCAD file I’m working on, I have a circular hub with a hole in it which I am also trying to place an alternating sequence of rectangular spokes of a certain relative size around.

I had 4 spokes that I had copied and rotated 45 degrees to create 8 spokes in total around the circle. I tried scaling the the non-cardinal spokes relative to the center of the circular ring, but that causes them to also move towards the center of the ring as they shrink, thereby putting them out of place as they scale.

I therefore had to activate the scale tool once per each object and set an origin (focus) point around the area where each spoke is “attached” to the ring in order to stop each from shifting inward to the circle as it scales.

It occurred to me though that there could be a simple tool or option to do this without that.

Each of my rectangles are polyline objects and thus are coherent continuous objects.

A new scaling tool could be designed such that it is based on simply clicking on each scaling origin on each object (using snapping tools if needed) and then clicking a check button (or enter) when done and then causing the scaling GUI to appear so the user can specify the desired scaling. Each scaling would then be applied to where the polylines were clicked instead of to all the objects as one.

This would be a much faster way to rescale a bunch of objects around individually varying relative scaling origins!

I was having some problems getting some shapes to fill with a solid fill and was frustrated by the awkward numeric coordinate it was giving me for where the error (the disconnected shape points) were, until I fortunately noticed that a tiny pale circle appears around the point where the error is for about just 1 second.

This is a very helpful error indicator circle but is far too easy to miss.

Perhaps making it last longer (or letting the user control that) would be beneficial.

I also wonder if showing multiple such circles (when they exist, as they did in the piece I was working on) at the same time or having that as a UI option would be good.

Anyway, goodnight all!

I don’t actually have any use for this idea currently, but am just posting it here to document it for consideration.

Basically, it occurred to me at least a few more useful conversions between shapes besides the existing ones could be useful.

For example:

• Converting lines into axially aligned rectangles of a specified “radius” or “diameter” (with an option to delete or keep the original line geometry).
• An option for the above (lines –> rectangles) that causes the intersections between the resulting rectangles to be automatically removed, like a kind of “automatic/magic wall creation tool” based on laying down lines instead of rectangles and then converting via this tool.
• Converting circles/ellipses and rectangles back and forth between each other via their bounding volumes. It seems reasonably likely that people will sometimes want to convert circular design elements into rectangular ones and vice versa (e.g. deciding a rectangular column makes more sense than a cylindrical one and vice versa).
• Converting any arbitrary selection into a corresponding bounding circle (not rectangle, which already exists) of sufficient size to enclose all points in the selection.

Basically, QCAD already has tools for converting shapes with operations that are a natural fit for the existing geometry, but has less tools for converting to entirely different geometry, but such uses could actually still be very useful potentially!

It seems likely to be common enough as a use case to merit inclusion, rather than just using scripting.

I don’t have any pressing need for these and I know that I could script them to create them if I really wanted to.

These are relatively minor ideas. I’m just putting this out here as more ideas for making this already wonderful software even better. :)

Reason: Same underlined keys are used for different menus

Select and Snap = S,
Dimension and Info = I,
Modify and Misc = M,

Andrew,

Related topic: https://www.qcad.org/rsforum/viewtopic.php?f=33&t=10649

Already two different users report that Landscape is printed cropped in portrait format, both Win11. The behavior change occurred recently.
Although the second user (rdtsc) reports the same behavior for latest Mabox Linux (Manjaro, Arch.)

Can not replicate that on Win7 32 bit nor on Win10 64 bit, both are no longer or not updated OS. For one, I have no orientation setting displayed in my printer dialog.

It seems not to be related to the QCAD version:
Reported for:
- Win11 QCAD Pro 3.29
- Win11 QCAD-CAM 3.27.8.0

Regards,
CVH

Andrew,

Probably not OS or QCAD version related.

The ellipse arc in the example file is drawn CCW and then the start parameter was set to 180. (All part of a test of newer code for the nearest point on an ellipse)
Its end parameter was originally 44.56263613...

If we reload this file its properties are:
- Not reversed (CCW)
- ratio is 0.42307692...
- Parameters are 180 & 404.56263613...
- The reported length is about 1993.21829743...

To replicate the issue you must draw over this ellipse shape:
- EA ; Direction CCW
- SR for snapping to references.
- Indicate the major, minor, start and end point all by snapping to the original references.

You now have a copy of the provided ellipse shape.
Select it with Alt-Select, it is the one without a length.

Properties are:
- Not reversed (CCW)
- ratio is 0.42307692...
- Parameters are 180 & 44.56263613...
- The reported length is NaN

I can replicate that for some other CCW ellipse arcs ...
... Perhaps given that the start parameter is 180 degrees.
Also suspecting that it can be replicated for CW arcs.

For the record:
A 2D wire Centroid for this shape also fails.
Simply because it tests for the length reported by QCAD.
It doesn’t start to approximate something that is about zero long.

Regards,
CVH

QGroupBox widgets with <property name=”checkable”> are not saved in Qcad3.conf

Andrew,

If a given point p is on the major axis then REllipse::getVectorTo(p) returns one of the major points. In the code this is handled as a special case when the point is in-line (collinear) with the major axis.
This is only correct for points p outside the ellipse.
Or better: For points p outside the area between the focal points.

The correct solutions are:
- if p equals the center ⇒ two vectors to the two minor points.
- if p equals one of the major points ⇒ the major point itself.
- if p is in between the focal points ⇒ two vectors mirrored over the major axis.
- if p is on the unlimited axis but outside the focal points ⇒ the nearest major point.

The problem is now what to return on a duality with full ellipses.
Or for an ellipse arc where two results are valid.

For example:
RCircle::getVectorTo(p) returns an invalid vector when the point is near the center.
Then there are an unlimited number of solutions.

Further discovered that the point related to the returned vector may fail x²/a²+y²/b²=1
Although almost on the ellipse within 2.299e-10 ... f(x,y) may return 9.5310
This example would fail REllipse::contains while the border is considered as inside.

Meanwhile implemented a ‘simple method’ to find the nearest point(s) on an ellipse.
Fast converging in 3 steps, no trigs and very accurate, about 24 lines of code.
f(x,y) returns mostly 1.000 with so far:
- a minimum of 0.9999999999999997
- a maximum of 1.0000000000000007.
In other words, it is only off for the last meaningful decimal digit.

With this all methods that are based on REllipse::getVectorTo(p) can be implemented very reliable with tolerance, border flag, ... and so on.
By default the normal for a point is given with high accuracy and a tangent is that rotated.
...
..
.

Regards,
CVH

See:
http://www.qcad.org/rsforum/posting.php?mode=reply&f=30&t=2677

I am doing a bit of landscaping and using a (big) ortophoto as one of my layers in order to sanity-check on the ground measurements.

The layer contains a point and the image and nothing else.

The image is a 8MB file: “PNG image data, 4200 x 2980, 8-bit/color RGB, non-interlaced” and it is scaled to 210 coordinate units (meter) horizontally in the drawing.

With approx 50% probability the image disappears during Save, as see for instance in this diff of the DXF file:

      @@ -158699,28 +153057,6 @@ AcDbXrecord
        90
       6
         0
      -IMAGEDEF
      -  5
      -A1
      -100
      -AcDbRasterImageDef
      - 90
      -0
      -  1
      -/critter/HTV10/Ortofoto/ortofoto201502f.png
      - 10
      -210.0
      - 20
      -149.0
      - 11
      -1.0
      - 21
      -1.0
      -280
      -1
      -281
      -0
      -  0
       ENDSEC
         0
       EOF

The point in the same layer does not similarly disappear, the bug only seems to affect images.

I have seen this bug from version 3.7.5.0 to git as of yesterday (63e06c778926a803bdfbffdf27b8c24d41511072).

I have not been able to correlate the bug with anything.

Looking closer at the DXF file (attached), there seems to be some residuce of attempts to insert images in protected/invisible layers, so this may be some kind of refcounting issue.

(Any chance of getting FreeBSD into the “Operating System” field ?)

Add parameters to the function DL_Dxf::writeVPort.
This way users will be able to specify the desired viewport.

Is the github the official repository? Are pull requests sent there accepted?

I see the following problem:
When I open a particular DXF file in the Professional Trial version 3.27.9.0 on macOS, “^I” in text fields is expanded to whitespace.
When I open the same DXF file in the Community Edition 3.27.9.0 on NetBSD/x86_64 (installed from pkgsrc), “^I” in text fields is visible as “^I”.

Implement a command line switch to only show a list of given layers for dwg2* command line tools.

dwg2svg supports exporting the layer name (and probably others?) as namespaced XML attributes (`qs:layer`) which works well.
However I’d like to export block attributes as well, as seen on the following screenshot:

https://imgur.com/a/wUd0adE

(...so `ROOM_NAME` would become `qs:ROOM_NAME=”Eötvös terem”` on the respective XML element).

Thanks in advance.

Add support to specify multiple blocks (layouts) to output (one per page).

When trying to plot a dwg or a dxf to pdf where the viewport is orientated to a different angle than north up
the data in the view port is plotted north up.
see attached DWG and pdf for clarification.

We currently have a paper-space using two viewports with different layers from the model-space frozen. Unfortunately in the pdf output the layers which are frozen show up.
dwg2pdf should obey the specific frozen layer for each viewport

It would be nice if QCAD spit some kind of warning message when trying to render a layer with a name that doesn’t exist (and perhaps render nothing), rather than silently rendering an empty image. :D

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