Reusing a DOM with Batik

[Paul Tae <Pa...@mgisoft.com>]

Hi,
	I have been using the Batik libraries and have run across a problem
I hope some one can help me with.  I have an SVG file that I want to
rasterize multiple times with slight modifications.  To make the process
more efficient I am reusing the DOM so that I don't have to parse the SVG
multiple times.  However, after the first rasterization, certain changes are
not picked up by the rasterizer.  Specifically a change in opacity.  These
are the steps.

1) parse SVG to DOM (using SVGFactory.getDocument())
2) rasterize DOM (using JPEGTranscoder.transcode()) (this works fine)
3) use the setAttribute() method on an element in the DOM with the attribute
name 'opacity' and a value different from the original.
4) rasterize the DOM again (using JPEGTranscoder.transcode())

The second rasterization results in no change in the opacity on the
specified element.

I have been trying to trace the code and so far have pinpointed the
org.apache.batik.css.AbstractViewCSS.getComputedStyle() method.  During the
first rasterization, there are no entries in the style hashtables so the
computeStyle() method is called and the hashtables are updated.  The second
time through, the hashtables are now populated and the change in the opacity
is not picked up.  The change is not detected.

There seems to be some caching of the style that cause a change in the style
not to be detected.  Changes to other attributes such as 'x',
'y','transform' and 'xlink:href' are all processed properly.

Any help on this matter would be greatly appreciated.

Thank you,
Paul Tae

Re: Reusing a DOM with Batik

[Stephane Hillion <hi...@apache.org>]

On Monday 26 February 2001 17:38, Paul Tae wrote:
> Hi,
> 	I have been using the Batik libraries and have run across a problem
> I hope some one can help me with.  I have an SVG file that I want to
> rasterize multiple times with slight modifications.  To make the process
> more efficient I am reusing the DOM so that I don't have to parse the SVG
> multiple times.  However, after the first rasterization, certain changes
> are not picked up by the rasterizer.  Specifically a change in opacity. 
> These are the steps.
>
> 1) parse SVG to DOM (using SVGFactory.getDocument())
> 2) rasterize DOM (using JPEGTranscoder.transcode()) (this works fine)
> 3) use the setAttribute() method on an element in the DOM with the
> attribute name 'opacity' and a value different from the original.
> 4) rasterize the DOM again (using JPEGTranscoder.transcode())
>
> The second rasterization results in no change in the opacity on the
> specified element.
>
> I have been trying to trace the code and so far have pinpointed the
> org.apache.batik.css.AbstractViewCSS.getComputedStyle() method.  During the
> first rasterization, there are no entries in the style hashtables so the
> computeStyle() method is called and the hashtables are updated.  The second
> time through, the hashtables are now populated and the change in the
> opacity is not picked up.  The change is not detected.
>
> There seems to be some caching of the style that cause a change in the
> style not to be detected.  Changes to other attributes such as 'x',
> 'y','transform' and 'xlink:href' are all processed properly.

You are right, the ViewCSS associated with the document keeps references to 
the computed styles and since no dynamic update is taken in account for the 
moment, the computed style is not updated by your change.
You can hack SVGOMDocument and adds a method to set 'defaultView' to null or, 
a solution which requires no code modification, you can replace the nodes you 
change by clones... but the danger is the memory leak.
I will consider adding a method somewhere to reset the ViewCSS.
--
  Stephane Hillion.