Should you not want to have a permanent clipping option or ability so that the path is altered?

Oh and could we please have the ability to clip a group of objects, I want to cut an object at a boundary line perhaps the page boundary I don't want to have to ungroup every object and clip each one, very annoying and causes alot of problems with very complex objects.

On Sat, 18 Mar 2006 18:25:15 -0400 , "bulia byak" <buliabyak@...400...> wrote:

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="urlclipPathdefs> <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

---

This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid%110944&bid$1720&dat%... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel