All Projects

Follow up of  FS#2685 
Tested with 3.23.4 trial on Win 7 but probably not related to OS

With the example file attached to the related forum topic p48576
D2 fails for the lower left ellipse in magenta indicating the segment near (11.72, 2.58).

ShapeAlgorithms.getIntersectingShapes() locates 8 intersecting shapes ...
... That is not the issue here.
ShapeAlgorithms.autoSplit() for the given position returns 3 new segments:
(address may vary)

- [0] REllipse(RShape(address: "0x204229d0"), startPoint: "RVector(11.675918, 2.746654, 0.000000, 1)", endPoint: "RVector(11.977686, 2.428095, 0.000000, 1)", center: "RVector(11.852689, 2.644595, 0.000000, 1)", majorPoint: "RVector(-0.124996, 0.216500, 0.000000, 1)", majorRadius: 0.249993, minorRadius: 0.144334, ratio: 0.57735, startAngle: 45, endAngle: 180, full: false, clockwise: true)
- [1] Undefined
- [2] REllipse(RShape(address: "0x204239c0"), startPoint: "RVector(11.675918, 2.746654, 0.000000, 1)", endPoint: "RVector(11.977686, 2.428095, 0.000000, 1)", center: "RVector(11.852689, 2.644595, 0.000000, 1)", majorPoint: "RVector(-0.124996, 0.216500, 0.000000, 1)", majorRadius: 0.249993, minorRadius: 0.144334, ratio: 0.57735, startAngle: 45, endAngle: 180, full: false, clockwise: false)

The issue is that the new entities are only (re-)generated when longer than RS.PointTolerance (Good practice).

The approximated Simpson-length for the ellipse-arcs are:

- [0 CW] **NaN**   (instead of about 0.683800238925154)
- [1] Not an RShape
- [2 CCW] 0.5773502691896258

The full ellipse is removed but not replaced by new segment [0] or [1].
Segment [2] is the segment that is broken out.

Similar new segment lengths for the segment near (12.02, 2.49):

- [0 CW] **NaN**    (instead of about 1.12960650667804213)
- [1] Not an RShape
- [2 CCW] 0.13154400143673767

Regards,
CVH

Andrew,

Bitmap entities can not be cropped by QCAD.
There are no properties to store the reference points of the cropped area.
The cropping area is not limited to a rectangular area.
Image entities at an angle are even more complex to handle.

In all, CLR rejects selected image entities at this stage.

Regards,
CVH

Andrew,

Reported for QCAD 3.32.3 Win10, replicated on Win7.

In your reply to user DerekGove you state:

• After the measurement, QCAD inserts the variable into the command line (e.g. d1). You can then confirm that value in the command line by pressing the enter key.

This is not entirely correct.
The focus should be on the Command Line before pressing the enter key.
Not an issue when inserting a variable in a tool option field. Evaluated on the fly.

Using IP to take some measurement the focus is shifted to the drawing panel.
Then hitting ENTER simply restarts the latest command or ‘arcc’ and no Arc entity is created with the previous active tool (also ‘arcc’).

Hitting the Space-Bar followed by ENTER may do the job.
Assumed to be the intended behavior ... Verified in QCAD 3.26.7

Your cursor is probably still nearby the second point of measurement ... Or not at all.
Hitting the Space-Bar followed by ENTER results in an Arc preview with seemingly a very arbitrary radius but finally repeatable depending the actual cursor position.

Steps to replicate:
- Start QCAD 3.32.3 with a new empty file (In mm over here).
- Start AR.
- Indicate center at (0.0, 0.0).
- R-Click on Command Line input field > opt for ‘Insert Measurement’ > opt for IP.
- Indicate a measurement point at (100.0, 0.0).
- Indicate a second measurement point at (90.0, 20.0) ...
... What is 22.360679774997896964091736687313 units apart.
... IP inserts the variable ‘d1’ on the Command Line.
- Ensure that your cursor is left very near this second point, snapped ...
... And even release the mouse device.
- Hit the Space-Bar.
- Hit the ENTER key or the Return key.
- Move your cursor a little to see a preview of the Arc.

This preview passes through the second point of measurement. Almost but not exact.
And has a radius of 92.19544457 units » Repeatable.

- Do just the same for the next Arc but leave your cursor near (80.0, 20.0).

This preview does NOT pass through the second point of measurement NOR through the indicated point. It has a radius of 85.6605063 units » Repeatable.

- Repeat but leave your cursor near (70.0, 20.0) → Radius of 82.33442756 units.
- Repeat but near (60.0, 20.0) → Radius of 80.62257748 units.

Any mathematical relationships eludes me.

Typing ‘=d1’ in the Command Line returns 22.360679774998 with 12 decimal digits.
The same is reported for subsequent identical measurements d(2-4).

Regards,
CVH

It would be handy to know which toolbar is what, which toolbar we are dragging.

Or which (Empty) toolbar is floating over the GUI drawing area.
Please refer to this forum post.

Regards,
CVH

Andrew,

Latest Trial version on Windows 7 32bit
QCAD Professional Trial 3.32.3 / Qt 5.13.2 / Windows i386
Detected in debugger mode.

In updatePreview an array with shapes to preview is queried with this.getAuxPreview().
These shapes are added to the preview with di.addAuxShapeToPreview(arrayItem).

It seems that the resulting object(s) in previewShapes can be an array of RShape objects.
Then addAuxShapeToPreview fails with an array instead of singular RShape object.

Most probably related to  FS#2605 

Regards,
CVH

Andrew,

Related to this forum topic with the attached file as example.
Tested on Win7 32 bit.

Open drawing as is.
Try:
- Drawing Preferences .. Layout .. Viewports .. Four: Equal » OK
- Menu File .. Revert » Acknowledge warning dialog: All changes will be lost!

There are still 4 GUI Viewports visible.
Check Drawing Preferences .. Layout .. Viewports » Reports one single Viewport.

OK won’t update to a single as no changes are assumed.
One can fix the current state by selecting another configuration and then a single again.

A difference spotted against v3.27.6.0 is that the border of the active Viewport turned dark blue before. This is not seen in the latest stable release.

Regards,
CVH

Andrew,

Related to this forum topic with the attached file as example.
Tested on Win7 32 bit.

Drawing Preferences .. General .. Grid .. Display Grid Y/N is not reflected in the GUI.
But changing the Grid visibility with GR is reflected back in the Drawing Preferences.

