RE: request : optimising size of generated PNG by the SVG Rasteri zer

[Paul Hermans <pa...@protext.be>]

Thanks for the clarification but my reasoning is as follows.

The Batik rasterizer takes the SVG definitions (vectors) and generates a
bitmap out of it
(in our case a png).
Now this bitmap can be searched for the lowest left pixel different from the
background
and the highest right pixel different from the background.
Those two points can be used to define the width and the heigth of the png
with maybe a few pixels added at each side.

This is what the product WebEQ does going from MathML to PNG renditions of
mathematical formulas.
The width and height of the generated png is depending on the result of the
rendering of the formula.


Regards,


Paul


-----Original Message-----
From: Thierry Kormann [mailto:tkormann@ilog.fr]
Sent: maandag 16 juli 2001 8:57
To: Batik Users; Paul Hermans
Subject: Re: request : optimising size of generated PNG by the SVG
Rasterizer


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 Rasteri zer

[Thomas E Deweese <th...@kodak.com>]

>>>>> "PH" == Paul Hermans <pa...@protext.be> writes:

PH> Thanks for the clarification but my reasoning is as follows.  The
PH> Batik rasterizer takes the SVG definitions (vectors) and generates
PH> a bitmap out of it (in our case a png).  Now this bitmap can be
PH> searched for the lowest left pixel different from the background
PH> and the highest right pixel different from the background.  Those
PH> two points can be used to define the width and the heigth of the
PH> png with maybe a few pixels added at each side.

    You are missing a vitally important point, what is the user to
device transform for the outermost SVG element?  By changing that
transform the size of the bitmap can be changed.  You appear to be
assuming that this transform is 1:1 (or defaults to 1:1) which is a
bad assumption.  The transform is computed from the viewbox, width and
height attributes.

PH> This is what the product WebEQ does going from MathML to PNG
PH> renditions of mathematical formulas.  The width and height of the
PH> generated png is depending on the result of the rendering of the
PH> formula.

    I don't know much about MathML, but I'm guessing they are based
on Pt's (1/72nd of an inch), SVG is based on a completely scalable
coordinate system.  Now people who have done more work with the
viewbox stuff may be able to tell you how to indicate that the user to
device transform for the outer element should be 1:1, but I don't know
how to do that (it's a little antithetical to the SVG mentality).

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