Re: [Inkscape-devel] Her is an example of what I am talking about
On 8/21/07, Bibi Morris <bibimorris@...856...> wrote:
Yes I understand what you are saying, however I am not seeing that happening in 45.1.
When you tried it, and got what I wanted, did you have to do a break apart to preserve the centers of the letters?
Nope.
I think I understand what's going on. The culprit is the font you use. See, when a path contains an inner subpath, that subpath makes a hole only when the direction of that subpath is contrary to that of the outer path. Otherwise, if their directions are the same, there's no hole - the path is solid. That's why, if you convert an O to a path and break apart, you get two paths, and when you combine them back, you get the hole back. If you break apart, Path > Reverse the inner path and combine, you won't get a hole.
Now, in your font, for some weird reason, the direction of path in "o" is opposite to that of "d" and "g". Therefore when you convert "dog" to path, the places where the letters overlap become holes. And Union of a path with itself only removes the non-hole overlaps as extraneous; it does not touch holes because it assumes they are there for a reason. Therefore, you could not remove those holes in letter overlaps neither by offset nor union.
One way to fix this would be, after converting to path, select both inner and outer parts of "o", Path > Reverse them, then combine everything back and Union. Or just use a different font :)
It would also help, btw, to not work always in Outline mode - in normal mode it's much easier to see if some overlap is a hole or not (because you have fill). You could also note in regular mode that you have an atrociously huge stroke width (73px!) on your shapes which I assume isn't really necessary for a cutter :)
If I understand the issue correctly, I'd say this is actually partly an issue in livarot -- ideally, it should use the insideness/outsideness rules that the path is being rendered with, which should then give the expected result without worrying about winding differences between operands.
When it's finished, 2geom's boolean code should be agnostic to inter-operand winding, though, as Mike normalizes the windings.
-mental
On 8/22/07, MenTaLguY <mental@...3...> wrote:
If I understand the issue correctly, I'd say this is actually partly an issue in livarot -- ideally, it should use the insideness/outsideness rules that the path is being rendered with, which should then give the expected result without worrying about winding differences between operands.
If so, this needs to be inserted not only into boolops, but into converting text to path as well, because in this example the holes appeared at the step of converting text to path.
On Wed, 22 Aug 2007 13:04:12 -0300, "bulia byak" <buliabyak@...400...> wrote:
If so, this needs to be inserted not only into boolops, but into converting text to path as well, because in this example the holes appeared at the step of converting text to path.
Ah. Yeah, sounds like it then -- text to path shouldn't affect apparent inside/outsideness.
-mental
participants (2)
-
bulia byak
-
MenTaLguY