Per GUI Viewport:
It is thus possible to set the preference to yes without that the grid is showing.
Or clearing the preference with a visible Grid and then it remains visible.

Regards,
CVH

Andrew,

Still Writing most of my code on v3.27.0 and adapt that to newer resources.

Detected a difference in the latest version while adding entities with an interactive tool.
On v3.27.0 getAuxPreview shapes are Dashed-Dotted in color #7976c5 and displayed above existent entities and under the shapes to create in preview mode.

On 3.32.2 the auxiliary shapes are above the shapes to create in preview mode.

Where both fall together an entity to create as continuous looks like dashed.
For example: An auxiliary circle masks the arc that is being constructed.
Or an auxiliary ray masks a new line segment.

I liked the looks of things to be clearer under v3.27.0.
The preview of new entities are then as intended by the Linetype attribute.

The order of how things are send has not changed in EAction,
In updatePreview new entities come first.
Auxiliary shapes always come second.
Highlighted third.

Regards,
CVH

Andrew,

See related forum topic in the International Forums, Deutsch.

User ‘dijs’ reports:
QCAD Professional Trial Version 3.32.2.0 (3.32.2)
M1-Max-Mac Sequoia 15.4.

Using the Library Browser somehow corrupts the QCAD config file.
Closing and restarting the application fails.

QCAD start up as new when deleting the config file or with only removing the entry:

[Appearance] DockappWindows="@ByteArray(…)"

The corrupted line seems to be much shorter: 6k vs 17k characters in my case.

DockappWindows="@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x3\0\0\0\0\0\0\0\0\0\0\0\0\xfc\x2\0\0\0\x1\xfb\0\0\0\x1c\0T\0o\0o\0l\0M\0\x61\0t\0r\0i\0x\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0u\0\xff\xff\xff\0\0\0\x1\0\0\x1#\0\0\x4\xf0\xfc\x2\0\0\0\n\xfb\0\0\0\x1a\0\x42\0l\0o\0\x63\0k\0L\0i\0s\0t\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0z\0\xff\xff\xff\xfb\0\0\0\x1a\0L\0\x61\0y\0\x65\0r\0L\0i\0s\0t\0\x44\0o\0\x63\0k\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\xfb\0\0\0$\0P\0r\0o\0p\0\x65\0r\0t\0y\0\x45\0\x64\0i\0t\0o\0r\0\x44\0o\0\x63\0k\x1\0\0\0N\0\0\x1\x87\0\0\0`\0\xff\xff\xff\xfb\0\0\0&\0\x45\0\x63\0m\0\x61\0S\0\x63\0r\0i\0p\0t\0S\0h\0\x65\0l\0l\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0-\0\xff\xff\xfe\xfb\0\0\0(\0\x43\0l\0i\0p\0\x62\0o\0\x61\0r\0\x64\0\x44\0i\0s\0p\0l\0\x61\0y\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\x16\0\xff\xff\xff\xfb\0\0\0 \0L\0\x61\0y\0\x65\0r\0L\0i\0s\0t\0P\0r\0o\0\x44\0o\0\x63\0k\x1\0\0\x1\xd6\0\0\0\xe6\0\0\0z\0\xff\xff\xff\xfb\0\0\0$\0L\0i\0\x62\0r\0\x61\0r\0y\0\x42\0r\0o\0w\0s\0\x65\0r\0\x44\0o\0\x63\0k\x1\0\0\x2\xbd\0\0\x1T\0\0\x1&\0\xff\xff\xff\xfb\0\0\0&\0S\0\x65\0l\0\x65\0\x63\0t\0i\0o\0n\0\x46\0i\0l\0t\0\x65\0r\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\xff\0\xff\xff\xff\xfb\0\0\0\x18\0V\0i\0\x65\0w\0L\0i\0s\0t\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0z\0\xff\xff\xff\xfb\xff\xff\xff\xff\x1\0\0\x4\x12\0\0\x1,\0\0\x1,\0\xff\xff\xff\0\0\0\x3\0\0\b2\0\0\0\x43\xfc\x1\0\0\0\x1\xfb\0\0\0\x1e\0\x43\0o\0m\0m\0\x61\0n\0\x64\0L\0i\0n\0\x65\0\x44\0o\0\x63\0k\x1\0\0\0R\0\0\b2\0\0\0\x10\0\xff\xff\xff\0\0\b2\0\0\x4\xac\0\0\0\x1\0\0\0\x2\0\0\0\x1\0\0\0\x2\xfc\0\0\0\x4\0\0\0\0\0\0\0\x1\0\0\0\x14\0\x43\0\x61\0\x64\0T\0o\0o\0l\0\x42\0\x61\0r\x3\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\x1\0\0\0\x1c\0W\0i\0\x64\0g\0\x65\0t\0s\0T\0o\0o\0l\0\x42\0\x61\0r\x3\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x2\0\0\0\x17\0\0\0\x18\0R\0\x65\0s\0\x65\0t\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0\x46\0i\0l\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\0K\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0\x45\0\x64\0i\0t\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\x1h\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0V\0i\0\x65\0w\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\x2{\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0(\0I\0s\0o\0m\0\x65\0t\0r\0i\0\x63\0V\0i\0\x65\0w\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0S\0\x65\0l\0\x65\0\x63\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0\x44\0r\0\x61\0w\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x14\0\x41\0r\0\x63\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0\x43\0i\0r\0\x63\0l\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0 \0\x44\0i\0m\0\x65\0n\0s\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1c\0\x45\0l\0l\0i\0p\0s\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0H\0\x61\0t\0\x63\0h\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0L\0i\0n\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0P\0o\0i\0n\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1e\0P\0o\0l\0y\0l\0i\0n\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0S\0h\0\x61\0p\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0S\0p\0l\0i\0n\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0M\0o\0\x64\0i\0\x66\0y\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0S\0n\0\x61\0p\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0$\0I\0n\0\x66\0o\0r\0m\0\x61\0t\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0L\0\x61\0y\0\x65\0r\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0\x42\0l\0o\0\x63\0k\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0W\0i\0n\0\x64\0o\0w\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x2\0\0\0\x13\0\0\0\xe\0O\0p\0t\0i\0o\0n\0s\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x6\0P\0\x65\0n\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0 \0M\0i\0s\0\x63\0\x42\0l\0o\0\x63\0k\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0,\0M\0i\0s\0\x63\0\x44\0\x65\0v\0\x65\0l\0o\0p\0m\0\x65\0n\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1e\0M\0i\0s\0\x63\0\x44\0r\0\x61\0w\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1a\0M\0i\0s\0\x63\0I\0O\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0,\0M\0i\0s\0\x63\0I\0n\0\x66\0o\0r\0m\0\x61\0t\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\"\0M\0i\0s\0\x63\0M\0o\0\x64\0i\0\x66\0y\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\"\0M\0i\0s\0\x63\0S\0\x65\0l\0\x65\0\x63\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0 \0\x41\0t\0t\0r\0i\0\x62\0u\0t\0\x65\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1e\0V\0i\0\x65\0w\0p\0o\0r\0t\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0,\0\x45\0\x64\0i\0t\0Q\0u\0i\0\x63\0k\0M\0o\0\x64\0i\0\x66\0y\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0 \0M\0i\0s\0\x63\0L\0\x61\0y\0\x65\0r\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0*\0M\0i\0s\0\x63\0P\0r\0o\0j\0\x65\0\x63\0t\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x1c\0O\0v\0\x65\0r\0l\0\x61\0y\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0U\0s\0\x65\0r\0T\0o\0o\0l\0\x42\0\x61\0r\0\x31\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x18\0U\0s\0\x65\0r\0T\0o\0o\0l\0\x42\0\x61\0r\0\x32\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\"\0P\0r\0o\0j\0\x65\0\x63\0t\0i\0o\0n\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\0\0\0\x16\0H\0\x65\0l\0p\0T\0o\0o\0l\0\x42\0\x61\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0)"

