It has been noted/discussed in at least two other threads that shaping operations (Weld, Trim, Boundary, etc.) can sometime produce content that will initially have correct geometry, but that can unexpectedly become distorted when some types of node editing operations are performed.
Annoying bug when working with curvers!
Nodes convert on weld, objects distort when nodes moved
My observations are that this has to do with nodes that were Symmetrical nodes before the shaping operation, but should have been changed to Smooth nodes as a result of the shaping operation. These nodes cannot be Symmetrical and produce the correct geometry, but they are still identified as being Symmetrical. Note in this screenshot that the node is identified as being Symmetrical, but the control points are not equal distances away from the node (as they should be if a node is Symmetrical).
If certain node editing operations are performed, such nodes appear to "wake up" and assert their Symmetrical identity - which distorts the geometry.One way to work around this is to perform the shaping operation, then manually find every such node and change it from Symmetrical to Smooth. Depending on the complexity of the shape, that might be very tedious.As a less-tedious workaround, here is a VBA macro I wrote that checks each node in a Curve that is identified as Symmetrical. If the control points are not equal distances from the node, then that node is considered to be a "bogus" Symmetrical node, and is changed to Smooth.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
Option Explicit Sub fix_bogus_symmetrical_nodes() Dim sr As ShapeRange Dim s As Shape Dim nodeThis As Node Const dblLengthToleranceTenthMicrons As Double = 50 Dim lngNodesChangedCounter As Long Const strMacroName As String = "Fix Bogus Symmetrical Nodes" On Error GoTo ErrHandler EventsEnabled = False Optimization = True ActiveDocument.BeginCommandGroup "Fix Bogus Symmetrical Nodes" Set sr = ActiveSelectionRange If sr.Count = 1 Then If sr(1).Type = cdrCurveShape Then Set s = sr(1) For Each nodeThis In s.Curve.Nodes If nodeThis.Type = cdrSymmetricalNode Then If Abs(nodeThis.PrevSegment.EndingControlPointLength - nodeThis.NextSegment.StartingControlPointLength) > ActiveDocument.ToUnits(dblLengthToleranceTenthMicrons, cdrTenthMicron) Then nodeThis.Type = cdrSmoothNode lngNodesChangedCounter = lngNodesChangedCounter + 1 End If End If Next nodeThis MsgBox "Number of nodes changed: " & lngNodesChangedCounter, vbInformation, strMacroName Else MsgBox "Selection is not a Curve.", vbInformation, strMacroName End If Else MsgBox "Exactly one Curve shape must be selected.", vbInformation, strMacroName End If ExitSub: ActiveDocument.EndCommandGroup Optimization = False EventsEnabled = True Exit Sub ErrHandler: MsgBox "Error occured: " & Err.Description Resume ExitSub End Sub
That same code is in the .GMS file in this.ZIP archive:
JQ_Fix_Bogus_Symmetrical_Nodes - GMS in ZIP
Here is a short video showing an example of a situation where this bug shows up, and how changing those "bogus" Symmetrical nodes to Smooth can be used to correct the problem:
VIDEO: Fix Bogus Symmetrical Nodes
.
Thank you for taking the time to investigate this issue John, and write a macro to correct these "bogus nodes".Even though I appreciate your efforts, having to use a macro to make sure all nodes are correct is not a solution.What we must do now is to make sure the Corel techs do all they can to correct this very serious bug for version 2019.I am afraid though, that the bad code is spread across a number of different operations and it won't be an easy fix.
Ronny Axelsson said:Even though I appreciate your efforts, having to use a macro to make sure all nodes are correct is not a solution.
I agree that this is not a solution. It's a workaround.
Corel's own code should be correctly keeping track of the cusp/smooth/symmetrical properties of nodes when shaping operations are performed, and not generating "bogus" symmetrical nodes.
I started this thread to (1) increase awareness of the problem and (2) help those users who could benefit from having a workaround available. The two other threads I've seen on this topic now have links pointing to this thread.
Ronny Axelsson said:What we must do now is to make sure the Corel techs do all they can to correct this very serious bug for version 2019.
Do you have any ideas on how to accomplish that?
I think it would require that Corel management be willing to assign resources to fix these types of issues. Perhaps they think it is better, from the standpoint of making money, to leave these things broken. I don't like thinking about that as a possibility, but there it is.
Ronny Axelsson said:I am afraid though, that the bad code is spread across a number of different operations and it won't be an easy fix.
It depends on how their code is structured. It's possible to have a problem show up in a number of places in a program because the same not-quite-right code is being referenced in all of those places. Find and fix that one not-quite-right section of code, and it all gets better.
A real solution would involve one or more Corel developers who know how the program works "down in its bones".
Eskimo said:Do you have any ideas on how to accomplish that?
Serious threats by mail perhaps.
In an earlier version of my text, I was going to ask if you had any ideas on how to legally accomplish that.
As in, how to accomplish that without breaking any laws...