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 Andreas Neumann <ne...@karto.baug.ethz.ch> on 2006/04/18 23:35:07 UTC
SVG Rasterizer questions
Hi,
I have questions on the SVG Rasterizer:
We added a printing functionality to our interactive Yosemite map. We
use the svgrasterizer on our server to create PDFs. Batik does a good
job and the resulting PDF is of good quality. Also, svgrasterizer can
execute scripts onload, which is a necessary feature for our
application. I don't know of any other svg2pdf converter that can handle
"onload" scripts. Thanks for your good job!
The prototype of the printing tool is available at
http://www.carto.net/williams/yosemite/unstable/index.svg --> use the
printing tab. Maybe it can be better used in a webbrowser with SVG
capabilities. It works in Squiggle as well, but its easier to launch the
generated pdf in a browser.
My main concern is speed though. Depending on the complexity of the map
content and the paper size it takes 15-60 seconds to render the pdf. It
seems like part of the slow down is due to a use of opacity and raster
images.
The interesting thing is, that Squiggle renders the same file much
quicker to the screen than rasterizer to the PDF. Squiggle is several
times faster than the rasterizer process to pdf. And I did not see much
difference with using different output formats (png, jpeg, pdf).
Are there any known performance tuning hints that I should follow to
improve the PDF rendering speed of svgrasterizer? I think I allow enough
memory for the svgrasterizer process (up to 512M).
The other thing is that svgrasterizer always rasterizes polygons if they
have the opacity attribute set. I am pretty sure that PDF also supports
real transparency. Are you planning to support real transparency in PDF
output in the future?
ah - maybe I should mention: the rasterizer task is started from a php
script and runs as a batch job. Maybe it would be quicker if I'd use
some sort of serverside java?
Thanks for any hint,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG Rasterizer questions
Posted by Cameron McCormack <ca...@mcc.id.au>.
Hi Andreas.
Andreas Neumann:
> ah - maybe I should mention: the rasterizer task is started from a php
> script and runs as a batch job. Maybe it would be quicker if I'd use
> some sort of serverside java?
Indeed this would be where most of the time is taken, I'd guess. The
startup time for the JVM is significant, so if you can somehow get a JVM
running already and farm off rasterisation requests to it, it should
improve things. I'm not familiar at all with serverside Java things
like Tomcat, but my guess is that a server like that could be used to
provide a web interface for running rasterisations. A home cooked
solution for having a JVM running and sending it rasterisation tasks
could work, too.
--
Cameron McCormack ICQ: 26955922
cam (at) mcc.id.au MSN: cam (at) mcc.id.au
http://mcc.id.au/ JBR: heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG Rasterizer questions
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Hi Thomas,
I tested with changing the opacity to fill-opacity and am happy to
report that the svgrasterizer works now A LOT faster. It is now around
ten seconds, whereas it was 20 to 30 seconds before. Of course this
depends on the complexity of the map.
I noticed that the landcover polygon now stays as vector whereas before
it was rasterized because of the group opacity.
Next, I will try the Tomcat stuff. Will take longer than just fixing the
opacity ...
Thanks again for your hint,
Andreas
> The short answer is that no setting the property on individual
>elements is not more efficient.
>
> The big difference comes between using 'fill-opacity' and 'opacity'.
>You need to be aware that in some cases the rendering result can be
>quite different. If a group with 'opacity="0.5"' has two overlapping
>rectangles the overlap region will have the same opacity as the
>non-overlap regions of the rectangles. However a group with
>'fill-opacity="0.5"' and the same two rectangles will have 75%
>opacity in the overlap region (the first rectangle will block 50% the
>second will block 50% of what's left).
>
>
--
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland
Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG Rasterizer questions
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
> The short answer is that no setting the property on individual
>elements is not more efficient.
>
> The big difference comes between using 'fill-opacity' and 'opacity'.
>You need to be aware that in some cases the rendering result can be
>quite different. If a group with 'opacity="0.5"' has two overlapping
>rectangles the overlap region will have the same opacity as the
>non-overlap regions of the rectangles. However a group with
>'fill-opacity="0.5"' and the same two rectangles will have 75%
>opacity in the overlap region (the first rectangle will block 50% the
>second will block 50% of what's left).
>
>
ok, I remember that you explained group opacity a few months before. In
my case the elements within the group don't overlap, so this is not an
issue. I will use fill-opacity on the parent group as you suggested.
> Also I realized that the interface we use to draw to PDF does
>not allow us to easily specify the group opacity case so even if
>PDF does support it (which the more I think about it, it probably
>does) it would be quite difficult for us to generate...
>
>
>
ok.
Thanks again. I will report on my progress.
Andreas
--
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland
Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG Rasterizer questions
Posted by th...@kodak.com.
Hi Andreas,
Andreas Neumann <ne...@karto.baug.ethz.ch> wrote on 04/19/2006 01:56:25
AM:
> >>have the opacity attribute set. I am pretty sure that PDF also
supports
> >>real transparency. Are you planning to support real transparency in
PDF
> >>output in the future?
> > If you are only using fill or stroke you should
> > map the opacity attribute to fill-opacity or stroke-opacity it will be
> > much more efficient in either case[...]
> sounds like a good approach. Currently, I only need fill opacity. But I
> set the attribute on the group. Does that matter? Would it be more
> efficient to set it on the individual elements instead of the group?
The short answer is that no setting the property on individual
elements is not more efficient.
The big difference comes between using 'fill-opacity' and 'opacity'.
You need to be aware that in some cases the rendering result can be
quite different. If a group with 'opacity="0.5"' has two overlapping
rectangles the overlap region will have the same opacity as the
non-overlap regions of the rectangles. However a group with
'fill-opacity="0.5"' and the same two rectangles will have 75%
opacity in the overlap region (the first rectangle will block 50% the
second will block 50% of what's left).
Also I realized that the interface we use to draw to PDF does
not allow us to easily specify the group opacity case so even if
PDF does support it (which the more I think about it, it probably
does) it would be quite difficult for us to generate...
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG Rasterizer questions
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Thanks Cameron and Thomas for your hints,
>Hi Andreas,
>
> Cameron is correct that just starting the JVM from scratch and loading
>all the
>classes (and running the JIT compiler, etc) can easily represent the
>majority
>of your rasterizing time. I'll also comment on some of the other points
>you raise:
>
>
>
ok, then this is something I will definitely look at. I am new to Tomcat
but will probably find out how to do it.
>>And I did not see much
>>difference with using different output formats (png, jpeg, pdf).
>>
>>
>
> If JPEG is about as fast as PDF the really most of your time
>is spent bringing the JVM up.
>
>
>
sounds reasonable
> With the current SVN version of Batik (not the 1.6 release) images
>are rasterized at 300dpi. For many purposes this is a bit high you could
>consider lowering the value by setting the KEY_DEVICE_RESOLUTION hint
>on the PDF transcoder.
>
>
>
yes, 200 dpi might be enough
>>have the opacity attribute set. I am pretty sure that PDF also supports
>>real transparency. Are you planning to support real transparency in PDF
>>output in the future?
>>
>>
>
> I don't know that PDF supports 'group' opacity, i.e. multiple
>elements that need to be rendered to an offscreen opaquely and then
>rendered transparently to the main canvas (but I'm no PDF expert so
>perhaps it does). If you are only using fill or stroke you should
>map the opacity attribute to fill-opacity or stroke-opacity it will be
>much more efficient in either case (you might also make an artistic
>decision that setting both is satisfactory for your needs).
>
>
I am not a pdf expert either. Would have to ask other people.
sounds like a good approach. Currently, I only need fill opacity. But I
set the attribute on the group. Does that matter? Would it be more
efficient to set it on the individual elements instead of the group?
Andreas
--
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland
Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG Rasterizer questions
Posted by th...@kodak.com.
Hi Andreas,
Cameron is correct that just starting the JVM from scratch and loading
all the
classes (and running the JIT compiler, etc) can easily represent the
majority
of your rasterizing time. I'll also comment on some of the other points
you raise:
Andreas Neumann <ne...@karto.baug.ethz.ch> wrote on 04/18/2006 05:35:07
PM:
> I don't know of any other svg2pdf converter that can handle
> "onload" scripts. Thanks for your good job!
Thanks!
> And I did not see much
> difference with using different output formats (png, jpeg, pdf).
If JPEG is about as fast as PDF the really most of your time
is spent bringing the JVM up.
> Are there any known performance tuning hints that I should follow to
> improve the PDF rendering speed of svgrasterizer? I think I allow enough
> memory for the svgrasterizer process (up to 512M).
With the current SVN version of Batik (not the 1.6 release) images
are rasterized at 300dpi. For many purposes this is a bit high you could
consider lowering the value by setting the KEY_DEVICE_RESOLUTION hint
on the PDF transcoder.
> The other thing is that svgrasterizer always rasterizes polygons if they
> have the opacity attribute set. I am pretty sure that PDF also supports
> real transparency. Are you planning to support real transparency in PDF
> output in the future?
I don't know that PDF supports 'group' opacity, i.e. multiple
elements that need to be rendered to an offscreen opaquely and then
rendered transparently to the main canvas (but I'm no PDF expert so
perhaps it does). If you are only using fill or stroke you should
map the opacity attribute to fill-opacity or stroke-opacity it will be
much more efficient in either case (you might also make an artistic
decision that setting both is satisfactory for your needs).
> ah - maybe I should mention: the rasterizer task is started from a php
> script and runs as a batch job. Maybe it would be quicker if I'd use
> some sort of serverside java?
Tomcat is the 'official' route to go, my guess is that even for
something
as simple as this it would be simpler and more effective than roll your
own (although it would probably be close).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org