The user can replicate the issue just by opening the Library Browser dialog.
Using 3.32.2.0 trial on Win7 32bit installation by ZIP I cannot reproduce the failure.

Regards,
CVH

Andrew,

Related to this forum topic where an export by dwg2svg fails in various ways.

The attached file in the topic has drawing unit ‘none’, the intended unit is ‘meter’.
The content of the given file is drawn extremely far form the origin (About 228 km away).
All this should not be a problem in any way.

A simple export with: dwg2svg.bat -o “_out_g_m.svg” -g -u m -f “input1.dxf” produces an export in mm (SVG limitation) but with no visible text.

We managed to get a better output with:
dwg2svg.bat -o “_out_1000mm.svg” -g -s 1000 -u mm -f “input1.dxf” We get a viewBox in meters and a scaled canvas in mm.
Values are then in meters and things are displayed 1000 times larger.

The first occurring text item in the SVG output is one in Model_Space:
Text at (148846.7038, 172548.9401); Height 0.35; Alignment Left Base

<!-- Text: 6.01 -->
<text x="0" dx="0" y="0" dy="0.35" font-family="ARIAL.TTF" font-size="0.49" line-height="1.1" fill="#000000" transform="translate(148846.7038,172548.9401) translate(0,0.35) scale(1,-1)" text-anchor="start">6.01</text>

Breaking this down:
- SVG font size = 140% (Height of capital ‘A’ vs lower case for SVG) = 0.49
- Created at 0.35 (units=m) down what is the CAD height.
- Translated 0.35 up because alignment = Base, again the CAD height.
- Translated to its position in the drawing at (148846.7038, 172548.9401).

This text is visible and positioned correctly including the tweak -s 1000 -u mm.
The font may be incorrect depending the client.
‘ARIAL.TTF’ is listed as last in QCAD (As not a system font)

All the text items from Model_Space are now visible and sized correctly.

A Block Reference for Block ‘$TITLE_BLOCK’ is inserted in Scale (0.01, 0.01) at (148862.63734451, 172549.97956209);
For a text ‘Tekening’ at (100, -50); Height 100; Alignment Left Top the exports reads:

<!-- Text: Tekening -->
<g transform="translate(148862.6373,172549.9796) scale(0.01,0.01)">
    <text x="0" dx="0" y="0" dy="100" font-family="ARIAL.TTF" font-size="1.4" line-height="1.1" fill="#000000" transform="translate(1,-0.5) scale(1,-1)" text-anchor="start">Tekening</text>
</g>

- SVG font size = 140% = 140 but scaled down by factor 100
- Created at 100 down what is the CAD height.
- Not translated up because alignment = Top.
- Translate within the Block is scaled down by factor 100.
- As group for a second time scaled down by factor 100
- As group translated to its position in the drawing at (148862.6373, 172549.9796).

Formatted following the rules seen in the Model_Space example this should read:

<!-- Text: Tekening -->
<g transform="translate(148862.6373,172549.9796) scale(0.01,0.01)">
    <text x="0" dx="0" y="0" dy="100" font-family="ARIAL.TTF" font-size="140" line-height="1.1" fill="#000000" transform="translate(100,-50) scale(1,-1)" text-anchor="start">Tekening</text>
</g>

When manually adapted for all text items in the ‘$TITLE_BLOCK’ they appear at the intended location and in correct size. See file <_out_1000mm_rev1.svg>

Revision 1 because text of the $LEGENDRCT Block is still not visible.
Most probably outside the viewbox or too small.

I attached the related files here.

Regards,
CVH

Andrew,

When for example the last used folder was ...QCAD/libraries/templates/metric
On ‘New from Template...’ the panel previews a list with templates in that folder.
⇒ Expected behavior

In the top Drop-down list called ‘Folder’ I can select ...QCAD/libraries/templates
In my case there is only one item listed.
But that doesn’t update the list in the preview panel.

Strangely enough when I now hit the ‘Up’ button the list is updated for ...QCAD/libraries
Or one up from ...QCAD/libraries/templates while the content of ...QCAD/libraries/templates/metric was still showing.

Navigation in the list panel works as expected.
Opening a different folder with the button ‘Choose Directory’ is also working as expected.

Also (starts to) works as expected with more than one item in the Drop-down list.
With starting over new there is again only one item to select.
Again failing to synchronize when selected.

Not reacting on the drop-down list ‘Folder’ with one option can be replicated in 3.27.6 Win7 32bit

Regards,
CVH

Andrew,

Observed by a user.
It is:
A) Or approximated by a Polyline with tangentially connected Arcs within some tolerance.
B) Or interpolated by a Polyline with Line segments depending a given number of segments.

Opting for B by the checkbox keeps the preference for A enabled.

In Explode.js these preferences are twice used in an OR clause:
- Explode Spline shapes
- Explode Spline shapes from TTF text
Both as polylines ‘with arc-segments’ (bulging) OR as polylines with line-segments.

