>>>>> "PH" == Paul Hermans <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
