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 "K. W. Landry" <kw...@gmail.com> on 2006/11/14 21:56:56 UTC
Is this still necessarily true?
http://www.aditus.nu/jpgraph/jpg_svg.php
Summary of findings To our surprise we have to conclude that with the
current SVG standard 1.1 as well as with the upcoming 1.2 (based on SVG-T)
it will not be possible to implement a full backend in SVG.
The primary hinder is the lack of adequate text manipulation in the current
SVG standard. In addition the implementation of the text supporting feature
in current SVG viewers range from poor and erroneous to non-existing.
The only way to solve this would be to drastically reduce some functionlity
of the library in regards to text handling and require the user of the
library to supply text sizes to be used in many places of the library where
that is needed.
Re: is it possible to speed up / reduce memory usage of rasterization ?
Posted by th...@kodak.com.
Hi JD,
benamou jean-david <je...@inria.fr> wrote on 11/14/2006
04:34:51 PM:
> I am using Batik on a server to rasterize svg content.
> i am doing
> java -Mmx128M -jar batik-rasterizer -m image/png ..etc
> The Xmx option is needed for big SVG files ...
> Is it possible to reduce the memory requirements and
> speed up the rasterization and how ?
For large files you might look at the TiledTiffTranscoder
(in the contrib directory). Unfortunately it outputs Tiff not
PNG but it is much easier on the memory. As for speed if you
are invoking Java for each rasterization you are probably
spending the vast majority of your time bringing up the JVM.
Java really works best if you bring it up once and keep it
up servicing multiple requests, I would suggest using something
like Tomcat (a java servlet engine).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
is it possible to speed up / reduce memory usage of rasterization ?
Posted by benamou jean-david <je...@inria.fr>.
Hi
I am using Batik on a server to rasterize svg content.
i am doing
java -Mmx128M -jar batik-rasterizer -m image/png ..etc
The Xmx option is needed for big SVG files ...
Is it possible to reduce the memory requirements and
speed up the rasterization and how ?
Thanks
JD
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Is this still necessarily true?
Posted by th...@kodak.com.
Hi Cameron, K.W.,
I would actually push back on what they say. What they are asking for
is
a parametric layout system, it is true that SVG does not provide one
natively
(one could potentially be built with script). While a parametric layout
system
would be way cool and I personally think the only way to make SVG 'truely
scalable' it is total overkill for static output of a graph.
For what they want all they need to do it make use of a tool like
Batik
to calculate text bounding boxes and to embed SVG font's in the output.
Embedding fonts has _long_ been the solution to accurate reproduction
of
text across many clients. What they are asking for may be interesting but
is
way beyond what any other output format I am aware of provides.
They can use Batik as an engine to calculate the bbox of text rendered
with
the required SVG font. While there could be some small differences in
rendering
between viewers for a given SVG font the differences should be on the
order of
fractional pixels per char.
Cameron McCormack <ca...@mcc.id.au> wrote on 11/14/2006 04:34:16 PM:
> K. W. Landry:
> > http://www.aditus.nu/jpgraph/jpg_svg.php
>
> Their central claim:
>
> With the current SVG 1.1 (and draft 1.2) standard there is no way to
> statically find out the bounding box of an arbitrary text string for
> later usage in the SVG script.
>
> is true, if you do not embed fonts into the document. I agree that it
> makes it difficult to generate static documents from dynamic content,
> and be sure of exactly how much space text will take up. Which is a
> shame, since font fallback is meant to be a feature of SVG, but without
> some way to adapt the layout, it?s mostly useless.
>
> --
> Cameron McCormack, http://mcc.id.au/
> xmpp:heycam@jabber.org ? ICQ 26955922 ? MSN cam@mcc.id.au
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Is this still necessarily true?
Posted by Cameron McCormack <ca...@mcc.id.au>.
K. W. Landry:
> http://www.aditus.nu/jpgraph/jpg_svg.php
Their central claim:
With the current SVG 1.1 (and draft 1.2) standard there is no way to
statically find out the bounding box of an arbitrary text string for
later usage in the SVG script.
is true, if you do not embed fonts into the document. I agree that it
makes it difficult to generate static documents from dynamic content,
and be sure of exactly how much space text will take up. Which is a
shame, since font fallback is meant to be a feature of SVG, but without
some way to adapt the layout, it’s mostly useless.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org