xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Becker <pbec...@meganesia.int.gu.edu.au>
Subject Re: request : optimising size of generated PNG by the SVG Rasterizer
Date Sat, 14 Jul 2001 04:33:03 GMT
> Paul Hermans wrote:
> Dear all,
> I'm generating programmatically SVG from an SGML file.
> This is fairly straigthforward except for determining
> the attributes width, heigth and viewport on the svg element.
> as in : <svg width="4in" height="3in" viewBox="0 0 40 30">
> So i leave those undefined.
> concrete : <svg>
> When I run the rasterizer to PNG, this works of course.
> But these PNG's are much too large.
> Result: when included in HTML the layout does not look as hoped for.
> Would it be possible that the rasterizer would automatically generate
> an
> optimised image size when the attributes width and height are not
> available.

What do you mean by optimized size here? If you are not able to
determine the size of the image, how should Batik do it?

If you are using SVG rendering on the client side (i.e. Browser-Plugin
or feature) the renderer can know which size the image has to be and
render it in an appropriate size. But if you render on the server side
(and I assume you do this) there is no way of knowing the size for the
image directly. You could try to hack some callbacks to the server in
Javascript, this might work but is far from elegant for multiple
purposes (including the fact that you force people to use Javascript).

You can get some more flexibility if you use DOM to add the size later
in your process. For example: I generate buttons for HTML sites using
SVG and the size of the buttons is determined using the structure in my
program, then I add the two attributes [width] and [height] to the <svg>
element. But still they are of a fixed size, I just avoid redundancy
this way (the program supports different renderers and I need always the
size for the HTML generation).

So if I understood you correctly you are out of luck -- unless you want
to serve the SVG and let the client render, which is AFAIK only really
useful if you can assume that your clients run Windows and the Adobe
plugin (OT: can anyone give a short summary of the current state of SVG
support in Mozilla and other browsers?).


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

View raw message