I think you should be able to create something like:

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

There's no law that things like gradients and clipPaths have to go in <defs>, it's just a convention.

Since clipPath elements aren't part of the rendering tree in the SVG rendering model, there shouldn't be any actual circularity here (though I can't promise that Inkscape's renderer handles them entirely correctly in that regard).

Anyway, try playing with that in Inkscape and Batik to see how it works for you.

-mental

bulia byak wrote:

On 3/17/06, Joshua A. Andler <joshua@...533...> wrote:

...

1. In Inkscape, currently you can not edit a clippath on canvas

(presumably because it's located in defs). I wouldn't imagine this wouldn't be too painful to change, but the aspect of residing in defs brings up the other major difference/problem.

OK, suppose you have a clipped object and you want to edit the clippath. What's wrong with this: you unclip ("release") it so that the clippath becomes a regular path, edit it, and then clip back? I always thought that's the way you do it in AI (but I may be wrong on this, as I never used clipping much anywhere).

In AI, if you clip an object and use the (black) selection tool, it moves the entire "group". If you use the (white) direct selection tool, you can manipulate the clippath (or clipped objects) while the clip is still applied.

In Xara, if you clip an object and use the selector tool, it will move the entire "group". If you ctrl+click using the selector tool, you can manipulate the clippath (or clipped objects) while the clip is still applied.

From what I recall of Freehand, which I haven't used in a few years, you could also live edit clipped objects and the clipping paths but by normal selection the acted as "groups".

With good UI, if I need to make 20 tweaks to a clippath (or it could be 2 tweaks to 10 clippaths), I shouldn't have to visit the menus 40 times to do it. A ctrl+click like Xara saves the menu trips and is faster, more user-friendly, and I never have to leave the canvas.

For note, I do use clippaths quite a bit in my work.

...

2. In Xara or Illustrator when you clip objects, they're "grouped"

together (clipped objects and the clipping path/mask). It doesn't seem like this is easily achieved because of the structure of SVG and defs preceding regular items in the doc.

What do you mean by "grouping"? Why would you, as a user, care about document structure at all? What you need is the correct behavior, not structure. Most importantly, the clippath must be transformed together with the clipped object. This is already true for some kinds of objects (eg ellipses) and I know how to make it true for all objects. And this is doable regardless of whether the clippath is in defs or not.

The way that I'm talking about grouping is the behavior, not necesarilly a document structured group (but I would imagine it is, but just a special type). You're right, what I do need is the correct behavior. From the way it seems, if anyone that uses masks or clippaths in other vector software comes to Inkscape, they'll be confused by lack of ease with editing. Please try to clip some objects and manipulate them in both Xara & AI with my instructions above, and the "grouping" I talk about will probably make more sense to you then.

So, unless I'm missing something, I don't see any need for moving clippaths out of defs as Mental suggested.

I would personally prefer not moving them out of defs as well, but if it's the best solution, then it is what it is. And even though we both prefer to keep clippaths and masks in defs, I feel the need to repeat your own question and following statement back to you. "Why would you, as a user, care about document structure at all? What you need is the correct behavior, not structure." And it seems like to get the correct behavior, we may have to not use the "best practice" of having it in defs and modify our structure... unless you have any other suggestions.

-Josh

On 3/17/06, Joshua A. Andler <joshua@...533...> wrote:

In AI, if you clip an object and use the (black) selection tool, it moves the entire "group". If you use the (white) direct selection tool, you can manipulate the clippath (or clipped objects) while the clip is still applied.

In Xara, if you clip an object and use the selector tool, it will move the entire "group". If you ctrl+click using the selector tool, you can manipulate the clippath (or clipped objects) while the clip is still applied.

OK, so these apps allow you to edit clippath without unclipping. That's good, and eventually we'll need to do this as well. However my point is that:

- even without it, clipping is quite usable if you have reliable clip and unclip commands;

- implementing editing clippath without unclipping would not be made any easier or more difficult by placing it in defs or not. Even when not in defs, clippath is still a special invisible object, and you still need special code to enable editing it as a regular path. It'll take work no matter which way you go.

The way that I'm talking about grouping is the behavior, not necesarilly a document structured group (but I would imagine it is, but just a special type). You're right, what I do need is the correct behavior. From the way it seems, if anyone that uses masks or clippaths in other vector software comes to Inkscape, they'll be confused by lack of ease with editing. Please try to clip some objects and manipulate them in both Xara & AI with my instructions above, and the "grouping" I talk about will probably make more sense to you then.

Please be more specific. I have already explained the situation with transforming clipped objects, and with editing clippath without unclipping (both are doable but need work). What else do you need to get the desired "grouped" behavior?

I would personally prefer not moving them out of defs as well, but if it's the best solution, then it is what it is. And even though we both prefer to keep clippaths and masks in defs, I feel the need to repeat your own question and following statement back to you. "Why would you, as a user, care about document structure at all? What you need is the correct behavior, not structure."

Because I am not a user, so I care about structure. I think that keeping them in defs would be much easier overall, because we have a lot of legacy code that assumes that everything is in defs.

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

# from Joshua A. Andler # on Friday 17 March 2006 01:29 pm:

And the other potential solution we thought of was having the clipPath (or mask) in defs just have a link to an object on canvas.

This thread seems to be mostly about clipping, but I would like to visit an issue about masks.

The XAR transparency object is totally separate from the fill. Rather than the RGBA, the fill only describes color (albeit in CMYK, RGB, etc) and the transparency object can describe flat or gradient (linear, elliptical, radial, etc) transparency. This allows you to have e.g. a vertical linear transparency over a horizontal linear gradient.

The only way that I have found to express this in SVG is with a mask, but ideally I would like to be able to link the mask entities to the entities on the canvas. I have found that I can accomplish this by referencing (use) them both to an entity in the defs section, but that disables editing in inkscape's canvas. All other forms seem to lead to circular linkage. Suggestions?

http://scratchcomputing.com/tmp/mask_linked.svg

Maybe some mode of editing entities in the defs section? Possibly in a separate canvas or just as ghosted (dotted?) shapes on the main canvas?

--Eric

# from bulia byak # on Sunday 19 March 2006 10:42 am:

Everything said here applies both to clips and masks.

except that there is no need to link to the entities which are being clipped...

...

Maybe some mode of editing entities in the defs section?  Possibly in a separate canvas or just as ghosted (dotted?) shapes on the main canvas?

As I proposed, at this first stage we will have clippaths/masks in defs and not editable except by temporarily unclipping/unmasking, editing, and then clipping/masking back.

If I understand this correctly, the plan is to (conceptually or actually) move them out of defs for a bit and onto the canvas proper?

How would that work with an entity and mask which are both "use"ing a path from the defs section? How would a user select one as the mask for the other when they are identical?

This is at least somewhat distinct from clipping in that a mask which is defined by a shape which is identical to thing which it masks is difficult to deal with when it is unmasked. Of course, I am only talking about a very specific (mis?)use of masks here. There might be a better approach to getting around the lack of transparency/fill separation in SVG, but I haven't seen it. If I do use a mask to represent this, I would like to know what is the best way to make it editable.

--Eric

After the patch with clipping masks/paths was applied, I'm figuring out how to solve an issue with tranforms on masks. The problem is: *If any object to which a mask is applied is transformed already, mask is placed on wrong place *If masked object is moved, unmasking places mask object in wrong place

First solution that comes in mind - for first issue take a transformation of masked item, invert it and apply to a mask item (the ones which is moved to defs), for second issue - take transform of masked item and apply it to masked item which is moved back from defs.

But that does not solve same issue for multiple items which are masked/unmasked. So, quickest solution I see - if mask is beeing applied to multiple items, make an ordinary group and apply mask to it. That still does not solve an issue with unmasking multiple items whick mask was set manually or externally - for those we can just say, that unmask transform is calculated by the last item which mask is removed.

So, if there are no objections, I will implement that behavior.

Andrius

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

After the patch with clipping masks/paths was applied, I'm figuring out how to solve an issue with tranforms on masks. The problem is: *If any object to which a mask is applied is transformed already, mask is placed on wrong place *If masked object is moved, unmasking places mask object in wrong place

First solution that comes in mind - for first issue take a transformation of masked item, invert it and apply to a mask item (the ones which is moved to defs)

Yes, this might work. Please test it and commit if it works.

, for second issue - take transform of masked item and apply it to masked item which is moved back from defs.

Yes, this is what I had proposed for that problem.

But that does not solve same issue for multiple items which are masked/unmasked. So, quickest solution I see - if mask is beeing applied to multiple items, make an ordinary group and apply mask to it.

I think there's a better solution. If a user wants a group masked, he can always group it himself before clipping. Instead, I propose this: when you mask several objects by one common mask, just create a separate mask for each object being masked, i.e. copy the clippath/mask as many times to the defs as necessary. This will prevent sharing the clippath/mask among objects, which will likely have many issues. If you really need several objects with one shared mask, group them yourself.

Correspondingly, when you unmask/unclip, right now it checks whether the same mask is used by other objects, and if it's not, it's moved from defs to the canvas. Instead, I think it should _always_ create a copy of the clippath/mask object for _each_ unmasked object, and then delete those masks in defs that are not used anymore. So, if you unmask several masked objects, you get the corresponding number of mask objects - which may or may not coincide, depending on whether the objects have aquired different transforms since being clipped/masked.

I think this will resolve it in the most logical and flexible way. What do others think?

Here are a couple more things to do:

- When ungrouping a clipped/masked group, copy the clippath/mask once for each ungrouped object and apply, so that the objects remain clipped as they were before

- When converting anything to path, carry over the clippath/mask attributes

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

On 3/20/06, Joshua A. Andler <joshua@...533...> wrote:

One thing has become apparent though, you seem to be against the "auto-grouping" that other apps do. Why is that?

I'm against auto-anything if it does not really do anything which I can't do myself just as easily.

It's simple: there are 2 possible configurations:

(a) 10 objects grouped, group clipped

(b) 10 objects independent, each clipped separately

You seem to propose that applying clipping to several objects should automatically give (a). But note that I can still go from (a) to (b) simply by ungrouping. So if I need (b) I will have to undo something that was done automatically for me. In other words, both your and mine ways allow both (a) and (b), but in my approach, to get extra functionality (grouping), you need to do an extra step (group before clipping), whereas in your approach, to get more simple functionality (no group), you have to do the extra step of ungrouping. That's why I'm saying that my approach is more logical. However I do not insist on it, and if several people will assert that they use (a) much more often than (b), I will not object to autogrouping. It's not really a big issue.

I'll use my common illustration example to try and explain. If I am drawing a leg, and I have a bunch of objects on top of it that are layered for highlights and shading, when I clip or mask all of these, it's because I want the whole thing to be treated as one object (with restricted view). When I clip it... that's now the leg. If I move said leg, all highlights and shadows need to transform with the leg.

I really don't see why you had no need to treat these objects as a whole _before_ clipping and thus didn't group them _yourself_. This is what I would have done first thing, right at the start, and then would add new highlights and edit them while being _inside_ that group. Then when I need to move them all as a whole, or to clip them all, I would ascend to the parent layer and do this on the group as a whole. Compared to your scenario, this would save me a lot of trouble in not having to painstakingly select all those scattered highlights each time I need to treat them as a leg.

If I'm understanding correctly, this is a bad solution. I do complex work, often with thousands of objects. I'm planning on going back to re-do effects on Gaze and a number of other pics down the line and I have some pretty wild ideas about how I want to do it. One of them involves masking sections of hair... there are THOUSANDS of strands of hair. This will murder my file to have thousands of masks in defs,

Of course not. If all your hair needs to be precisely trimmed by the same shape, I am NOT proposing that you should clip or unclip each strand separately. OF COURSE you should group them all and clip the group. And unless you manually ungroup the clipped group, you will always have one clipping path applied to the single object (group).

However I can very well imagine that I may want to introduce some untidiness into the hair: first trim it but then move the clipped strands around, so that some of them stick out farther than others. Again, it's no big issue: with your autogrouping, I will just have to ungroup the group, and then I have the separate clipped strands that I can move around. But it just seems so much more logical to me that when I clip separate objects, I get separate clipped objects. When I clip a group, I get a clipped group. What's wrong with that?!

As for performance of 1000 strands having 1000 separate clippaths: first, as I just explained, I don't force this on you in any way (unless you want to have untidy hair, in which case it's unavoidable); and second, please don't panic until you have really tested it. My intuition says that a performance hit will be quite small.

