You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Seth Tager <se...@gmail.com> on 2006/01/30 18:33:12 UTC

efficiently generating multiple images from one svg doc

Hello,

I'd like to generate multiple images based on the same svg doc. Each
image will be slightly different (i.e. use different colors, replace
text, etc). I plan to use a SAXSVGDocumentFactory to generate an
SVGDocument and then manipulate the nodes/elements directly before
generating a jpg using ImageTranscoder.

Can anyone tell me whether this is a reasonable strategy or whether
I'd be better off manipulating gvt instead of the svg dom? Speed and
memory are concerns, which is why I'm not considering the option of
generating svg xml and then processing that. For smaller images I'm
estimating (based upon no evidence) that the parsing will consume a
noticeable amount of time and memory, but since I'm unfamiliar with
the code I realize my estimation may be way off. I'd like to avoid
burning development time on obviously wrong solutions.

Seth

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


Re: efficiently generating multiple images from one svg doc

Posted by th...@kodak.com.
Hi all,

Oscar Picasso <os...@yahoo.com> wrote on 01/30/2006 05:17:52 PM:

> I would do exactly what you intend: manipulate directly an SVGDocument.

   Manipulating the SVGDocument is _definitely_ the way to go.

> I did some tests few months ago, and if I remember correctly, loading 
the 
> document was the most time consuming part. I didn't try to use gvt so I 
don't 
> know if it would be more efficient. My guess is that it wouldn't change 
much. 

   The generation of the GVT tree from the SVG Document is generally fast. 
 
The slowest part of this tends to be text (so if your documents are text 
heavy
you might see a significant hit). 

   It should be noted that as long as you setup the Document to by dynamic 

you can build the GVT tree once and have Batik update it automatically as 
you change the SVG Document (this is what happens with dynamic content 
in the SVG Canvas).  To do this however you will have to bypass the 
transcoder (as it will always rebuild the GVT tree).

   This really isn't that hard especially since you can mostly just
crib the source from the Transcoders in Batik.  The trickiest piece of
the whole thing tends to be the scaling stuff, and that is complex in
the transcoders mostly because of the flexability the transcoders try
to provide.

> I can be wrong but in any case working directly on the SVGDocument is 
good 
> enough for me. If there is a faster method however, I am always willing 
to learn.
> 
> Oscar
> 
> Seth Tager <se...@gmail.com> wrote:
> Hello,
> 
> I'd like to generate multiple images based on the same svg doc. Each
> image will be slightly different (i.e. use different colors, replace
> text, etc). I plan to use a SAXSVGDocumentFactory to generate an
> SVGDocument and then manipulate the nodes/elements directly before
> generating a jpg using ImageTranscoder.
> 
> Can anyone tell me whether this is a reasonable strategy or whether
> I'd be better off manipulating gvt instead of the svg dom? Speed and
> memory are concerns, which is why I'm not considering the option of
> generating svg xml and then processing that. For smaller images I'm
> estimating (based upon no evidence) that the parsing will consume a
> noticeable amount of time and memory, but since I'm unfamiliar with
> the code I realize my estimation may be way off. I'd like to avoid
> burning development time on obviously wrong solutions.
> 
> Seth
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

> 
> Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on 
new 
> and used cars.

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


Re: efficiently generating multiple images from one svg doc

Posted by Oscar Picasso <os...@yahoo.com>.
Hi Seth,

I would do exactly what you intend: manipulate directly an SVGDocument.

I did some tests few months ago, and if I remember correctly, loading the document was the most time consuming part. I didn't try to use gvt so I don't know if it would be more efficient. My guess is that it wouldn't change much. 

I can be wrong but in any case working directly on the SVGDocument is good enough for me. If there is a faster method however, I am always willing to learn.

Oscar

Seth Tager <se...@gmail.com> wrote: Hello,

I'd like to generate multiple images based on the same svg doc. Each
image will be slightly different (i.e. use different colors, replace
text, etc). I plan to use a SAXSVGDocumentFactory to generate an
SVGDocument and then manipulate the nodes/elements directly before
generating a jpg using ImageTranscoder.

Can anyone tell me whether this is a reasonable strategy or whether
I'd be better off manipulating gvt instead of the svg dom? Speed and
memory are concerns, which is why I'm not considering the option of
generating svg xml and then processing that. For smaller images I'm
estimating (based upon no evidence) that the parsing will consume a
noticeable amount of time and memory, but since I'm unfamiliar with
the code I realize my estimation may be way off. I'd like to avoid
burning development time on obviously wrong solutions.

Seth

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




			
---------------------------------
 Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.