>>>>> "CK" == Christian Kindler <[EMAIL PROTECTED]> writes:
CK> The problem is that this solution only works if all these values
CK> are set in the document's svg element. I am sorry if you
CK> misunderstood me, unfortunately my English is lousy.
The answer is that if you want to know the size of the document
without parsing everything (and interpreting most things - transforms,
clip, etc) you need to have the viewbox available.
CK> I will try to provide some more information to make my problem
CK> clear:
CK> I automatically generate SVG documents from little svg "snippets".
CK> In the resulting document these snippets are placed in a <defs>
CK> block and are referenced via <use> tags. A snippet can reference
CK> another snippet.
CK> A generated document may look like this:
CK> <svg> <g> ... <use xlink:href="#snippet1" x="100" y="100" /> ...
CK> </g>
CK> <defs> <g id="snippet1"> ... <use xlink:href="#snippet2" x="80"
CK> y="-90"/> </g> <g id="snippet2"> ... </g> </defs>
CK> So there are no viewBox, width, height, viewPort values for that
CK> document. The problem is, that depending on where a snippet is
CK> added (or at which coordinates the snippet which is referenced
CK> first begins), parts of the document are not visible because they
CK> are located in the negative area of my coordinate system. To
CK> adjust values like viewBox (and to add a dimension arrow without
CK> overlaying somthing) something, I need to know absolute top-left
CK> X, Y and bottom-right X, Y coordinates.
If you are constructing the document using Batik and you have the
GVT (rendering tree) around you can ask the root GraphicsNode for it's
bounding box. Otherwise, it is up to you to either keep track of this
as you go, or calculate it after the fact (perhaps by building the GVT
tree in Batik and asking the root graphics node for it's bounds).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
