All Projects

Andrew,

Concerning commit: https://github.com/qcad/qcad/commit/73a3b141bbe7438f36adad7219545e7b85d4304f

The sane number limits within -1e+12 to 1e+12 are removed.
RMath::isSane(value) is now reduced to an analog of RMath::isNormal(value).

This means that every numeric value except NAN and +/-INF is normal AND sane.
About sure that I can give counter indications of that.

I do not consider the used coordinate values as sane.
Please explain why we should support things in real world size
(A chair, about 500 by 500mm)
placed at X = 3440898387387.5750mm (+/-1ULP is about +/-0.0005mm)
and Y = 15219137016394.785mm (+/-1ULP is about +/-0.002mm)
While the longest distance on Earth is about 40075017000mm.
Or about and less than 1/100 of those in the drawing file.

The origin of these insane values is probably:
"A metric unit represents one point (1/72 inch)"
"Divide the metric value by 185771 for mm"
Then the coordinates are about 84 and 82 km from some reference point.
Instead of about 8-9 times the distance to the Moon.

But that won't hold because the page border is 42000 by 29702mm.
Almost exactly A3 scaled up 100 times and used in scale 2.00.
The file data is probably edited in multiple applications.

Allowing larger numbers is one.
But why is this suddenly associated with shorter (not smaller) Arc segments?
And also with longer Arc segments.

Shorter Arc segments has always been problem.
Even when far over the common RS::AngleTolerance (Not PointTolerance).
Polyline Arc segments are considered to be straight with a bulge of less than 1e-6.
atan(0.000001)*4 = 3.9999999999986666e-6 rad
… Not the end of the story … The chord between the two vertices must be over 1e-6 long.
Otherwise the chord has always an undefined orientation equal to zero.
The center is then limited to vertically up/down from the midpoint.

The biggest flaw sits in 'Longer Arc segments'

        if (ret > 2 * M_PI - 1.0e-16) {
            ret = 0.0;
        }

IMHO, 6.283185307179586 minus 1e-16 remains 6.283185307179586
Meaning that you can subtract 1e-16 from 2Pi several times over and still end up with 2Pi.
2Pi - 1e-16 - 1e-16 - 1e-16 - 1e-16 - 1e-16 === 2Pi

1ULP of 2Pi is 8.881784197001252e-16
Subtracting about half of that would have an influence on the LSB by binary rounding.
2Pi - 5e-16 = 6.283185307179585
All depends on the rounding scheme.

As 'FIXED' a near a full circular Arc is now 2Pi or more and not a fraction less.

The so-called 'FIXES' are only applied in RArc::getAngleLength
Checking for near zero rad or near 2Pi occurs at various places.

Since some time my near 2Pi limit is defined as 6.283185307179584.
Based on a survey that DXF records values ending in 179586 or 1795862.
(The 2 is a flaw, 4 or 5 is expected)

Also defined 2Pi as 6.28318530717958647692528676655900577
(36 digits, analog to RMath)

QCAD code is riddled with the multiplication of Pi times 2 and the division by 2.
RMath specifies M_PI, M_PI_2 and M_PI_4 (36 digits) but JS and C++ may still use derivatives of Pi.

It is a bit faster with various well defined (and effectively used) constants.
A JS equation must be translated, evaluated, passed on to C++ and the result back.
Even if that is merely a binary exponent shift.

Regards,
CVH

strictRange by default typically RMAXDOUBLE

Expected is a vector with a magnitude strictly not larger than the given range.

But the behavior is very different in regards with the shape:
- RArc: Unused, compare strictRange with distance to center minus radius
- RLine: Only applied for non-perpendicular vectors towards the nearest endpoint if limited
- RCircle: Unused, see RArc
There is always a perpendicular vector towards an RCircle
- REllipse: Unused, there are 0-4 normals for a full or limited ellipse shape
Compare strictRange with distance to (nearest) point on ellipse ...
... At least, if that would be a point exactly on the ellipse or not a false positive
- RPoint: Unused, compare strictRange with distance to point
- RPolyline: Only applied for non-perpendicular vectors towards limited line segments
- RXLine: Unused, handled as unlimited RLine
There is always a perpendicular vector towards an RXLine
- RRay: Unused for unlimited, not passed on for limited ⇒ RMAXDOUBLE
- RSpline: Undocumented for proxy, otherwise handled as RPolyline
- ...