Additionally, Andrius had talked about having a dialog that will allow you to apply existing clippaths and masks to other objects, groups, or layers... this will then be impossible.

I'm against actually sharing clippaths/masks among different objects, for architectural reasons. If you want 2 or more objects to use the same clippath, again, just group them and clip the group, or put them all in the clipped layer.

I for one look forward to being able to mask or clip an entire layer easily...

No problem with that either way.

I also look forward to having the ability to add or remove items to/from clipping and masking objects via the dialog as well (adding additional paths or masks to make compound paths/masks for example).

Why dialog? Just unclip temporarily, add to your clippath, and clip back. However, no problem adding a special command for the same, for example Object > Clip > Add to clipping path.

...

• When ungrouping a clipped/masked group, copy the clippath/mask once

for each ungrouped object and apply, so that the objects remain clipped as they were before

Am I wrong in thinking that this will exponentially increase filesize and as a result hurt Inkscape performance with really complex documents?

If by "exponentially" you mean what this word _really_ means, then of course no. It will increase size and probably somewhat affect the performance, but not by much. I don't think the change in performance will be even measurable in 1000 objects using 1 mask vs. 1000 objects using 1000 masks. On the other hand, sharing one mask among several non-grouped objects is sure to have a lot of hidden issues and extra code to guard against surprises.

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

