I was adding a feature request for non symmetrical scaling with reference and target point.
In some cases it was enoying that the 'reference' do not end up at the 'target'.
But that failed. Error: 'wrongtoken'.
A good thing because more insights came later.

Documenting this I found out that polylines with arcs don't scale properly.
A non symmetrical scaled arc is an ellipse. I enterred a bug report.
Andrew dismissed this because polylines don't support ellipses.
so I ran into the limmits of dxf/dwg.

As a fact I fought this one before.
Ever tried to design an oval rim to use with G-code? There is only one good way.
A central oval, two offsets that are splines, exploding to polys with tangentially conneted arcs, exploding to arcs.
None of the final paths are ellipses but they look like one, are concentric and have a fixed distance.

But is there no beter way to scale polylines with arcs? I asked myself.
And there are much better ways than keeping the bulge factor constant.
Pitty for all those polys I scaled before.

file included <Scaling Poly-arcs.dxf> (zoom in on the details)
I started with a spline with fitpoints as base for a fluent polyline with arcs.
This spline (yellow) has no line segments so I divided it in 3 parts and inserted 2 line segments (blue). (upper leftmost in the file)
Splitting the spline changed it into a splines with control points. (Expected behavior by Andrew)
From that I copied it to a polyline (orange) and as a string of arc segments (magenta).

The fitting of these three is quite good. Obvious the two latter fit perfectly.
(I have to mention that exploding the spline fails the demanded approximation tolerance set at 0.1 whatever)
This can not be said for the non symmetrical scaled versions at the right.
As I use the segment string as reference because here the arcs are properly scaled to ellipses (also magenta).
The scaled spline is by about the same amount off as the non scaled.
The scaled polyline is much more off and has bulging and kinks.

I also scaled the sagitta (cyan) and found that a three point arc (cyan) fit does the trick far better.
Using start and end point and the end point of the scaled sagitta.
A last enhancement would be scaling the tangent (dark cyan) and again use a three point arc (dark green).
Using the intersection of the scaled tangent and a line perpendicular to the midpoint between start and end point.
(also the new sagitta for the arc with equal bulge)
These two methods can be translated to a mathemathically relation to define a new bulge for the arc in question.
Although a pretty computal effort, I rather wait a few seconds than continue with bulging an kinky polys.

I chose the rounded corner for the error-math because I asume it is one of the worst cases in this example.
Rigoureus testing can only be done with a test function because the graphical work involved is very time consuming.
The numbers are the integrated surfaces of the deviations.
The tangent method is far out the best. The present method far out the worst.

When an arc sits between two non colinear line segments it can also be treated as a rounding.
in this case one could scale the rounding or use the tangent for a rounding and trim the lines to it.
For the first the error is larger as the best match but can be even smaller then the present method for scaling polys.
The same would be possible for arcs that connect at one line segment. I did not investigate it.

At the far right the different sagittas for the three arcs in detail are blown up to see the inpact of the constant bulging.
With X ratio over Y ratio of 0.5/1 the error can easely be twice that what would be expected and much more.

My conclusions are:
Splines are not replaced by Polys within the approximation tolerance.
Non symmetrical scaling is best not done for Polys with arcs or Splines.
Non symmetrical scaling of Polys with arcs with keeping the bulge for arcs is faulty.
Altough never perfect, the tangent method is a far better approximation for scaling fluent Polys with arcs.
The only exact way is to explode them into a string of segments an work with blocks.
This has a huge impact on using functions or modifcations on them.

So the way to 'reference' skewing is far more complicated as expected.

And I have other feature requests pending.
Like flawless offsetting a buch of curved lines.
Like simplifying curved lines.
Like median line between two curved lines.

I grew to be fond of the QCAD way and the UI and renew my contribution every year.
In fact, I am awaiting the CAM part to exits its puberty.

I finished the math, but still have issues with signs because some fall off by squaring and/or square-routings
For testing I am copying and pasting the polylines properties manually one by one.
For this enoying task I commented FS#1555 a while ago.
I did this for the CXF fonts too, remember?

Can this script include the bulge property too? How?
What Is the reason why the polyline is first set to clockwise? I need the datapoints as they are, CW or CCW.
Would it not be simplier to check the Orientation property for that? Or is that not a property?

I would allready be happy with the export.
For importing we need a whole new script or function.
Manually setting only all the bulge factors is something I would not mind for now.

Kind regards

Edit: found it myself, took a while to get the syntax correct
for (var k=0; k<n; k++) {
var v = entity.getVertexAt(k);
var w = entity.getBulgeAt(k);
EAction.handleUserMessage("%1,%2,%3,".arg(v.x).arg(-v.y).arg(w));
}

Last edited by CVH on Mon May 14, 2018 3:18 pm, edited 1 time in total.

I am trying hard but I feel lost in the woods.
I wander in the EMCA script reference and the QCAD project reference for days now.

In the above script: ( Please interrupt me where I fail )
var v = entity.getVertexAt(k) will set the variable v to a RVector
var w = entity.getBulgeAt(k) will set the variable w to a double
EAction.handleUserMessage will put the arguments formatted as CSV by the format "%1,%2,%3,"
The arguments 1-3 are {v.x ; -v.y ; w} and as far as I can find 3 doubles.
Q: why x from RVector and y from minus RVector? Why .arg(-v.y)?

The value of the bulge [=entity.getBulgeAt(k)] is passed through to the command line history with 8 decimal places (= ok).
The value of x (=RVector.x) is passed through with only 2 decimal places(= nok, need at least 6).
Q: why only 2 decimal places?
The value of y (=-RVector.y) is passed through with only 3 decimal places(= nok, need at least 6).
Q: why only 3 decimal places?
Q: why different number of decimal places for x and y?

Chekking some point manually it is found that some data for x and y is rounded to 2/3 digits, some is truncated.

Q: how do I get at least 6 decimal places rounded to the 6th digit.

I thought scaling my polys with factor 10,000 and do the math 10,000 times smaller would serve me.
Placing the left lower point of the poly on the origin I found something most peculiar.
My left lower vertex printed as -1.74185e-07,1.49883e-07,0.292587,
a) not the origin...... but almost
b) not 0.00,0.000, ...
c) x and y with 5 decimal places in engineering notation

To be comlete: AppPrefs/DimSets/Precisions: Linear 6 ; Angle 3

Regards
(Copying this post to notepad before submitting. So I can try to send it 3 times like usually)

Last edited by CVH on Mon Sep 09, 2019 9:16 am, edited 3 times in total.

The scripts in Misc > Examples are not meant for production use but are various examples that might or might not be useful. At one point I needed a script the dumps polylines for use in a pixel based coordinate system with the origin at the top left.

I'd recommend to create your own script based on that and make changes as needed.

CVH wrote:Q: why only 3 decimal places?
Q: why different number of decimal places for x and y?

JavaScript does that automatically when converting numbers to strings.

You might want to use numberToString to control decimals:
"%1".arg(numberToString(Math.PI, 12))