Turns out that for a returned valid vector one still has to verify that it is within range or not.
getDistanceTo is itself based on getVectorTo ... Doing things twice.
Or that the projected point is on the limited shape ... Also doing things twice.

Then I don’t understand the purpose as it is only implemented for an RLine (segment) when limited. And then only when the projected position is not on the limited shape.
What requires an extra diversification on perpendicular or not.

I only see a purpose for RLine.getVectorTo(pos, false, 1e-6)
What is equally tolerant for the start and end of a limited line (segment).
Except that the magnitude from the start is always exactly zero, even when near.

Regards,
CVH

Andrew,

In an ideal world the angle of a horizontal vector pointing to the right would be zero.
But the numerical system is not ideal, is it?

Breaking it down in the current reference:

double dp = getDotProduct(*this, RVector(1.0, 0.0));

On itself a of an overkill ... It is simply dp = x

Then handled as 3 cases:
- x / m >= 1.0 the intermediate result is 0.0
- x / m < -1.0 the intermediate result is Pi
- else the intermediate result is acos(x / m), a result limited in quadrant I or II

Not really critical: Case 2 is missing an equality sign.

In a last stage this value is projected to the III and IV quadrant when y is negative.

Assuming x is equal to m and the intermediate result is 0.0
Then y must be zero and the final result is zero.
Even if y differs from zero by a tiny bit, sqrt(x²+y²) can not be equal to x.
Theoretically.

In floating point this would occur when x is large enough and y small enough.
So that x’²+y’² = x’² and x’ / m = 1 holds.
Because of a very small negative value of y the result is then 2Pi - 0.0 = 2Pi.

The flaw: X is normalized to a unit circle, Y not!
Test reveals that y/m < 0.0 will not trigger on nearly negative zero.

The solution would be to normalize the result of for example:
- RVector::getAngle()
- RVector::getAngleTo(other)
- RPolyline::getSegmentAt(i) where i points to a bulging segment
+ many other methods based on getAngle()
Each time something of the sort is used.

But applying RMath::getNormalizedAngle(a) each time to filter out a few rare
cases among hundred of thousands based on getAngle() is very time consuming.

If you can already like in the example case of the getSegmentAt(i) method.

Regards,
CVH

Andrew,

Probably not OS or QCAD version related.

Similar resources evaluate near 2Pi or over as zero.

    if (ret >= 2*M_PI - RS::AngleTolerance) {
        ret = 0.0;
    }

Other like getAngleDifference do not.
Then it is at least equal or over.

