anti-art / auto-node-types Goto Github PK

Even if it was clearly smooth.

Cause: Cubicsuperpath breaks it into two points with one 0,0 handle.

Solution: Maybe special case that takes vec_a from first point, vec_b from last...

If n paths are selected, n copies of the full debug string will be written.

Try

• change indents/loops, maybe it's just in the wrong loop
• Else: Output some Markers to see where the repeat happens
• Then: Make sure it's just the string and not the entire code that is repeated...
• Maybe don't append to a long string, but instead use single sys.stderr.writes...

In this testcase the path was ([x] = tested, not the problem):

• combined (two holes) - Union of two paths introduced the transform-attrib
• had no nodetypes data before running
• had svg attribute transform scale(0.2)

Theory:
May be Inkscape bug? 🐛 🐞 🤷‍♀️
The node.set() pretty clearly just touches sodipodi:nodetypes.
The transform attribute is always deleted no matter if I try to change the "sodipodi:nodetypes", the "id" or if I node.set("wtf", "idk"). Or if I change NOTHING AT ALL 😱

On the other hand: No other extension removes the transform-attrib...

Idea:

Instead of just changing the sodipodi:nodetypes the plugin could also correct the path data to use S, s (or T, t).

Note:

It's not really supported by Inkscape. Manually entered S-Data is instantly turned into C/c...
...and it's not even changing to "s" or "z" in the :nodetypes string! 😞
Idea postponed for now.

Example path d:

M 0,0 C 1,0 10,5 10,10 S 20,15 20,20 ==> M 0,0 C 1,0 10,5 10,10 C 10,15 20,15 20,20

sodipodi:nodetypes is one long string, put cubicsuperpath splits path data into subpaths (and messes up the endpoints...).
This complicates #1 considerably.
There needs to be a better way to iterate. Maybe collect all data into list/s first, clean up endpoints, then run the node type recognition...

Note:

sodipodi:nodetypes is completely unreliable? It may be missing completely or is not updated. Inkscape recalulates it when touching a handle... May be best to completely ignore it and generate a new one.

Optional:

Make it forward compatible in case the cubicsuperpath is changed in the future to omit the added 0,0-handle node at the end. The additional node at the end comes from "Z" close in svg-d...

Sample Path with subpath:

M 0,0 C 5,0 20,10 20,20 C 20,23 0,7 0,5 Z M 10,9 C 10,8 12,7 12,11 C 12,15 10,13 10,13