On 3/18/06, Andrius Ramanauskas <knutux@...400...> wrote:

For the first case, I guess the simple approach would be to have something like:

<defs> <clipPath id="clipPath123"> <use href="url to the clipping object(s)> </clipPath> </defs> <g clip-path="#clipPath123"> ... the clipping object(s) ... ... the clipped objects ... </g>

We might try that. But we'll need to code various special cases, such as deleting the clippath and unclipping its users when the source of the clone is deleted. Also various clone move compensations need to be disabled for this case.

However I have doubts about whether this will be convenient enough. I think in a lot of cases, when I clip an object I do want the clippath to disappear and not be in my way. If it stays visible, I will be tempted to just delete it, which will remove or incapacitate the clip - not the result I expected! I will therefore have to make it invisible by removing fill and stroke, which is very inelegant and brings lots of usability issues of its own.

Also this approach, as well as Mental's, requires that clipped objects are always grouped together with their clippers, which adds a layer of indirection, its own special cases to guard against (what if I just decide to ungroup it?), and usability issues.

For these reasons, I feel more predisposed towards the other approach, where the clipped object is just removed into defs and no grouping or cloning is needed. It's much cleaner conceptually. Yes, it prevents direct editing of the clippath unless you temporarily unclip it. But enabling the node tool to edit the clippath without unclipping is doable and relatively easy, and in any case this special-casing will only affect the node tool and nothing else. So, I propose to do this simple approach first, and then only if it proves inadequate, to look into more complex solutions with cloning etc.

-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org