double RMath::getAngleDifference(double a1, double a2) {
    double ret;

    if (a1 >= a2) {
        a2 += 2*M_PI;
    }
    ret = a2 - a1;

    if (ret >= 2*M_PI) {
        ret = 0.0;
    }

    return ret;

In this forum topic I gave an example where:
- A slightly deformed bulge factor -0.4142135623730875
and not -0.4142135623730950 (-90°).

- So that the start angle becomes 1.5707963267948708
and not Pi/2 or 1.5707963267948966 as intended.

- So that ret = 6.2831853071795479
or only 3.85769e-14 (about 45 ULP) less than 2Pi

Returning an Arc length form start that is (almost) the full circumference of a circle.
While expecting zero because the point in question almost coincides with the begin.

Fine when you are merely using getAngleDifference() locally and can guard for that.
By comparing a position with an Arc ending based on RVector.equalsFuzzy()
But in the case at hand we use RPolyline.getDistancesFromStart() extensively.
The flaw can only be circumvented by replacing this resource in JS code.

The typical solution for our problem is using the first returned distance for cropping ...
... Disregarding the other returned distances ...
... If we can rely on that the first is equally valid as the rest ...
The example proves otherwise.

Next hurdle are more than two distances from the start of a Polyline.

Regards,
CVH

Andrew,

Tested on 3.27.6 Win7 32bit msi, replicated on 3.32.4 (trial), probably OS independent.

A bit similar as linetypes before ... ( FS#2622 )

It seems that the list of patterns in the Hatching dialog is based on whether the document unit is considered to be metric or imperial.
Disregarding this is ambiguous for RS::Microinch (FS#2541) but that unit is probably best handled as 10-based like all metric units.

We would expect that the list is according the document measurement system.
It is not: Current implementation is whether doc unit isMetric or not.

But there is more to it:
With a custom pattern installed in the metric folder,
with a new empty document in mm, with the measurement system set to imperial,
the (metric) pattern is listed in the pattern drop-down list of the hatching dialog.

The preview is empty and the resulting patterning is also empty.

However, on saving such a file and after reloading, the patterning is shown as intended.
Pattern type is ‘from entity’ ...
... And can thus not be used for creating a new Hatch with that pattern.
Except new blank ones ...

Somewhere down the line the pattern is correctly sourced from the
RPatternListImperial resource list and stored in the DXF.

Background:
For a ready to donate Zig-Zag pocketing Add-On I need an available, measurement system / unit independent and immutable custom pattern.
Exploiting the QCAD hatching engine to do a lot of the work.

But it seems I can not generate a virtual custom RPattern (Q 11971).
Nor construct one from RPatternLine objects.

I must thus rely on an installed pattern file.
Identical for both systems but also mutable and removable ...
... The problem is retrieving that with 100% certainty or the Add-On can’t pocket.

Regards,
CVH

Andrew,

In an attempt to create the ellipses with a NaN length mentioned in  FS#2693 .
The toString() text of an REllipse states start- and endAngle.
That are in fact the start- and endParameter.

One can alter the Start and End Parameter properties of an ellipse entity when selected.
But one can not alter the Start and End Angle properties.

In such a case these properties would be grayed, disabled like the Length property.

On the other hand:
Changing Start and End Angle properties could be supported.
For an REllipse we can set these:
- REllipse::setStartAngle(a)
- REllipse::setEndAngle(a)

Regards,
CVH

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 upper right ellipse in magenta indicating the segments near (13.55, 3.90) or near (13.457, 3.83).

ShapeAlgorithms.getIntersectingShapes() locates 6 intersecting shapes ...
... That is not the issue here.

But 2 of those lines return no intersection points with the ellipse.
Then ShapeAlgorithms.autoSplit() for the given positions removes both segments combined as one segment.

Line (13.4954, 3.8817)-(11.7277, 2.8611) should be considered as a tangent line.
Similar as being tangent to the lower left ellipse in magenta

The calculated discriminant of the quadratic equation is -6.927791673660759e-12
Negative and then there are no real roots to solve for a position of intersection.

The line passes only at about 1.0097e-13 units outside the ellipse.

The same occurs when indicating the segments near (13.79, 3.51) or near (13.68, 3.44).
Line (13.7454, 3.4487)-(11.9777, 2.4281) is also nearly a tangent line.
Here the discriminant results in -6.927791673660814e-12

Note that in this case the two tangents in question are almost vertical when transformed into the ellipse’s local coordinate system. dx is almost nothing after transforming.
→ Best handled as a special case. Equations may choke.
Also best practice for near horizontal tangents.

But this doesn’t solves the nearly a tangent outside an ellipse condition for all cases.

Increasing discEps is not a solution because:
!! We cannot quantify “almost a tangent” by the degree to which the discriminant of the quadratic equation differs from zero !!
That is a fix for accumulated errors in Floating Point.
Where the result should be plus zero and not at the negative side of zero.

Knowing that transforming to localize already introduces minor errors.
Even rotating by zero rads does alter things (FS#2635)

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