It would be more appropriate to also toggle the enabled state of:

            widgets["SplineTolerance"].enabled = !state;
            widgets["SplineTolerance_Label"].enabled = !state;

And set the enabled states on init:

        widgets["SplineTolerance"].enabled = !widgets["SplinesToLineSegments"].checked;
        widgets["SplineTolerance_Label"].enabled = !widgets["SplinesToLineSegments"].checked;

The issue was a vast amount of line segments (14344) from an explosion.
The user was not aware of the OR clause.

It would also be beneficial if users would be aware that the default preference of 64 segments means: 64 Lines per Bézier Segment times (degree + 1)

The number of Bézier Segments depends on the original Spline.
- Equal to number of points when closed
- Number of Fit-Points - 1 (degree=3)
- Or number of Control-Points - degree

Regards,
CVH

Andrew,

Some habits die hard. Like drawing on a representation of a page with the intended aspect ratio, scaled for example.
Also typically ‘drawn at scale’ seen in many third party drawings.

It would be an enhancement that the indicated ‘window’ optionally has the aspect ratio of the page. Adapting deltaX or deltaY in relation with the largest indicated delta and the aspect ratio.

Also optionally accounting for paper borders or not.

And auto orientation depending on deltaX and deltaY of the indicated ‘window’.

For now (With such third party drawings) I still resort to the workaround as described here.
Page orientation as required
Viewport offset = Lower left ‘paper’ corner
Viewport scale = paper size divided by paper representation size
Simply indicating the opposite corners of the paper representation would be easier.

Regards,
CVH

Andrew,

A minute flaw (may) occurs when we rotate an RVector by zero rads around (0, 0).

rotate() is based on: The magnitude, getAngle(), cos() and sin()
getAngle() is based on: The magnitude, a dot product, divisions and acos()
getMagnitude2D() is the hypotenuse and based on sqrt()

These functions all have some degree of error.
Accumulated and reflected in the returned RVector while that should remain steady.

I then propose that the initial test also verifies isZero.

/**
 * Rotates this vector around 0/0 by the given angle.
 */
RVector RVector::rotate(double rotation) {
    if (!valid || rotation == 0.0) {
        return *this;
    }

    double r = getMagnitude2D();
    double a = getAngle() + rotation;

    x = cos(a) * r;
    y = sin(a) * r;

    return *this;
}

The extra cost is an OR clause and an equality test.
I suppose that this is not a major hurdle.

Comparing with NaN is always false.
As expected, rotating with an angle value NaN gives x=y=NaN.
Neither z, nor the valid flag are affected.
The resulting vector is considered to be valid.

Eventually x=y=NaN will fail somewhere else.
Returning NaN for any calculation with x and/or y.

For now ...
The workaround is to verify it yourself for all RVector rotations that occur in a script:

// For all in the nature of:
pos.rotate(angle);

// Replace code with:
if (angle !== 0.0) {
    pos.rotate(angle);
}

What is more costly because ‘angle’ can be the inline result of an equation.
That must then be store in a variable or calculated twice.

In many cases we are not able to fix it. For example:
- Rotating RVector’s forth and back is rather common in various REllipse resources.
With the major axis and major point aligned with +X that serves no use ...
... But the things do shift.

As key resource the issue is not at all limited to ellipse methods only.

Regards,
CVH

Andrew,

In the attached file ‘ActingOnNotSnappable.dxf‘:
Both Block References are on layer 0 ... Snappable
Both red shapes are on layer 2 ......... Not snappable

Start AT, radius 15, indicate near the red circle and then a point on an arc.
Solutions to the red circle are previewed while this shape is NOT snappable.

(For the record: AT is not (yet) functional for ellipses)

Implemented as in many tools:
Typically in pickEntity it is verified that the indicated entity is snappable.
Returning nothing if not.

    if (!this.isEntitySnappable(entity)) {
        return;
    }

Here ‘this’ refers to EAction.
- Checking if the given entity is not Null and derived from REntity.
Otherwise returning false ⇒ nothing.
- Retrieving the entity layer ID, its data and document.
- With a document verifying that the layer by id is snappable.
Returning false ⇒ nothing without a document.

