On Sat, 5 Apr 2008 15:48:20 -0400, "bulia byak" wrote:
OK, while I'm still not sure about the correct behavior of close_path, I just eliminated it by replacing it with a lineto to the remembered start-of-path point, and that got rid of the bug. Thanks for helping to figure this out, and sorry for bothering you with this :)
That will make the bug go away, sure. But it will introduce another. If you don't do a cairo_close_path when the SVG has the close-path ('z') operator, then you'll get caps at the beginning and ending of the path rather than a join between them.
On Sat, Apr 5, 2008 at 2:40 PM, bulia byak <buliabyak@...400...> wrote:
On Sat, Apr 5, 2008 at 9:54 AM, Carl Worth <cworth@...573...> wrote: I then wondered how replacing a curveto with a moveto in any path may result in drawing a _line_ which was _not in the path_. But then I remembered about the close_path command, z.
Yes, the close_path is critical to the bug.
If some curves precedingit were replaced by movetos, it will indeed draw a line from the last stroked point which will be wrong. But then the question is, is it correct to draw a closepath command from the last stroked point, not from the current point? If closepath would work from the current point, as set by movetos, there would be no bug here.
That's not quite what's happening.
A close_path operation always do draw a line from the current point. But it draws a line (and joins) back to the beginning of the current sub-path, (that is, it joins back to the most recent move_to).
What's funny is that in cairo 1.2 we added a path manipulation function, (cairo_new_sub_path), that doesn't have any analogue in PostScript, PDF, or SVG. What it does is begin a new sub path but without setting the current point, (so it's exactly half of a move_to).
For your optimization you would actually want the other half of move_to. That is, what you want to do is to change the current point, but without starting a new sub-path. I suppose we could add another function for that, but I wonder if it would be more confusing than helpful in general.
In the meantime, you can actually do the right thing, but it takes a little more effort. What you would need to do is every time you are optimizing away a path element, save the final point, (but don't issue a move_to), replacing a point saved in any immediately previously optimized-away element. Then, at the next non-optimized-away element, if there's a saved point you would issue a cairo_line_to to that point. That way, you optimize away almost as much drawing, (all but one line), but you avoid introducing the extra, undesired sub-path.
I don't know if any of that is making sense, (I hope it is, but describing the state-management in prose can be tricky). I wanted to try writing code for that today, but I didn't get a chance.
Anyway, more than anything, I'm glad that you're playing with cairo inside of inkscape, and I want to let you know that we're always available if you have any questions or problems.
-Carl