Optimizing some cubic beziers away
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Fix Released
|
Medium
|
jazzynico | ||
Scour |
Fix Released
|
Medium
|
Unassigned | ||
scour (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
When optimizing paths, scour discards commands which don’t advance the path, that is, which have a relative movement of 0,0. But this is wrong in the case of cubic beziers. For example, a path
<path d="m 100,100 c 10,0 0,10 0,0 z"/>
is a raindrop-like figure, but scour only looks at the last 0,0, decides the "c" command to be superfluous and turns it into
<path d="m100,100z"/>
which results in a different visual rendering. The right thing to do would be to look at all three coordinates of a cubic bezier command and only delete the command if all three of them are zero.
I encounter shapes like this quite often with vectorized scans of drawings I aggressively simplified within Inkscape (if someone is interested, I can include a test file, but I hope it should be clear what I’m talking about anyway).
Within cleanPath, and within the '# remove empty segments'-segment, the code
elif cmd == 'c':
while i < len(data):
if data[i+4] == data[i+5] == 0:
del data[i:i+6]
else:
i += 6
should be replaced with
elif cmd == 'c':
while i < len(data):
if data[i] == data[i+1] == data[i+2] == data[i+3] == data[i+4] == data[i+5] == 0:
del data[i:i+6]
else:
i += 6
Related branches
Changed in inkscape: | |
status: | Fix Committed → Fix Released |
Hmm... yes, that was definitely an oversight when (0,0) removal was coded. Thanks for the bug report!
I just looked at the specification and saw that 'q' was also a curve command, so I edited your proposed fix to also require a (0,0) control point for that command. The fix is in trunk as revision 197.