QCAD.org Forum

Greetings again.
My next question is a mixture of a few subjects already broached on my other posts.

I want to be able to reverse the printing direction of the entities I am working on.
I have attempted entity.reverse(); but the changes created by this particular function are not permanent even with the applyOperation().
To circumvent the problem I attempted to change the StartAngle, EndAngle, StartPoint and EndPoint of the entities.
I can do this without a hitch with lines, but arcs are proving a problem, for two reasons.
1st, because there doesn't seem to be a setStartPoint or a setEndPoint for arcs, though there is a getStartPoint and a getEndPoint. In alternative, I attempted to use the moveStartPoint and moveEndPoint but I am confronted with the following;

"Uncaught exception at scripts/IuSYS/FirstWidget/FirstWidget.js:116: TypeError: Result of expression 'entity.moveStartPoint' [undefined] is not a function."

2nd, because just changing the StartAngle and EndAngle will cause the arc to curve in the wrong direction. the function setReversed(); solves this but, again is not permanent even the ApplyOperation().

Any suggestions?

Thank you.

By 'not permanent', do you mean that the arc direction is reversed again (to be positive or counter-clockwise) after the file is saved and reloaded?

If so, that is a limitation of the DXF/DWG formats which always store arcs counter-clockwise.

Depending on the reason why the direction is important, there might be ways to potentially solve the problem. Can you elaborate on that?

Imagine that I want to make a drawing for 2d printing purposes.
I make a complex design (I say complex of something I don't want to redraw it if I can help it), I copy-paste it bit away but I determine that it is more efficient if that copy is printed in reverse.
If I save the dxf and import it to the printing program, the printer will make a jump to print the arc in the original direction, thus rendering my efforts to make it efficient into moot point.
My point is to simply give the user the power to manipulate order and direction of printing according to his own necessities.

Hope my explanation was sufficient.

Thank you very much, andrew.

Ghost_of_Magellan wrote:If I save the dxf and import it to the printing program, the printer will make a jump to print the arc in the original direction, thus rendering my efforts to make it efficient into moot point.

Your best option might be to convert arcs or connected paths into polylines. Arcs keep their direction if they are part of a polyline.

Thanks for the reply, andrew. A pity I can't use the same method, it would make my life that much easier.

I will try to find alternatives.

thank you once again.

If so, that is a limitation of the DXF/DWG formats which always store arcs counter-clockwise.

Thanks I just learned something or made it clear for me . "Reversed" only changes how Qcad displays the arc. The line type or Arc can never change direction around the centre. Makes sense really. Adding reversed line types if(reversed) to my CAM display solved the problem.

srl

Hi Andrew.
Further to the comments already on this thread, I was wondering if I could please ask your advice regarding a problem my local joinery is having with the way its router is interpreting arcs in a a number of DXF files I have sent them?
The files are my QCAD representation of paper plans for a wooden boat I'm hoping to build. Marine ply constitutes the bulk of material used. As a number of the elements are longer than a single length of standard ply, I decided to try to incorporate what are known as "puzzle joints" to provide a neat method of joining those sections together.
An early puzzle-joint test-cut proved to work very well. However, at a later date, when I submitted a number of files incorporating puzzle-joint edges, the joinery told me their software was interpreting a number of the curve elements incorrectly (as in it was seeing their properties as "reversed - yes" instead of "reversed - no" - or vice versa)... but in any event they were being interpreted as the opposite of what was intended and would have produced a number of curves with the incorrect shape.
The joinery prefers to accept only DXF files and their software is normally ok with "blocks", but not so much with "polylines" - especially splines (which have to be produces as a series of 3-point arcs if required). In this instance, however, their software didn't like the curves incorporated in the files utilising blocks either - ie. they would have been cut to the wrong shape - the shape that results when I change the reverse option from yes to no or vice versa...
This led me to a painstaking process of trying to ensure the consistency of arc direction as "reversed - no", but I discovered something interesting happen when I made certain groups of elements into blocks or polylines then "exploded" them. The exploded blocks seemed to retain the desired arc properties, but exploded polylines showed a mix of reversed - no and reversed - yes. It is the reversed - yes arcs that cause the issue when my files are interpreted by their machining software.
Could you possibly, please, offer some advice on what I may be able to do to ensure their software consistently interprets all of the elements of my drawings as intended?
I'm attaching a DXF file of one typical pair of male and female puzzle joints. (There are about 40 of these in different combinations and numbers across the various parts of the boat's drawings). When "assembled" there's a 0.6mm gap between the edges to permit the introduction of thickened epoxy glue.
I'd be grateful if you could please examine the properties of the curves initially, as well as after turning each of the composite shapes into separate blocks (and exploding them), then separate polylines (and exploding them) to see if you obtain the same results I described above.
Thanks very much, Andrew.
Cheers, Kim

Unfortunately, as mentioned above, the DXF format has no concept of reversed arcs (all arcs are CCW, i.e. not reversed).

QCAD maintains the arc direction through a custom property, thereby extending the DXF format.

Again, for the purpose or sending a file to a machine shop I would strongly recommend to use polylines. This not only ensures the arc directions are correct but also guarantees that connected segments are truly connected. If that is not supported by the target system, I cannot think of any way to transfer arcs without losing the intended direction. Perhaps the machine shop can tell you how they intend to handle this.

Creating a polyline will indeed reverse arcs as required, so creating a polyline and exploding it again might change the direction of some arcs (intended behavior). Creating a block and exploding it again should not change the direction of any arcs involved (I cannot reproduce any problem with that here).

Thank you Andrew.
Blocks, when exploded, faithfully reproduce the direction of the arcs as you say.
It's the polylines, when exploded, that (as you rightly suggest) can - and in this example, do - reverse the direction of the small arcs.
The joinery operator tells me that the DXF files go through 2 propriety software processes prior to cutting. Maybe one of those is doing the equivalent of exploding the polylines... I don't know - and neither does the joinery operator I'm afraid.
I've submitted a few different options to him including a more traditional dovetail arrangement, but arcs are still present so their result will likely be the same.
I wonder if I were to first create the polyline, then make it into a block, whether that may go through the joinery's proprietary software and give the intended result? (Clutching at straws here...)
Worst case, I'll forego the puzzle/dovetail joints and use an older (less neat) method.
In any event, I really do appreciate your response and input.
Thanks again!

Blocks will very likely make things harder, more complex and are less likely to be supported by the chain of tools used.

Ok. Thanks Andrew. Appreciate the advice.
Cheers, Kim