Problem with clip-path and DOM modifications or other linked resources

[Andreas Neumann <ne...@karto.baug.ethz.ch>]

Hello,

I am having a problem with linked resources where Batik behaves 
substantially different than other SVG viewers (ASV, Opera, MozillaSVG).

E.g. I am having a problem with a clip-path. The clip-path was linked to 
an element. This works fine. Afterwards, I change an attribute of the 
clip-path (e.g. by setting the "transform" attribute) but the 
modifications don't show up at the elements where the clip-path is linked.

As an illustration have a look at 
http://www.carto.net/neumann/batiksvgbugs/clipTest.svg - if you click on 
the lower text the clip-path should move and the changes should show up 
at the upper text. This example works fine in Opera or ASV, but fails in 
Batik.

A similar problem arises in Batik if I have definitions in the <defs> 
section, let's say a central gradient definition, and I change the 
central gradient definition later per script (after it was attached to 
the element that should show the gradient). With other viewers (Opera, 
MozillaSVG, ASV) the changes of the central gradient definition reflects 
back to the elements that use the gradient definition, with Batik, the 
changes don't show up. As an illustration see this example: 
http://www.carto.net/papers/svg/gui/colourpicker/index.svg - if I modify 
the upper slider (hue slider), the two other sliders (saturation and 
value) don't reflect the hue changes in Batik. In other viewers it does.

I don't know if that is a bug in Batik, and I didn't see any text on 
this situation in the current SVG spec, but I think we should make the 
SVG viewers behave consistent or update the SVG spec to make sure that 
the viewers behave consistent.

What do you think?

I remember having reported the issue with the gradients several 
months/years ago, but don't remember what the answer was back then.

In my opinion it is a "bug" in Batik, even if I cannot come up with 
wording from the spec that helps me justifying my opinion. Maybe the 
spec must improve in this case.

Thanks for your feedback,
Andreas



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Problem with clip-path and DOM modifications or other linked resources

[Tonny Kohar <to...@kiyut.com>]

Hi,

On Sat, 2006-04-29 at 13:06 +0200, Andreas Neumann wrote:
> thank you Thomas for confirming. I can use workarounds, not a problem 
> for my project. But if you find a longterm solution to the problem it 
> would be great.
> 
> Should I write a bug report on this or is this sufficiently known?

Yup, like Thomas said, it is a long time standing bug, due the
referencing problem. It is also happen with anything that requires
referenced element eg: gradients, defs, etc

The simplest workaround is like Thomas said, change some attribute of
the referencing element, so that it will rebuild the tree again.

The bug number is: 23443

If you are interested you might add your own description, sample stuff,
etc to that bug id: 23443

Regards
Tonny Kohar
-- 
Sketsa 
SVG Graphics Editor
http://www.kiyut.com


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Problem with clip-path and DOM modifications or other linked resources

[Andreas Neumann <ne...@karto.baug.ethz.ch>]

thomas.deweese@kodak.com wrote:
> Hi Andreas,
>
>     This is a long standing bug in Batik. 
>
>     In early versions of Batik we added listeners in these cases but with 
> many of the
>  'chaining rules' in SVG we would have memory leaks so the listeners were 
> removed 
> and as a consequence for many linked resources we don't track changes. The 
> simplest
>  fix is to 'twiddle' the referencing element so it rebuilds the referenced 
> resource (obviously 
> not a great solution).
>   

thank you Thomas for confirming. I can use workarounds, not a problem 
for my project. But if you find a longterm solution to the problem it 
would be great.

Should I write a bug report on this or is this sufficiently known?

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Problem with clip-path and DOM modifications or other linked resources

[th...@kodak.com]

Hi Andreas,

    This is a long standing bug in Batik. 

    In early versions of Batik we added listeners in these cases but with 
many of the
 'chaining rules' in SVG we would have memory leaks so the listeners were 
removed 
and as a consequence for many linked resources we don't track changes. The 
simplest
 fix is to 'twiddle' the referencing element so it rebuilds the referenced 
resource (obviously 
not a great solution).

Andreas Neumann <ne...@karto.baug.ethz.ch> wrote on 04/29/2006 06:10:40 
AM:

> E.g. I am having a problem with a clip-path. The clip-path was linked to 

> an element. This works fine. Afterwards, I change an attribute of the 
> clip-path (e.g. by setting the "transform" attribute) but the 
> modifications don't show up at the elements where the clip-path is 
linked.

> I remember having reported the issue with the gradients several 
> months/years ago, but don't remember what the answer was back then.

    It's the same thing...

> In my opinion it is a "bug" in Batik, even if I cannot come up with 
> wording from the spec that helps me justifying my opinion. Maybe the 
> spec must improve in this case.

    I agree it's a bug, unfortunately it's not one that is easy to
fix (well).


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org