What follows is a double test already verified for in the AND clause above:

    if (isNull(entity)) {    // # Duplicate # isEntitySnappable(entity) would be false
        return;
    }
    else { ...

After that it gets the nearest simple shape and verifies if that is supported by the tool.
For example ArcTPR, current line 145

        shape = entity.getClosestSimpleShape(pos);

For a Block Reference living on a snappable layer it is not verified if the nearest simple shape also lives on a snappable layer.

I know, it gets more complicated than that ... The nearest simple shape may be a Polyline segment, a part of a Dimension, a simple shape from an explosion and so on.
These simple shapes are themselves no existent entities with the required layer to verify.
Then it is obvious that they virtually live on the same layer as the base entity.

One can test this on only the middle segment (Arc) of the Polyline.
Unless it is moved to layer 2.
Or AT to the dimension line or even the arrows, extension lines, ...

Being snappable is not always the case when shapes are part of a reference to a Block,
part of a Block Reference.
It can not be the intention that everything in a Block must share the same layer.

One could query the nearest sub entity ID with:

var subId = entity.getClosestSubEntityId(pos, Number.NaN, true);

But that is like doing things twice because it calls the same resource of REntityData.

REntity.getClosestSimpleShape(pos) calls REntity.getClosestShape(pos, range=NaN, ignoreComplex=true)
What calls REntityData.getClosestShape(pos, range=NaN, ignoreComplex=true, subEntityId=NULL);
Returning at least an invalid RShape.

Convenience function for scripts:
REntity.getClosestSubEntityId(pos, range=NaN, ignoreComplex=true) calls REntityData.getClosestSubEntityId(pos, range=NaN, ignoreComplex=true)
What calls REntityData.getClosestShape(pos, range=NaN, ignoreComplex=true, subEntityId=RObject.INVALID_ID);
Disregarding the shape but returning the subEntityId

Combining and querying the shape, and the entity ID at once fails so far ...
... QCAD Crashes.

Regards,
CVH

Andrew,

Win7, latest stable QCAD trial release installed from ZIP file.
Version: 3.31.2.0 (3.31.2)
Build Date: Oct 27 2024
Revision: bae1b88
Qt Version: 5.13.2
Architecture: i386
Compiler: MSVC++ 14.16 (2017)

Fresh restart of QCAD loading an existing file.
→ Mouse wheel = Zoom IN/OUT

Switch to Print Preview mode (Ctrl+Shift+P)
→ Actuating the mouse wheel sets the origin at the left lower corner of the GUI view area.
→ No zooming occurs at all.
→ I can zoom and pan with other methods but actuating the mouse wheel in Pan Zoom mode exhibits the same issue.

Switch back to Model view (Close Print Preview)
→ Issues remain.

I can replicate the same behavior when starting QCAD and selecting a Layout with Viewport from the Block List. Essentially automatically in Print Preview mode.

What seems to be fixed in the mean time (3.27.6) is that the mouse wheel = vertical scrolling after visiting the Application Preferences. Or in and after Print Preview mode.

I would upgrade to the newest release for production when I could turn off the “Show” buttons. The Always show all properties preference of the Property Editor has no influence on that. See: Related topic

Regards,
CVH

Andrew,

It simplifies drawing circles where the target circle must be internally tangent instead of only externally. Or relevant constructions with Arcs.

It also avoids the repeated sequence:

Step 1: LI
Base point
Target point perpendicular on circle/arc, Auto Snap or forced by SU 
(or center snap SC of if that is easier)
QQ

Step 2: RM
Drawn auxiliary line of first step
Far side of circle/arc
QQ

Step 3: Use the intersection for another task, Auto Snap or forced by SI/SY 

Regards,
CVH

Andrew,

Related to this Forum topic
(ArcTPR.js: Offsets to an ellipse are fit-point splines)

The array of intersections of a fit-point spline and a circle is always empty.

The method is broken ...
OR
The method is not implemented at all without mentioning it ...!?
(Already failing with QCAD 3.27.6.0)

Workaround 1:
Quote: If we trim or cut up a fit-Point spline the result(s) is/are (a) control-point spline(s).
If any, the intersections between these splines and a circle are valid.
Downside:
If the circle crosses the cutting point (or the start=end point when closed) then
two identical intersections are included.

Workaround 2: Approximate the fit-point spline with a polyline (Explode).
Expected are approximate intersections.
Unaware if that is the method used for intersections internally.

Below a simple script that can be run with XC:
→ No intersections as fit-point spline
→ 4 intersections as control-Point spline segments (Workaround 1)

// Example points to fit:
var fitpoints = [new RVector(0, 9),
                new RVector(7, 0),
                new RVector(0, -9),
                new RVector(-7, 0)];

// Create a spline shape:
var spline = new RSpline();
spline.setFitPoints(fitpoints);
spline.setPeriodic(true);
// Create a circle shape:
var circle = new RCircle(RVector.nullVector, 8.0);

// Get intersections of spline and circle, expecting 4:
var ips1 = spline.getIntersectionPoints(circle, false);
// Report the number of intersections on the Command History:
EAction.handleUserInfo("As fit-point spline: %1 intersections (of 4)".arg(ips1.length));

// Cut up the spline in two parts -> Control-Point spline
var cutPoint = spline.getTMin() + (spline.getTDelta()/2.0);    // fitPoint (0, -9)
var splines = spline.splitAtParams([cutPoint]);

// Get intersections of both spline segments and circle:
var ips2 = splines[0].getIntersectionPoints(circle, false);
ips2 = ips2.concat(splines[1].getIntersectionPoints(circle, false));
// Report the number of intersections on the Command History:
EAction.handleUserInfo("As control-point splines: %1 intersections (of 4)".arg(ips2.length));

Regards,
CVH

Andrew,

As test I added this customiso.lin file:

;;
;;  Custom QCAD linetypes for metric system
;;
*DASHEDC,Custom Dashed _ _ _ _ _ _ _ _ _ _ _ _ _ _
A, 2, -1 
*DOTTEDC,Custom Dotted . . . . . . . . . . . . . .
A, 0, -1  

All fine but they are listed as ‘DASHEDC’ and ‘DOTTEDC’.

Kinda expected that the description would be used to list them.
All seemingly according the standard types.

Where for example

*DASHED2,Dashed (.5x) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
A, 6.35, -3.175

is listed as ‘Dashed (.5x)’ and not as ‘DASHED2’

Most probably because ‘types’ are translated and mine are not in that standard list.
It would still be appropriate to use the descriptor.
Then I have the option to include that in English or in an even custom language.

Regards,
CVH

Andrew,

The mouse tips of some manual snap options (SN, PX, PY, SH) are not handled.

For SN the mouse tips and the command line tip are unaffected.
Tips for PX and PY are only handled as command line tips:
- ‘Specify point for X coordinate’.
- ‘Specify point for Y coordinate’.
Tips for SH are only handled as command line tips:
- ‘Specify first point to measure distance from’.
- ‘Second point’.

As counter example:
For SY both mouse tips and command line tips change to:
- ‘First entity’.
- ‘Second entity’.

For SN we would expect at least a guidance that we are indicating the first or the second position. That could be implemented as command line tip but adding some additional mouse tip would be welcome.
For PX and PY we could add ‘(X)’ or ‘(Y)’ to the current mouse tip.
For SH we could add ‘(Origin)’ and ‘(Direction)’ to the current mouse tip.

Regards,
CVH

Andrew,

Related topic: https://www.qcad.org/rsforum/viewtopic.php?f=32&t=10972#p45395
The user replied “I don’t have the option to “Flatten drawing to 2D”

The topic is thus misplaced in the QCAD Professional Version forum.

On checking it seems that ‘Flatten Drawing to 2D’ is a Pro only feature.
But this important feature is not listed as such on the QCAD features page

Regards,
CVH

Andrew,

The common circle of inversion in QCAD code seems to be a circle with R=10 e.g.:

var inversionCircle = new RCircle(point.position, 10);

Said to be arbitrary meaning that any well chosen circle will do.

There are a few drawbacks with a fixed radius of 10:
- For most and much larger circles outside such an inversion circle the inversion is a tiny circle shape. The aimed results are usually larger data and those are then based on minute data from the inversion shapes.
- For smaller circles inside such an inversion circle the inversion is quite a large circle shape. The aimed results are usually smaller data and those are then based on huge data from the inversion shapes.

It tend to play a role when we are working above the 10e3 range or below the 10e-3 range. At some point Apollonius.verify() based on Apollonius.shapesTouch() may remove solutions based on a difference of more than RS.PointTolerance.

Additionally an inversion circle with radius 10 may cross the center of a circle to inverse.
Resulting in a line.

My advice is to adapt the arbitrary radius relatively to the shapes involved, to something meaningful in the problem at hand.
For example based on the smallest of the radii of the circles to inverse.

I have to advice against using a larger (fixed) tolerance than RS.PointTolerance to solve certain issues.
Again, the best tolerance in any case of comparison is an adaptive one.

Regards,
CVH

Andrew:

Apollonius.getSolutionsPCC(...) calls for ShapeAlgorithms.getTangents(circle1, circle2)
What returns an array with tangent lines to the 2 circles.
- Empty when concentric (*)
- With 4 elements, the two external tangent lines and the two internal tangent lines if they exists.

Both or one endless internal tangent line(s) exists when the distance between the centers exceeds or equals the sum of the radii. Both the external exists when the smaller circle is not fully inside the larger circle, concentric disregarding the size is already excluded. When a smaller circle is internally tangent, only one endless tangent line exists.

Apollonius.getSolutionsPCC tests for an empty array but does not verify that the first external tangent exists.

In the case that it isn’t a line piece as expected:

var p1 = tangents[0].getClosestPointOnShape(circle1.getCenter(), false);

Will throw an exception ... Halting the code in debugger mode.

Reproducible in the attached file

I can not find any other use of ShapeAlgorithms.getTangents in open sources without verifying the returned tangents.

Further I detect a flaw in ShapeAlgorithms.getTangents(...)

    var dist1 = circleCenter1.getDistanceTo(circleCenter2);
    ...
    // outer tangents:
    var dist2 = circleRadius2 - circleRadius1;
    if (dist1>dist2) {
        ...

When circleRadius1 > circleRadius2 the subtraction becomes negative and the comparison is always true.

To my knowledge dist2 must be the subtraction in absolute.
OR
Circle 2 must be the larger one but that is not a condition here.

(*) Remark that with concentric or circles in each other there are still solutions possible.
And in general there are up to 4 possible solutions for Circle2TP.
That would be a next contribution for Apollonius.js I am working on.

Regards,
CVH

Andrew,

Reported by user SteveRay: https://www.qcad.org/rsforum/viewtopic.php?t=10929

I can replicate this in 3.30.0
The Distance/Angle information is only displayed when the cursor is near a snapping point.

Regards
CVH

Andrew,

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

For the drawing included in the topic: Mobilhaus.dxf
Drawing units: meters
Page units: millimeters

Page areas are defined by the user in Model_Space with a lower left corner at:
(0.0,0.0) , (21.0,0.0) , (42.0,0.0) , (63.0,0.0) and (84.0,0.0)
This are drawing units and thus meters.

When we setup the printing region to print page 2:
Scale: 1:100
Offset X: 21 (mm)
Offset Y: 0 (mm)

Prints perfectly.

But 21m in scale 1:100 would be 21cm or 210mm and that is indeed the width of a page.
Other test have shown that the Viewport offset is in drawing units.
And not 21 (mm) as displayed in the Drawing Preferences .. Printing .. Page widget.

Probably not OS related.
Tested in 3.30.0 and 3.27.6 on a Win32bit

In the topic there is also a revision of the file using Layouts and Viewports.
The most applicable way to approach something like this
Then the Viewports centers are also in drawing units.

Regards,
CVH

In the sense that current open file(s) is/are part of a new project and you want that/those to remain in the list.

Can be circumvented by:
- Clear recent list
- Save current open file(s)

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

Regards,
CVH

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 outside the evolute.

On the major axis is defined by getAngle().
This may fail for a magnitude equal to or less than 1e-6.
A point that close to the center should not have a single solution at zero degrees.

The correct solutions are:
- If p is equal to the center ⇒ Two vectors to the two minor points.
- On the major axis and strictly inside the evolute ⇒ Two mirrored vectors.
- On the major axis and on or outside the evolute ⇒ The nearest major point.
- On the minor axis ⇒ The nearest minor point.

An additional problem is now what to return on a duality with full ellipses.
Or for an ellipse arc where both of two results are valid.
getVectorTo() typically returns but one unique result.

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

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,

At present QCAD/CAM the tool drop-down box displays tool number and diameter between brackets.

It would be more appropriate to display if it is a mill or a drill and/or the description of such.
In a further stage of development ball-nose ... Conical ... And so on.

I have several specialized mills with the same diameter.
End-mills, roughing mills, routing mills, face mills ....

Tools 1(ø6mm) or 2(ø6mm) don’t say much if tool 1 is a side-mill and tool 2 is a high speed drill for metal.

Related forum topic:
https://www.qcad.org/rsforum/viewtopic.php?f=31&t=10722

Regards,
CVH

Andrew,

When we alter about any property of a Hatch entity it seems to be recreated with a newer/higher handle.
This doesn’t influence the drawing order in direct.
But already changing the drawing order of a Hatch it is recreated as a new entity.

It starts to matters in drawing order when there are multiple entities with the same drawing order and that after save/reload. Entities with the same drawing order then receive a new drawing order based on the original but sequentially increasing based on handle.

Because a Hatch is recreated with a newer/higher handle each time a property changes it will thus always end up above the others with the same order even when the original was created earlier.

This is more pronounced when copying/pasting entities from a source to a target drawing.
The original Hatch drawing order is retained but it will always be above existent entities with the same drawing order in the target drawing after save/reload.

Most other entities are probably just updated in situ.
It is unsure to me at this point if merely updating a Hatch is even possible.
And perhaps this is related to the addObject ForceNew flag what is false by default.

Regards,
CVH

Related forum topic:
https://www.qcad.org/rsforum/viewtopic.php?f=74&t=10468

For ‘milling’ on path it doesn’t consider

this.arcInterpolation = true

in the custom postprocessor nor the checked option in the CAM Configuration Dialog.

As far as detected the CamArcInterpolation checkbox of the CAM Configuration Dialog is unrelated to the this.arcInterpolation in the postprocessor.

Regards,
CVH

Andrew,

Referring to this forum post:
https://www.qcad.org/rsforum/viewtopic.php?f=74&t=10152

With radii 1341.35667735 and 26 the relative tolerance is 0.00683678 and exceeds the former used fixed tolerance of 1e-4.

These arcs will then be considered to be tangent and the intersection point is 0.31024 units to the left of where we expect it.

Implemented: https://github.com/qcad/qcad/commit/77ae3e4518cc34f178779d2d2c724adcf80c229d#diff-dcc4e31eaeaed5a047f65dbce4ddda4bcd4d604e9e1005ee8481ded273768449

Updated: https://github.com/qcad/qcad/commit/071b60acd1176e6301bf6b6fcf716684221a97e8#diff-dcc4e31eaeaed5a047f65dbce4ddda4bcd4d604e9e1005ee8481ded273768449

I had already expressed my reserves on the relative tolerance but that was already a better solution for small arcs:
https://www.qcad.org/rsforum/viewtopic.php?f=33&t=8775&p=34907#p34907

We could limit the tolerance by:
A- The smallest of the fixed and the relative.
B- A relative tolerance based on R2 there circle 1 is forced to be the larger one.

This will never account for the position in the plane.
At a certain point the tolerance will be less than the accuracy/certainty of the values.

Regards,
CVH

Andrew,

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

When entering 1’ 1’‘ in an input field.
- As the size of the rectangle in the topic
- As the length property of a line selected in the drawing
- ....

Returns 13 in a drawing in mm.
And also in a drawing in inch what turns out to be correct.
But also in a drawing in foot.

Similar, entering 1’ with a drawing in kilometers it returns 12 units = 12 kilometers.

Regards,
CVH

Andrew,
For more detailed description please refer to:
https://www.qcad.org/rsforum/viewtopic.php?f=33&p=40081#p40081

In the included screen grab below, left is when drawn cubic, closed periodic, from 4 points.
Right is when the file is re-loaded.

It is hard to select the incorrect shape when pointing near it ... Probably it is referring to the correct internal shape.
After drawing it explodes to a Null length polyline with 2 identical vertices.

I can’t include the error in a file as it reverts on re-load.

The same issue exist for quadratic, closed periodic, from 3 points.

Regards,
CVH

Andrew,

Usually I point to something to start with.
Sometimes I want to point away from here but then the arrow is where I just clicked.

An option on creation would be nice.
The capability to reverse the Leader orientation afterwards is another method to get it pointing the intended way.

A Leader entity is stored similar as a polyline.
I think it would not be difficult to reverse the basic polyline and update the dimension shape accordingly.

Regards,
CVH

Andrew,

When we use Lengthen/Shorten (LE) with a positive amount the result is clearly visible when indicating a side of an entity.
With a negative amount there is seemingly no preview.
It is generated and shown but one can not distinguish it especially with solid lines.

Adding an orthogonal auxiliary preview shape some N pixels long would do the trick.

Regards,
CVH

Andrew,

Unrelated to OS or QCAD version.

In the postprocessor configuration dialog there is a group box called ‘GroupCustom’.
One can add custom widgets to that, rename it and so on.

Such is not provided in CamProfileToolpathDialog.ui or CamDrillToolpathDialog.ui

It should be possible but we aren’t really able to mix up things with the ‘Message’ QLabel ...
A reserved QGroupBox would do the trick.

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

Regards,
CVH

Andrew,

When switching from Default to Dark mode the text on alternating rows is hardly visible.
We can customize this color.

It would be easier if a proper default color is set on switching to and back.

Perhaps the user preferences can be remembered.
Perhaps only when the contrast would be affected.

Regards,
CVH

Andrew,

Not OS or Version depending.

We can’t filter on some specific properties of polylines.

Handy would be:
- Global Width
- Orientation

Specific:
- Polyline Pattern
But I don’t really search for them ... For some post-op I just need them all to be set to ‘No’.
- # of vertices
Filtering the complex from the more simple ones.
- Including Bulges or not
To seperate polylines with arc segments form others.
There some operations that don’t really work with bulging.
- Z values and/or global Z
This would make sense for some but filtering on Z is not common under QCAD as it is 2D.

Regards,
CVH

Andrew,

Changing orientation of a polyline with RV or by changing it in the Property Editor clears the global width value.

Single line pieces as polyline default to CCW.
Still the global width is cleared when trying to set them CW.

I didn’t update since 3.27.0 but reading this topic I suppose it still is valid.
Related: https://www.qcad.org/rsforum/viewtopic.php?f=89&t=9362

Regards,
CVH

QCAD Professional
Windows7 pro WinInstaller
Version: 3.26.4.5 (3.26.4.5)
Internet: QCAD.org
Build Date: Jul 20 2021
Revision: e596276
Qt Version: 5.13.2
Architecture: i386
Compiler: Unknown

In the example given by ‘turtle’ .. why_is_this_not_closed-v2.dxf
https://www.qcad.org/rsforum/viewtopic.php?f=32&p=34157#p34153

Selecting hatch boundary segments of the horizontal polyline segment at
(1169.933593;274.432562)-(1089.933593;274.432562)

Segment selection stops where the AR-CONC hatch pattern touches the horizontal segment.
Such intersections points where already no longer regarded as snappoints.
See :
 FS#2090 : https://www.qcad.org/bugtracker/index.php?do=details&task_id=2090.
Related topic https://www.qcad.org/rsforum/viewtopic.php?&t=7340&p=28414#p28414

Regards,
CVH

QCAD Pro 3.25.2.7 Win7 Wininstaller 32bit
Related Topic:
https://www.qcad.org/rsforum/viewtopic.php?&t=7954

Reported is that black is saved as #00004c (dark blue)
Radek (iMac (Retina 5K, 27-inch, 2017), Catalina 10.15.7 (19H114)

My system/installation saves black as #4c000 (dark red)

When using single primary colors these get reduced to #4c, #7f, #99, #cc & #ff.
The threshold for that are #00, #65, #8b, #b2 & #e5
See: DimColorScale (png & dxf)

8 standard CAD colors fail saving correct
Black (something with #4c)
Dark Red, Dark Green, Dark Blue, Dark Cyan, Dark Magenta, Dark Yellow
(#80 turns #7f)
& Gray
(#adadad instead of #a0a0a4)

As with Gray, when mixing the 3 colors it gets rather fuzzy ...
#505050 & #555555 both turn #5b5b5b
&
#464646 turns #4c4226

A snippet of my investigation is included in the topic
(45 files in a ZIP)

CVH

Include RPolyline.getLeftRightOutline() method in class_r_polyline.html

In use since 11 Sept 2020

CVH

QCAD Professional
Windows 7, Win installer 32bit
Version: 3.25.2.7 (3.25.2.7)
Internet: QCAD.org
Build Date: Dec 16 2020
Revision: e06f230
Qt Version: 5.13.2
Architecture: i386
Compiler: Unknown

Issues most likely unrelated to OS and installations before 3.25.
Related post:
https://qcad.org/rsforum/viewtopic.php?&t=7982

Flaws documented in full in attached dxf.
The dxf has meaningful Layer States.

4 Columns:
- Prior Art
- The test cases
- Actual results
- Results with proposed fix

Tried as many things as I can come up with.
Orange: Flaws
Red: Errors
Green: Good results (or as good as I can get them)

Solution(s) given in attached script explode.js
(I am just a simple guy and wouldn’t know how to file a pull request on GitHub ......)

In section: “explode polyline into line and arc segments”
group: “if (RPolyline.hasProxy() && polyline.hasWidths()) {....}”
All additions, updates & typos are marked with “CVH”, one can textual search for it.
Over-documented for sure.
Any Eaction is to debug in Windows and is obsolete.

Included PreferencesPage.ui is updated for the all Splines from Text fix
Still in consideration: Forcing cubic splines from text to degree 2 ...
... I am rather convinced ...

CVH

QCAD/CAM
Trial package Win installer 32 bit
Version: 3.25.2.0 (3.25.2)
Internet: QCAD.org
Build Date: Sep 4 2020
Revision: 4a61501
Qt Version: 5.13.2
Architecture: i386
Compiler: Unknown

Local decimal separator is ‘,’ (comma)
In CAM configuration .. Z Levels .. Safety level

Using nn,nnn the output is Nxx G0 Znn
Using nn.nnn the output is Nxx G0 Znn.nnn

Drop down boxes are all in dot format.
Didn’t try anything else yet

Regards,
CVH

Unrelated to OS, nor version

Reported Jun 23, 2020 in: https://qcad.org/rsforum/viewtopic.php?f=30&t=7372

Status Dec 24, 2020: https://qcad.org/rsforum/viewtopic.php?f=30&t=7372#p30955 Documentation is updated.
The Classes still refer to an ‘angleTolerance’.

Regards,
CVH

QCAD Professional
Win installer 32bit
Version: 3.25.2.7 (3.25.2.7)
Internet: QCAD.org
Build Date: Dec 16 2020
Revision: e06f230
Qt Version: 5.13.2
Architecture: i386
Compiler: Unknown

Not related to OS, nor version.

The method Polyline from Segments (OC) can be configured for tolerance and simplification in the Options Toolbar.
The method Polyline from Selection (OG) has no UI or none showing.

OG retrieves a tolerance from QCAD.ini, what is initially not set:

    var tolerance = RSettings.getDoubleValue("PolylineFromSelection/Tolerance", 0.001);

The tolerance will be default = 0.001 similar as the default in AppPrefs.
The tolerance setting is included in QCAD.ini after changing the AppPrefs entry.

OG calls PolylineFromSelection.autoJoinSegments with this tolerance:

    var counter = PolylineFromSelection.autoJoinSegments(di, tolerance, this);

PolylineFromSelection.autoJoinSegments calls PolylineFromSegments.createPolylineShape
with simplification hard coded to true. (last parameter)

    // create polyline from line, arc, spline or open polyline entity:
    var polyline = PolylineFromSegments.createPolylineShape(
                    entity, doc, vTolerance, op, undefined,
                    traversed, callBacks, undefined, true);

I would like to see the simplification optional and default = true.

Regards,
CVH

QCAD Professional
Win installer 32bit
Version: 3.25.2.7 (3.25.2.7)
Internet: QCAD.org
Build Date: Dec 16 2020
Revision: e06f230
Qt Version: 5.13.2
Architecture: i386
Compiler: Unknown

Origin:
I like to start my CAM paths at low curvature instead starting at high curvature.
Ellipses may explode with the startpoint at the tip. (file Y2)

Documented in 3.25.2.4, reproducible under 3.25.2.7

File included with 4 LayerStates
- Original Ellipses: Y1
- Exploded to polylines (32 segments): Y2
- Direct after XP, OR performs different on the left top one: Y3
- Faulty solutions by OR: Y4 (= saved state)

The results may differ with the saved explosions.

With the file.
Y1
TA
XP
Relocate startpoint with OR to an existing reference (called ‘End’)

Regards,
CVH

QCAD Professional
Win installer 32
Version: 3.25.2.7 (3.25.2.7)
Internet: QCAD.org
Build Date: Dec 16 2020
Revision: e06f230
Qt Version: 5.13.2
Architecture: i386
Compiler: Unknown

Discovered in 3.25.2.4, reproducible under 3.25.2.7

Draw any open or closed chain of line entities.
Select All.
OC to Polyline.
Step through vertices.

No example file provided because these NaN values are not saved to a file.
More pronounced with lines as with arcs.
Less pronounced when recombining after an explosion.
Some methods clear these to value = void.
Some methods clear these to zero (OR).
Can also occur when adding segments to an existing polyline with OC.

Regards,
CVH

QCAD Professional
Win installer 32bit
Version: 3.25.2.7 (3.25.2.7)
Internet: QCAD.org
Build Date: Dec 16 2020
Revision: e06f230
Qt Version: 5.13.2
Architecture: i386
Compiler: Unknown

Documented in 3.25.2.4, reproducible under 3.25.2.7
In the attached file:
→ Explode the trial cases and locate NaN Widths.
→ These faulty widths are cleared while saving and reverting.
= work around.

Related Post: https://www.qcad.org/rsforum/viewtopic.php?t=7902#p30902
Related Topic: https://www.qcad.org/rsforum/viewtopic.php?t=7901
Related Commit: https://github.com/qcad/qcad/commit/fcd7929bced7ae328029c1aa2ee2aff2745709c6

Arctic_Eddie reports failing CAM offset at exactly these points !!!
Reported is a faulty arc with radius of over 360,000mm.
- I can not reproduce this under QCAD working further on the Polys with NaNs.
- However the direct offset of such controlpoint Splines is erroneous.
(see file in post 30902)

Arctic_Eddie reports arc radii of over 10,000mm.
- These don’t seem to be faulty.
- I agree that BiArc fitting should be bound to a lower and certainly to an upper limit.
- That should be huge otherwise faint curvature is represented by many
wobbles or too quick by straight lines.
(All this, keeping in mind that QCAD doesn’t return the optimum fitted BiArc, see: https://www.qcad.org/rsforum/viewtopic.php?t=4859)

Regards,
CVH