OK Bulia, thanks for this.

IMHO I feel this as not so flexible or coherent. Is there a way to challenge the spec, and have it updated in a future release, so that the clones become more flexible (up to the user to decide wether the geometry, move, stroke, fill (etc) must be linked with original or not).

Regards,

Matiphas

PS : I 'm thinking about a lot of example that might be impacted by this lack of flexibility - a presentation : a Box type is provided, and you'd like to fill them with different colors according to a severity for example - maps : clone an area and offer different kind of filling according to different layers/criteria - more poetic : a star shape is defined, and you'd like to have some blue, white, black (doesn't make a lot of sense by night, but I don't want to forget star wars fans...) spread over your canvas -etc etc etc (to sum up : it su***, but it's not blocking...)

-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: mercredi 20 octobre 2004 12:16 To: Gazal, Geraud (GE Healthcare) Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] clone behavior

...

I face a small issue while translating the tutorial from JP Bourgeoy (mirror effect), I'm facing a problem with the behavior of

the clones.

...

-> fill and stroke of the cloned object is locked and

synchronized with

...

the original object (while user can choose if geometric

transformations

...

are linked or not)

Per SVG spec, the style you assign to a <use> works as if it were the style on a <g> which includes the copy of the source object. This means that for a clone to have e.g. red color, the original which is cloned must have no color at all (it will be painted black by default then). Only in this case the red color from <use> will be inherited into the local copy of the object and it will be red. If however the source object has a color of its own, <use> cannot repaint it.

At least that's my understanding of the spec.