...

Now I have a segfault whenever I apply inset/outset to e.g. a star or circle (converted to curves first).

uh? doesn't bug here... changed the SP_IS_PATH in SP_IS_SHAPE, maybe it'll correct the problem (i don't understand the difference). inset/offset dont change style anymore.

Great. I only now realized that you inset/outset a shape by its stroke width, so with stroke:none there's no expansion. I don't think this is expected behavior - I may very well want to inset/outset a shape without a stroke. Instead, let's decide on some standard inset/outset step, say 1pt, that is applied to all shapes (now hard-coded, later settable in preferences).

Also currently there's a bug that drops stroke:none when new shapes are created, and it causes a crash when attempting to expand a shape that has stroke-width but has no stroke: or stroke-opacity: in its CSS. We'll try to fix this bug ASAP, but for now could you please add some extra protection in your code: if there's no stroke: specification it is implied to be "none".

the good behavior would probably be to set the style to "fill=none;stroke=black;stroke-width=1.0pt".

No, why? I think we must restrain from setting some arbitrary styles; the commands must preserve the fill and stroke (when insetting/outsetting) and convert stroke to fill (when converting stroke to path).

...

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. changed the order so that it's "under-over", but the determination of which object is over the other is done "the dirty way (tm)" by looking in the xml tree, since i couldn't find a function doing that elsewhere. if you know of such a function, can you tell me where it is?

I think there's a z-order property in CSS, but I don't know if Inkscape (or SVG) use it at all. As far as I can see, the XML tree order is the same as the z-order in Inkscape, at least for drawings created in the program. But I may be wrong. Anyone else have an insight?

the polygon intersector i use currently rounds coordinates to 1/32, so that more precision than needed. the function that creates d="" in splivarot.cpp is liv_svg_dump_path() and is a copycat of sp_svg_write_path().

Yep, but you probably copied it before I changed the precision. As I see, now your commands create d="" paths even with 9 digits so that should be enough I think.

i hope my "tweak it 'til it works" development style doesn't bother you too much; it's fine for livarot since nobody uses it, but might be a problem for a real program like inkscape...

No problem!!! We're doing this ourselves all the time. Our motto is "patch first, discuss later" :) We're very excited about your code, so please continue working on it. We'll have lots of time to fix most bugs before the next release.

_________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2...