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 Paul Hermans <pa...@protext.be> on 2001/07/13 16:21:08 UTC

request : optimising size of generated PNG by the SVG Rasterizer

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.

The tool WebEQ does this when generating PNG from MathML.

Thanks for the help.

Paul

Pro Text
Paul Hermans
Leuvensesteenweg 282/c 
3190 Boortmeerbeek (Belgium)
+32 15 61 85 45
+32 15 62 03 99 (fax)
Paul_Hermans@protext.be

Re: request : optimising size of generated PNG by the SVG Rasterizer

Posted by Thierry Kormann <tk...@ilog.fr>.
On Friday 13 July 2001 16:21, 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.

Batik can not now what's the appropriate size as Peter mentions. This is due 
to the use of percentages for example. If a rectangle has a width equals to 
100% - what does it mean ?

You can let your outermost svg element with no width and height. By default 
it means 100%, 100% and it's up to the user agent to choose the size. The 
JSVGCanvas chooses the size of the component (depending on the layout manager 
and the size of your application). The transcoder has 400,400 (which is 
totally arbitrary) but you can set the default size using a transcoding hint.

Hope this helps,
Thierry.


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


Re: request : optimising size of generated PNG by the SVG Rasterizer

Posted by Peter Becker <pb...@meganesia.int.gu.edu.au>.
> 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?).

HTH,
  PeterB

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