Calligraphy tool must remove hole subpaths

Bug #184550 reported by Martin Andersen on 2008-01-20
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Wishlist
Unassigned

Bug Description

I'm sure this is a known issues, but since I can't find a match, here it is for the record:

The Calligraphy Tool creates artefacts when a stroke changes direction sharply, creating overlapping shapes and holes in the line.
It should perform a Union on the completed stroke, and remove any subsequent subpaths which create the holes (equivalent to Break apart and removing the subpath). Doing so manually when inking a drawing is unnecessarily tedious, as there may be many dozen lines to clean up.
Additionally, a special Simplify should be performed on the finished path, reducing the number of points without altering the shape. Currently, due to the excessive number of nodes, the only practical solution to an inked drawing is to import it into Illustrator just to use its Simplify command, which is far more flexible and can substantially reduce the number of nodes without damaging the drawing (one Inkscape drawing I did was reduced from 5.5Mb to less than 500kb as a result). Inkscape's Simplify damages the drawing, even in current Developer builds.

In short:
Once a stroke is completed, Inkscape should do 3 things:
1. Perform a Union on the path to remove loops and overlaps where the stroke has changed direction.
2. Remove resultant subpaths creating holes in the stroke.
3. Perform a special Simplify, NOT like the default Simplify, but one which reduces the excessive number of Nodes without altering the shape substantially.

Martin Andersen (msandersen) wrote :
Martin Andersen (msandersen) wrote :
Martin Andersen (msandersen) wrote :

I'd already performed a Union an cleanup on one of the paths in the above SVG, so here it is again:

bbyak (buliabyak) wrote :

there's no "different simplify" - it just varies by force. Try reducing the default force of Simplify in Inkscape Preferences.

Martin Andersen (msandersen) wrote :

I think you're missing the point, the calligraphy tool by its nature produce far too many nodes, somewhat dependent on the speed of the stroke, and the strokes need a drastic reduction of nodes after the fact, and that shouldn't be up to the user except perhaps to a preference setting for the Calligraphy tool as to the Force, as you say, it is applied. However the default setting of Simplify messes with the integrity of the shape, whereas illustrator can tweak the Accuracy of the path. But deficiencies in the Simplify tool is not the crux of the report. I'm just saying in point 3 above that a higher accuracy Simplify should be applied automatically to the stroke when it is done, one that doesn't mess up corners or alters overall shape. I'm sure this can be achieved programmatically with the current Simplify routine using different parameters, for which there are no GUI controls.
As a side note, I cannot find this preference you speak of in the Windows build (either the Stable 0.45.1 or development builds).

Ryan Lerch (ryanlerch) on 2008-01-21
Changed in inkscape:
importance: Undecided → Wishlist
status: New → Incomplete
bbyak (buliabyak) wrote :

inkscape prefs > misc > simplification threshold

i'm not saying this closes your report. i'm just pointing out that you can simplify softer if you want.

the current parameters of the calligraphy tool have been very extensively tweaked to provide natural-looking results, exactly preserving even the very fast movements of the pen. this is a must for freehand artistic drawing for which this tool is designed. muffled, melted and oversimplified strokes are no fun. we intentionally chose precision over saving a few bytes, and personally i don't think the tool produces too many nodes. imho, just enough for the kind of shapes it creates.

for the rest of your requests on removing subpaths, this makes sense.

Changed in inkscape:
status: Incomplete → Confirmed
Martin Andersen (msandersen) wrote :

Thanks for the info.
To be honest, I added the 3rd point as an afterthought, as it is not the core of the report, I just thought it best to merge the issues. The main point is to remove the overlapping paths and resultant subpaths, or holes. Without the latter, though, I'd still either have to use Simplify and meticulously go over every path to fix them, or import the drawing into Illustrator and fix it there with its more flexible command.

