Bezigon Tool

[Daniel]

@larsherold: You don't need to this anymore. Thankfully. You can create a portable version of FreeHand. It is extremely simple. Install FreeHand using Sandboxie within a Sandboxed location. Now you have a copy that has zero dependency on Windows registries. You can copy the contents and use it anywhere!

[Daniel]

@VectorStyler: I sent you both the installer and keys in DM a while ago. I also have a portable version. So I can send that if you want.

[larsherold]

@Daniel said in Bezigon Tool:

Install FreeHand using Sandboxie within a Sandboxed locatio...

Ah, interesting. I have very little experience with sandboxing, virtualization and so on. I do have FreeHand running on an M2 Mac in Windows via Parallels, but I guess it's a different creature.
I still find the native installation on Win is well behaved - and completely legit, as I have the original installation media and valid license card from back then...

Still many basic features in this 2005 application that work so well, Illustrator doesn't come close now 20 years later, Bezigon as a case in point!

[Daniel]

@larsherold: Yes, FH is still to be bested. This is because FreeHand is an outgrowth of intensely vector focused software: Altsys' Fontographer. Released 30 years ago, it is what introduced Bezigon. Building FH on top of Fontographer engine gave them extraordinary power. Adobe sucks compared to it.

Virtualisation is easier than people think. Sandboxie is a shareware. You simply need to start it, and then run the installation inside a sandbox. Now the contents inside the sandbox are completely isolated - this means that they're device independent. Hence completely portable. There are many tutorials out there on this if you want to try. I do it this way because it means that should I change my computer in the future, and some Windows update breaks FreeHand, then I have a portable edition that I don't have to install.

[Daniel]

@vectorstyler: We thought a bit more about this. There is actually a far more elegant solution to this problem of tangent nodes than introducing a separate node type. It is simple. All you need is a tool setting option that says: "Snap" or "Lock Handle to Chords" - that's it! Now you have a tangent node.

With the node tool active, you click on a node, and then toggle on "Lock Handles to Chords" - the handle of that node is now locked to the chord of adjacent nodes. Chord being the straight line between two nodes.

This might be far simpler than introducing a third node type. What do you think folks? @larsherold?

Fuck! The more I think about this, the more delightful it is - it is so, so simple!

[VectorStyler]

@Daniel I'm confused about case (13) of the Four Nodes section of the "Bezigon - Permutations - Corner, Smooth and Cusp.pdf"

In this case the sequence is MC, PC, MC, PC, MC. Which should result in a smooth closing node (starts and ends with a smooth node).
Could it be that the sequence is wrong?

[Daniel]

@VectorStyler: No, The sequence produces the correct result. The reason is simple: The first click is modified twice. Once when it was place and the second time when when it was closed. And node 2 and node 4 are both sharp nodes, hence the top node becomes a cusp node with the handles of both pointing at the chord.

If all the nodes are smooth, including the closing click, the top node still is cusp and the handles are still on the chord to node 2 and 4. This is because node 1 was modified twice, once when placed and once when closed.

Consider this: The first node is placed as a square node, but all the others are modifier clicked. It still correctly produces a cusp at the top. The segment between node 1 and 2 on the left is approximated to a circle, as it should be. The segment between 1 and 4 on the right is cusped, and the handle points at node 4, the chord to node 4.

[Daniel]

@vectorstyler: I discussed it with Taras, my colleague. I think you should hold on the implementation of Tangent node. He agrees with me that it is just a matter of introducing a single new flag for each of the existing nodes rather than introducing a whole new node type. It is far more elegant, far simpler. Meanwhile, you can just work on getting the two main node types right. Sharp (&Cusp) and Smooth (&Symmetric).

[larsherold]

@Daniel said in Bezigon Tool:

This might be far simpler than introducing a third node type. What do you think folks? @larsherold?

It makes sense, as I guess the FH tangent Connector point can be viewed as a special case of a Cusp or Smooth Node.

But the Connector Node is only useful/sensible as a tangent constraint if the neighbouring segment is straight. So when you "lock the handle of a smooth node e.g. to the chord" to enforce tangency, you will have to decide which handle to lock and staighten up the segment by retracting the handle downstream. (Or lock the downstream handle to the chord as well.)

