trunk: degenerated linked offset of ellipse/circle (rev >= 12594)

Bug #1236830 reported by su_v
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Medium
Alvin Penner

Bug Description

Revision r12594 changed how the paths for elipses/circles are generated (see also bug #1235504, bug #1231990). This also affects linked offsets of circle/ellipses - please compare attached sample files generated with r12593 and r12594.

Reproduced with r12669 on Ubuntu 13.04 (inkscape-trunk PPA) and r12670 on OS X 10.7.5.

Revision history for this message
su_v (suv-lp) wrote :
Revision history for this message
su_v (suv-lp) wrote :
description: updated
Revision history for this message
Markus Engel (engelmarkus) wrote :

Yes, this happens as the ellipse and arcs use true elliptical arcs now instead of bezier curves. If you create a path containing an elliptical arc manually, this happens in revs < 12532 as well. The code for this is in livarot/PathConversion.cpp:102. So do you think this code is completely wrong? I mean, shouldn't the path degenerate the further you move the handle?

Revision history for this message
su_v (suv-lp) wrote :

On 2013-10-09 21:37 +0200, Markus Engel wrote:
> I mean, shouldn't the path degenerate the further you move the
> handle?

Not sure I understand the question: from a user's perspective, I expect a smooth offset of the original circle which runs as parallel to the outline of the original circle as possible. Based on my tests this does not happen with the ellipse/circles created after r12584 (it looks as if a polygon is getting offset, and the number of corners of the polygon seem to vary depending on the offset radius).

Maybe this and other recent ellipse-related issues ought to be discussed on the mailing list.

Revision history for this message
Alvin Penner (apenner) wrote :

    I am reasonably certain that the error is coming from the routine Path::RecStdArcTo in the file PathOutline.cpp. This routine has most likely never been used before. It converts arcs into beziers, depending on a tolerance, and if the tolerance is not satisfied, then it subdivides the arc before attempting the conversion.
     I think this routine got accidentally activated in rev 12594 because a bezier representation was replaced with an arc which necessitates calling this new (actually old) routine which converts back to bezier.
    I'll spend next week looking at the algebra to see what is wrong, it does not look like it should be hard to fix.....

Changed in inkscape:
status: New → Confirmed
Revision history for this message
Alvin Penner (apenner) wrote :

fixed a couple of typos in PathOutline.cpp

committed to rev 12696

Changed in inkscape:
status: Confirmed → Fix Committed
su_v (suv-lp)
Changed in inkscape:
assignee: Markus Engel (engelmarkus) → Alvin Penner (apenner)
Bryce Harrington (bryce)
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.