On 3/20/06, Joshua A. Andler <joshua@...533...> wrote:

I definitely understand what you're saying, and can agree that grouping is not too painful. What I needed to communicate in the last email was with the mentioned grouping... clipping "groups" are not quite like regular groups, they have special editing properties. Let me save a whole lot of correspondence by asking a question. Will it be possible to move objects around inside (and out) of the clipped area while clipping is applied?

Of course. If you've clipped a group, you can move objects inside the group, delete them or add new ones as you would do in any group. The clipping remains fixed as you do so. Only if you transform the group object itself as a whole, its clippath is transformed with it. I think this is quite logical.

It's only if you've applied clipping directly to an object, not a group, then moving that object without moving the clippath with it becomes impossible. But you can node-edit it (if it's a path) and thus even "move" it as a whole by moving all its nodes, without affecting the clippath. Or you can just unclip it, group it with something and clip the group.

Finally, if you _really_ need it, I can add yet another (5th) "transform with object" button to the Selector bar - for clippaths (and a 6th for masks). Like the corresponding buttons for gradients or patterns, these would allow you to transform the clipped/masked object either together or independently of its clippath/mask. It's not difficult to do, and I even like the idea somewhat for its consistency.

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

On Mon, 2006-03-20 at 21:47 -0400, bulia byak wrote:

Finally, if you _really_ need it, I can add yet another (5th) "transform with object" button to the Selector bar - for clippaths (and a 6th for masks). Like the corresponding buttons for gradients or patterns, these would allow you to transform the clipped/masked object either together or independently of its clippath/mask. It's not difficult to do, and I even like the idea somewhat for its consistency.

My feeling is that we should do that, but only have one button for both clippaths and masks.

-mental