Actually the FH Connector node has two handles as well. The hidden handle can be extracted by Alt-dragging from the triangular node.
Only, the second handle direction is locked, and seems arbitrary, like it has an undefined value when hidden.

The FH Connector node can be forced to expose its second handle when placing it, resulting in a sort of direction-frozen Cusp node.
Use the FH Bezigon tool to place 3 nodes: 1 smooth, 1 connector, 1smooth:

The middle point is a Connector node alright, but not much tangency going on.

The "stray" outgoing handle can be retracted, and the Connector node behaves like a tangent node again...

BR/ Lars Herold

[Daniel]

@larsherold: Yes, all of these can be reproduced with a simple flag for each of the two types of nodes. Including the two handled connector node. Thankfully, because we have mapped out every single rule, writing it back into the simple two node scheme is easy. Thank you for confirming this!

Technically, and ideally, a tangent node is only every useful if it follows one direction. We can force this in the tool setting, but I'd rather not. FreeHand allows you the choice to have both handles available which you can manually collapse. I prefer that freedom.

[larsherold]

@Daniel said in Bezigon Tool:

FreeHand allows you the choice to have both handles available

You are right, the direction of the second (rarely seen) Connector handle is not arbitrary at all. Both visible Connector handles lie on the chord extension towards each neighbour node! Makes sense. You can retract either, and depending on what segment is (made) straight, you have tangency in one direction or the other..

There would have to be some visible indication that a handle is locked to a chord, and a means of unlocking it, I guess.

[Daniel]

@vectorstyler

So the ideal way to proceed with this so that we can test it one step at a time is this:

--> Fix bezigon rules for smooth and cusp as it currently exists in VS.
--> Introduce flags for tangent nodes so that the handle is locked to chord and aligns to the chords of neighbouring nodes. --> Release --> Test --> Fix.
--> Introduce true circle option from TikZ Lib --> Release -->Test --> Fix.
--> Introduce handle clamps from Blender --> Release --> Test --> Fix

You get this right, you'll have outright the single best pen tool option in the market.

[Daniel]

@larsherold: Yup, figuring this out has been notoriously difficult. It is right under your nose and extremely simple once you see it. So is the 0.39 X Segment = Handle Length. Already worked out by several others. But putting these two pieces together has taken so long. More intelligent people would have seen it right away.

[Daniel]

@larsherold: Yes. We can simply turn it into a triangle! Just like in FreeHand. Except it's just a locked node!

[larsherold]

Re: ”More intelligent people would have seen it right away”.
All due respect - I think the level of bezier-intelligence is maxed out in this neighbourhood..
Impressive dedication to the Bezigon implementation!

[Daniel]

said in Bezigon Tool:

Just to add to this: We managed to test our algorithm further and we're extremely happy to say: We're off from FreeHand's at most by 0.008%, and typically about 0.005%, of each handle’s length. That is, 1 part in 13,000–20,000. The direction difference is effectively zero, at most 0.0003°. So that is a level of accuracy that you thankfully do not need to reproduce painfully. Please have a look at our algorithms! Thank you!

Do you recall this comment? Well, now that I have decompiled and looked at the code. I can tell you exactly why it is 0.008% deviation from FreeHand output. Because FreeHand uses the constant of 0.3899994: 16.16 fixed-point, 1.6 millionths below 0.39.

Now you know that mine is indeed a clean-room RE and not a decompiled bullshit. Besides, there are other exceptions and edges cases that I have accounted for that I couldn't get in the decompiled code. Those are all accounted for in mine. Finally, I have also made the whole function much more intuitive by allowing handles to remember their lengths after conversions from node types - something FH does not do.

[VectorStyler]

@Daniel Got it.

[Daniel]

@VectorStyler: Just an update; Over the weekend, we managed to figure out how to set per node flag and lock the nodes: It works beautifully and reproduces the tangent node behaviour within the two node scheme that we now have in VS. You'll see the little blue lock under the node. That's the node locked to chord!

You'll also notice the clamping function, true-circle approximation as well as ghost lines for comparison. We managed to simplify the APIs, cut down the entire library by about 30% in length.

