Re: [Inkscape-devel] new booleans
ok, some problems you mentioned are corrected (text not handled in outlines, offsets not behaving like outlines, outlines done even when stroke=none).
Now I have a segfault whenever I apply inset/outset to e.g. a star or circle (converted to curves first).
for difference, the rule "result=bottom-top" is a stamping; while i have nothing against it, forcing users to change the organization of the elements to do an operation is probably not good. so i changed the behavior to "result=first selected-second selected", so that layering doesn't need to be changed to do a difference. if that doesnt feel right, i'll change it, no problem.
I think this is wrong. First, the order of selecting objects may (in complex drawings) entirely depend on how convenient is each object for selecting. Second, one may select both objects with one rubberband, in which case the "order" is undefined. And third, when I prepare to do difference, I need to see and adjust the edge of the future shape, which means I need the subtracted shape to be on top because it will determine the shape of the cut-out. When I subtract bottom from top, I may end up with a quite unexpected shape because I don't see what I'm subtracting.
as a side note, it is true that outlines and such don't like path obtained by the freehand tool. in my opinion, there are already 2 things causing this: dumping the coordinates in the d attibute in the xml representation is not done with enough precisoin (should be corrected now that you've increased the precision), so that tangents at each end of the cubic patch (in fact, the control points) move slightly. since these tangents are very short, this result in (random) sharp edges, spikes and the like; also the points collected by the tool are fitted to bezier curves by the fitter in bezier-utils.c, while it may be better to collect all the points and then fit them, like illustrator does
"Cleanup" has always been a mystery for me, I never had time to figure out what it actually does. Is there any value in it being separate? Maybe combine it with simplify?
As for precision, I just changed %g to %.8g in svg/svg-path.c so that now curves are stored with 8 digits in each point in the d="" attribute. Is this enough for your purposes? If you have similar code that creates d="", you can use the same specification there.
And if you can in any way improve the freehand tool, e.g. by sombining it with your simplify command, that would be fantastic! What I would love to see is a slider controlling how closely the program reproduces the freehand. (For now, you can just make it a fixed value so I could recompile with different values to experiment, and I will add UI for changing it later.)
_________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f...
On Sun, 2003-12-14 at 12:11, bulia byak wrote:
I think this is wrong. First, the order of selecting objects may (in complex drawings) entirely depend on how convenient is each object for selecting. Second, one may select both objects with one rubberband, in which case the "order" is undefined. And third, when I prepare to do difference, I need to see and adjust the edge of the future shape, which means I need the subtracted shape to be on top because it will determine the shape of the cut-out. When I subtract bottom from top, I may end up with a quite unexpected shape because I don't see what I'm subtracting.
Agreed -- there's also a fourth advantage of subtracting the top shape; conceptually, it's like using the top shape to punch holes in the shapes below it. I think that works better with our basic intuition about things.
-mental
participants (2)
-
bulia byak
-
MenTaLguY