I've found what I think is a bug in NSBezierPath. I'm just wondering if others have found this, if there's a workaround, or whether I've just stuffed up somewhere.
Given a path formed from two closed subpaths such as: [first subpath] MoveTo() LineTo() LineTo() ... LineTo() ClosePath() [second subpath] MoveTo() LineTo() ... LineTo() ClosePath() If, while forming the path using this series of commands, I change the location of the second (or later) subpath's initial MoveTo using setAssociatedPoints, the ClosePath for that subpath goes to the previous position of the point, not the one I just moved it to. i.e. [second subpath] MoveTo() <---- make a note of this element's index LineTo() LineTo() ... SetAssociatedPoints( using saved index of MoveTo above ) ClosePath() <--- this close path adds a line segment that goes to the wrong place, being the previously set value of MoveTo. This doesn't occur with the first subpath, only the second (or later) subpaths. I'm supposing that the reason for this is that when you do a MoveTo(), the point you pass is internally saved as the point to which a ClosePath() must connect, but if setAssociatedPoints is used, and the index is not 0, this internal value is not updated as it should be. The reason I need this to work is because I'm computing a path based on an existing path (actually an offset) by iterating over its elements, but the exact placement of the initial MoveTo can't be determined until (and unless) a ClosePath() is actually encountered, at which point the point of the initial MoveTo() needs to be adjusted slightly. If the path isn't closed, this adjustment isn't needed. If I leave off the final ClosePath(), the path is correct except that there is a small gap left at the very corner where the path should be closed when the path is stroked. So I need a ClosePath() to eliminate this gap, but the unwanted line segment is even less welcome. One solution could be to look ahead sufficiently at MoveTo() time to see if the path is closed, and if so try to extract all the parameters needed to compute the modified moveTo location at that time, but this is really awkward given that apart from this problem I can simply process one element at a time in a loop with only a single element look-ahead. This requires making a special case of the start/end of the path that is anything but straightforward. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