We did use AI to run tests (as before) and tests produce FreeHand's results across millions of random paths.

I'll document everything thoroughly and do a handover. After this, it's entirely up to you how you wish to implement it. But I've handed you all the pieces you need.

[signalwerk]

@Daniel Thank you for all your work and the effort you put into reverse engineering this. That’s really awesome! I was very interested in its behaviour and what it feels like to work with, so I used Claude AI to create a small playground with your code. You can find it here.

You mentioned a new revision of the code, and I would be very interested in incorporating that as well. Would we be able to get it somewhere?

Since your code has already made its way into discussions in PhotoLine and Inkscape, I think it would be great to have a central place to get the latest version. I would love to see the code on GitHub, a platform for version control, so we can all access it there and know where to find the latest original source.

[Daniel]

@signalwerk: Thanks! Since I released that code, the code has gone through a huge churn cycle. We had to strip and rebuild. Not because the logic is wrong. It is perfectly usable. But because we had a new idea. Tangent node is really not a separate node, but a cusp node with handle locked to chord. The idea is as simple as it is obvious. The implementation however is a whole new monster. Because, now you have to figure out how is this lock going to work.

We use De Casteljau algorithm to preserve shape when inserting new node on existing shapes. But then locking is a unique case. So we had work out every single on of these cases manually. By hand. FreeHand is of no use here. Because FreeHand does not preserve shape. It brutally applies a tangent node with both handles instantly available. That is not intuitive or even purposeful. So after 10 further iterations of back and forth, we discovered the solution. It is simple too:

Locked node ALWAYS gives precedence to a sharp node's chord when a smooth neighbour is present. Where both neighbours are either square or locked or combination of the two, the locked node in between them has no handle automatically. If a manual handle is draw out, this gets preserved in subsequent operations.

This is our labour of love and addition to 40 year old Bezigon algorithm.

However, there's something even more interesting we've done.

We built a drag gesture layer which allows you to drag nodes, handles and segments using modifiers. Alt to break, Ctrl to unite. This will become obvious when people actually try it. These gestures are actually native to PL. We built it for the benefit of PL devs who have to integrate it into the program. So we wanted to show them how Bezigon can sit perfectly alongside their existing gestures model.

But then, we realised that in the process of doing this, we had created a dependancy! FUCK!

Now anyone who wanted to implement in must also implement these gestures. So another round: We created two layers. Geometry layer. Drag gesture layer. Completely separate as headers and algorithms. You can strip out gestures without losing a thing.

https://drive.google.com/file/d/1BDM-JtO3t5E3_iCCTFpNOw5Xa4DwZwM-/view?usp=sharing - Here's the new demo file. You can download, play and enjoy. You will get a warning on Windows. No digital signature. Ignore it. It's safe. PRESS D to see the handles. Forgot to add. K for clamp. C/S/L for toggling between Cusp, Smooth and Locked. G for Ghost Lines. O for True Circle. R for reset to Bezigon Handles. Ctrl + Z/Y for Undo/Redo. Esc to Clear Canvas. Enter or Alt Click to finish drawing curve.

We've also included Clamp, True Circle and Ghost Lines as options. Clamping exists for extremely close nodes which have enormous handles. Clamp makes sure that the length of the handle is not greater than either 2 or 5 times greater than distance between the nodes. True circles is basically a subset of Bezigon. It overrides Bezigon and approximates true circles like Spiro Path does.

So you have enormous flexibility built directly into the algorithm, which I hope @vectorstyler implements as options for bezigon.

Final note: EGE, the Open Source engine that we used before was not sufficient. So we rewrote the demo in Raylib. Well, my colleague did.

It works wonderfully. And we also took AI's help (GLM this time) to write an exhaustive test suite. Covering millions of paths. And we compared this with FreeHand.

The deviation is 0.0008%. Because FH uses 0.3899994 as the approximating constant.

At this point, my autistic, perfectionistic streak is completely satisfied. Please give me a kiss (applause) of appreciation. I am tired now. I've gotten this monkey off my back. Thank you!

I'll share the full code base after documentation is done. There's a lot to rewrite.