Hi Friends,
Just working on another image. Usually I give a clipping path some bright color fill that can't be confused with the rest of the drawing/image. It makes it easier to find, if I have to unclip later, for some reason. In this case, I decided things were clear enough to me, that I didn't need the color cue, so I left the clipping path unfilled. But for some reason, the clip doesn't work right if I don't have a fill in the clipping path. Here's a quick image:


The SVG is attached below for investigation. The red path is the clipping path, and please be assured that I don't normally make the path so wide. I just did it here to make it easy to see. The top pair shows the before and after, and you can see how the blur does not get clipped away in the "hole". The bottom pair shows that if the clipping path is given a fill (yellow), everything gets clipped as expected.

It seems that the object having the hole in the middle is the issue. Because I've tested clipping on a "solid" object, with and without a fill in the clipping path. And it works as expected, both ways. But in this case, for some reason, the hole doesn't get clipped unless the clipping path has a fill.

I searched Launchpad, and found this bug #564080, which might be related. I think the problem with my issue, might be somehow related to the Fill Rule, but don't really know.... Maybe it's more related to the clipping path being a compound path, because it seems that the inner subpath (which defines the "hole") didn't get clipped. And I don't really understand this bug #564080 very well -- just that it apparently has to do with the Fill Rule.

Assuming what I've found is a bug, should I add it to this report? Or should it have its own new report?
Or is it not a bug at all, but rather something that I did wrong or overlooked in the process?



Thanks for your help

How did you generate your clipping path? When I take your red path and do Path>Break Apart, and then do Path>Difference the resulting path clips the object correctly.

brynn wrote:Assuming what I've found is a bug, should I add it to this report? Or should it have its own new report?

IMHO neither.

Inkscape behaves as expected: the two clip-paths have different fill-rules, as indicated in the 'Fill & Stroke' dialog.
The upper one (unfilled) does have non-zero, the lower one even-odd. The different clipping results are not due to having a stroke or fill color assigned.

A few tests later…: Hmm - the issue seems that the fill-rule is not set when there is no fill assigned, even though it can be toggled in the 'FiIl & Stroke' dialog.

Yet a few more tests later…: The clip-path as stored in the <defs> section appears to have the fill-rule stripped if the fill is set to 'None'. Not sure if this is really incorrect though - fill-rule does affect the fill (and not the stroke), and if there is no fill, there's no fill-rule to be followed (which overrides the inherent fill status based on the path directions).

If you change the path direction of the sub-path of the inner hole, the clipping does what you expect (due to the reversed path direction which defines the inner part of the path as a hole). Basically, the fill-rule attribute can be used to override this (if the path has a fill).

So the subpaths basically have different default fill attributes? Not sure I understand but it does seem that Inkscape is treating it logically.

llogg wrote:So the subpaths basically have different default fill attributes?

No. The relative direction [1] of the sub-paths determines whether the innermost part is inside or outside.

To test:

1. draw a filled rectangle
2. draw a smaller filled rectangle on top of it
3. combine the two objects (Ctrl+K), verify that the fill-rule is nonzero: all parts are filled
4. switch to the node tool <F2>, select a node of the inner sub-path and reverse the path direction (Shift+R): the inner path now is unfilled even though the fill-rule remains nonzero.

[1] in Inkscape 0.48, you can have the path outline showing the path direction, see 'Inkscape Preferences > Tools > Node > Path Outline: [x] Show path direction on outlines'