For a lot of things, the current Simplify setting is just fine, but for cleaning up lineart, the needs are a little different. I found in inking a complex drawing, where I attempted to imitate my hand inking (with physical brush and ink), that Inkscape became increasingly bogged down as the filesize increased with the massive amount of nodes. As mentioned above, I imported it into illustrator to try and reduce the number of nodes without overly affecting the shape of the brushstrokes. There were over 84,000 nodes with a filesize of 5.7Mb, with the nodes packed tight. I reduced it to around 13,000 nodes with a filesize about 500kb with no significant damage to the drawing (I don't know if there's a way to get statistics in inkscape, but Object Properties would be a good place for it. But that's another matter).
It occurred to me that it depends on the speed of the stroke, a very fast stroke has a reasonable amount of nodes, whereas a slow careful one is ridiculously tightly packed, so it seems to me that a "cleanup" needs to be performed on the conclusion of a stroke, both for the removal of the overlaps and holes, and for reducing the complexity where needed.
I've attached an example from the abovementioned drawing, where the single line shown had 495 nodes, ridiculously high you must admit, and after simplification in illustrator, it had only 37. That's 7% the number of nodes. Given, that's with tweaking of the controls in illustrator's Simplify command.
Improved control over the simplify command could also help, but bug#170152 which requests this has been marked Invalid. I made a comment there, but it seems it won't be taken seriously.

Please tell me if you think it best to split this into a separate report, as it seems you are more willing to do the former, and less the latter.

bbyak (buliabyak) wrote :

i see what you mean - it cam indeed create that many nodes if you draw very very slowly. but that's not typical use of the tool - most users draw much faster, and the tool is optimized for that. also i tried reducing inkscape prefs > misc > simplification threshold to 0.005 and simplifying a long stroke with 1000 nodes, and it reduced nodes a lot almost without changing the shape. so you don't have to use illustrator for that at all.

note that simplification can accelerate as described here:

http://inkscape.org/doc/advanced/tutorial-advanced.html

so even with a low threshold you can get strong simplification by hitting ctrl+l repeatedly, if you need it.

Martin Andersen (msandersen) wrote :

I'll play with the threshold prefs, they are a little hidden away hence i missed them. I don't know what the number means, but 0.0010 seems a good number for the stroke illustrated. Also applied to the whole drawing, though extremely slow on my dual-core AMD64, the results seem ok, though the strokes have changed shape somewhat, with a bit of fixing needed perhaps. I'd have to test some more. It brought the filesize down from 5.7Mb to 1Mb, at least. I still think a slider with the simplify command controlling this parameter is needed. Hunting down the Preferences every time you have a different requirement continually until you get a good result for the particular drawing or stroke gets old quick. Illustrator's Accuracy slider is far better. I might file a new report despite it seeming to be a duplicate of bug#170152 .
As for drawing speed, I'm talking average careful tracing of an image with a Wacom tablet. A stroke is best done reasonably quickly I find, with a hand on Ctrl-Z until I get a "spontaneous" line I like. I'm not talking particularly slow. In any case, the point is it should be possible to apply some sort of test on the conclusion of a stroke to see if it is partiicularly complex, and do a simplify with a custom setting as you mention, automatically. If the stroke is quick with few nodes, it may not need to act. With the density mentioned above, the extra nodes adds nothing to the drawing.
I did play with repeating or holding down Ctrl-L. Quite fun to watch.
I haven't seen this tutorial before, I've only read some of the "official" manual pointed to in Help. It indicates the amount of simplification is relative to the size of the selection, which complicates things further. This would explain why the test above worked best on the single stroke, and a bit too strong on the whole, Hence simplification as the strokes are being made as needed might still be advantageous.

The attachment shows the difference on the drawing of a threshold of 0.001 on the stroke alone, and the whole drawing. The former maintains the shape, the latter is oversimplified, but fixable.

bbyak (buliabyak) wrote :

you're not really supposed to change the threshold all the time. you're supposed to set it to the lowest useful value, and then use repeated ctrl+l if you need stronger simplification.

i agree that the dependency of simplification force on object size is not perfect. yet i think you will agree that in general, such dependency is necessary. it's just that we need a better and more meaningful way to determine the size of the object for that purpose, taking into account the compactness of the shape. for example a long but narrow calligraphic stroke must use the same force as a short stroke of the same length; on the other hand, a big round lump needs stronger force than a small lump. it's an interesting mathematical problem to develop a measure of size for the purposes of simplifying that would always make visual sense.

David Császár (p5) wrote :

see bug 171676 for a way to easily reproduce this problem

su_v (suv-lp) on 2013-01-14
tags: added: calligraphy
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers