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 Peter Wagener <pe...@hypoluxo.com> on 2006/03/02 15:17:31 UTC

Combining SVG documents?

Hi All,

I'm working on an application where one of the new features allows  
the user to see the physical representation of the chunk of hardware  
they have sitting in their datacenter rack.  We have several  
different SVG files we are using to represent the various pieces of  
the hardware (one for the chassis, one for a "blade" that goes into  
the chassis in various slots, etc etc).

This is my initial foray into the world of SVG and Batik, but my  
initial approach to building up the combined image was:

1.  Load the initial SVG document (the chassis)
2.  Load in the rest of the pieces
3.  Get the root element of each component piece
4.  Import, position, and append that piece into the initial document

So, the code I'm using for that looks something like:

Document chassisDoc = ...
Document subDoc = ...

Element subElement = subDoc.getDocumentElement();
subElement = (Element) chassisDoc.importNode(subElement, true);

// Not shown: Position the sub-element at the right spot in the  
chassisDoc

Element chassisElement = chassisDoc.getDocumentElement();
chassisElement.appendChild(subElement)


This works, but I'm a little worried about performance.  The  
documents themselves are on the large side: the chassis is ~2MB, the  
sub-documents are between 200KB and 1MB.  It's possible that a  
chassis may have up to 20 - 30 components on the high side.  Also, a  
more recent test of this technique was throwing BridgeException's at  
seemingly random times on one of the many the 'appendChild' calls.

Is there a better way to accomplish this?  I've looked into using  
Overlay's, but am struggling with how I would draw an SVG from the  
Overlay's 'paint(...)' method.  I've also thought of rasterizing the  
SVG of each component, and drawing that way from within an Overlay,  
but would I then lose the ability to zoom in & out?  Any code  
snippets I could look at that do similar things?



Many thanks for your time,

Peter

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


Re: Combining SVG documents?

Posted by Peter Wagener <pe...@hypoluxo.com>.
Hi Thomas,

On Mar 5, 2006, at 3:34 PM, thomas.deweese@kodak.com wrote:
[...]
>> This app will eventually be delivered with the images inside
>> a JAR... how  messy is it to reference the PNG image as a
>> URL inside a JAR file?
>
>    It's simple, Batik is happy to decode 'jar:' protocol
> URLs.  You can get one from ClassLoader.findResource(String).

Excellent; I was hoping it'd be that easy!

>
>> I then load an SVG document, add an
>> event listener to the SVG's element, and append it to the document.
>> The event listener responds correctly.  Here's the generated SVG file
>> (with internal elements & encoded PNG data stripped out):
>
> [...]
>
>> The second situation is very similar: I create the same SVG document
>> with the initial embedded PNG image.  I then load another PNG as an
>> <image>, add an instance of the same event listener to the PNG's
>> element, then add that element to the document.  The event listener
>> doesn't respond at all.  Here's the generated SVG for that situation
>> (with the embedded PNG data stripped out):
>
>    I suspect that there is something subtle wrong with the creation
> and addition of the Listener, but I would have to see the code that
> creates the second image element and adds the listener to know.
> The structure of the document shouldn't really matter (unless you did
> something really silly like put 'pointer-events="none"' on the
> image element).

You're right -- something is odd with that code.  I haven't tracked  
down the issue in my little test application, but the real  
application has similar code that is working just fine.  I should be  
able to figure it out where I went wrong in the test app myself at  
some point.

Thanks again for all your help.  I'd like to put together a tutorial  
on these topics, and use my test application as the example.   
Assuming I can convince my client to let me use that code, I'll  
package it up & let the list know when I've done a first pass at it.


Peter

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


Re: Combining SVG documents?

Posted by th...@kodak.com.
Hi Peter,

Peter Wagener <pe...@hypoluxo.com> wrote on 03/05/2006 01:39:11 
PM:

> >    Just a comment, it would be much better to have the build up
> > SVG file reference the PNG file as a separate file rather than
> > encoding the File as Base64 and embedding.
> 
> Because of the memory requirements to not have that PNG floating 
> around as a String?  That makes sense. 

    Well also just the time to encode/decode the whole PNG as
base64.  Also there will be a couple of copies of the base64
string in the App (one in the DOM one in the ParseURL, etc).

> This app will eventually be delivered with the images inside 
> a JAR... how  messy is it to reference the PNG image as a 
> URL inside a JAR file?

   It's simple, Batik is happy to decode 'jar:' protocol
URLs.  You can get one from ClassLoader.findResource(String).

> >> Also, I've noticed I'm not able to attach event listeners to image
> >> elements in the same way I was with SVG elements.  Is there a
> >> difference in how those should be treated?
> >
> >    No.  Event listeners should work just the same on an image element
> > as on anything else.
> 
> I'm not sure if I broke it or not... I don't think so :)  What 
> confuses me is I have two very similar situations, except one is 
> using an <svg> node and the other is using an <image>.

> I then load an SVG document, add an 
> event listener to the SVG's element, and append it to the document. 
> The event listener responds correctly.  Here's the generated SVG file 
> (with internal elements & encoded PNG data stripped out):

[...]

> The second situation is very similar: I create the same SVG document 
> with the initial embedded PNG image.  I then load another PNG as an 
> <image>, add an instance of the same event listener to the PNG's 
> element, then add that element to the document.  The event listener 
> doesn't respond at all.  Here's the generated SVG for that situation 
> (with the embedded PNG data stripped out):

   I suspect that there is something subtle wrong with the creation
and addition of the Listener, but I would have to see the code that
creates the second image element and adds the listener to know.
The structure of the document shouldn't really matter (unless you did
something really silly like put 'pointer-events="none"' on the
image element).


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


Re: Combining SVG documents?

Posted by Peter Wagener <pe...@hypoluxo.com>.
Hello Thomas,

On Mar 5, 2006, at 6:58 AM, thomas.deweese@kodak.com wrote:

> Peter Wagener <pe...@hypoluxo.com> wrote on 03/05/2006  
> 12:37:24
> AM:
>
>> I'm having trouble getting the initial embedded PNG to size itself
>> correctly when setting the original document on the JSVGCanvas.  The
>> image is larger than the initial size of the canvas, but it doesn't
>> scale down correctly.  Instead, I only see the upper-left corner  
>> of it.
>
>> Interestingly enough, if I first set an SVG file as the document (I
>> created a blank SVG file in Illustrator), then append PNG's to that,
>> they are sized correctly.  Apparently I'm not creating my initial
>> document correctly ... ?
>
>    The problem is that you aren't providing width/height/viewBox on
> the outermost SVG element.  I'm guessing your initial document
> from Illustrator had those in it already.

Excellent -- adding the viewbox, height & width elements makes  
everything work just fine.  For future readers' sake, here's some  
code that loads a PNG image from a file, create a blank SVG document,  
then embed the PNG image into it:

<code>


// Load the PNG from the file
FileInputStream fileIn = new FileInputStream(inputFile);
PNGImageDecoder decoder = new PNGImageDecoder(fileIn, null);
RenderedImage image = decoder.decodeAsRenderedImage();
fileIn.close();

// Create the empty SVG document
DOMImplementation impl = SVGDOMImplementation.getDOMImplementation();
Document document = impl.createDocument(SVG_NS, "svg", null);
Element svgRoot = document.getDocumentElement();

// Set the initial attributes of the SVG Root element
int height = image.getHeight();
int width = image.getWidth();
svgRoot.setAttributeNS(null, "viewBox", "0 0 " + width +
         " " + height);
svgRoot.setAttributeNS(null, "width", String.valueOf(width));
svgRoot.setAttributeNS(null, "height", String.valueOf(height));

// Create the PNG image element
Element imgElement = document.createElementNS(SVG_NS, "image");
imgElement.setAttributeNS(null, "width", String.valueOf(image.getWidth 
()));
imgElement.setAttributeNS(null, "height", String.valueOf 
(image.getHeight()));

// Encode the PNG into a base-64 string
ByteArrayOutputStream outStream = new ByteArrayOutputStream();
Base64EncoderStream b64Encoder = new Base64EncoderStream(outStream);

ImageEncoder encoder = new PNGImageEncoder(b64Encoder, null);
try {
     encoder.encode(image);
     b64Encoder.close();
} catch (IOException e) {
     e.printStackTrace();
}

// Set the b-64 data in the image element
imgElement.setAttributeNS(XLINK_NAMESPACE_URI, ATTR_XLINK_HREF,
         DATA_PROTOCOL_PNG_PREFIX + outStream.toString());

svgRoot.appendChild(imgElement);

JSVGCanvas canvas = new JSVGCanvas();
canvas.setDocument(document);

</code>

>
>    Just a comment, it would be much better to have the build up
> SVG file reference the PNG file as a separate file rather than
> encoding the File as Base64 and embedding.

Because of the memory requirements to not have that PNG floating  
around as a String?  That makes sense.  This app will eventually be  
delivered with the images inside a JAR... how  messy is it to  
reference the PNG image as a URL inside a JAR file?

>
>> Also, I've noticed I'm not able to attach event listeners to image
>> elements in the same way I was with SVG elements.  Is there a
>> difference in how those should be treated?
>
>    No.  Event listeners should work just the same on an image element
> as on anything else.  Did you perhaps break having the document be
> dynamic in the Canvas?

I'm not sure if I broke it or not... I don't think so :)  What  
confuses me is I have two very similar situations, except one is  
using an <svg> node and the other is using an <image>.  Sorry for the  
lengthy description below, but I want to make sure I describe what  
I'm seeing correctly.

In the first situation, I create an SVG document with an embedded PNG  
image (as described above).  I then load an SVG document, add an  
event listener to the SVG's element, and append it to the document.   
The event listener responds correctly.  Here's the generated SVG file  
(with internal elements & encoded PNG data stripped out):

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.0//EN' 'http://www.w3.org/TR/ 
2001/REC-SVG-20010904/DTD/svg10.dtd'>

<svg contentScriptType="text/ecmascript"
width="599"
xmlns:xlink="http://www.w3.org/1999/xlink"
zoomAndPan="magnify"
contentStyleType="text/css"
height="773"
viewBox="0 0 599 773"
preserveAspectRatio="xMidYMid meet"
xmlns="http://www.w3.org/2000/svg"
xml:base=""
version="1.0">


<image width="599"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="data:image/png;base64,iVBORw0..."
xlink:type="simple"
xlink:actuate="onLoad"
height="773"
preserveAspectRatio="xMidYMid meet"
xlink:show="embed"/>


<svg contentScriptType="text/ecmascript"
zoomAndPan="magnify"
xmlns:xlink="http://www.w3.org/1999/xlink"
contentStyleType="text/css"
xmlns:x="http://ns.adobe.com/Extensibility/1.0/"
enable-background="new 0 0 35.162 463.158"
version="1.1" width="35.162"
xml:space="preserve"
xmlns:graph="http://ns.adobe.com/Graphs/1.0/"
preserveAspectRatio="xMidYMid meet"
viewBox="0 0 35.162 463.158"
height="463.158"
xmlns="http://www.w3.org/2000/svg"
xmlns:i="http://ns.adobe.com/AdobeIllustrator/10.0/"
x="42"
overflow="visible"
y="200">

...
</svg>

</svg>


The second situation is very similar: I create the same SVG document  
with the initial embedded PNG image.  I then load another PNG as an  
<image>, add an instance of the same event listener to the PNG's  
element, then add that element to the document.  The event listener  
doesn't respond at all.  Here's the generated SVG for that situation  
(with the embedded PNG data stripped out):


<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.0//EN' 'http://www.w3.org/TR/ 
2001/REC-SVG-20010904/DTD/svg10.dtd'>

<svg contentScriptType="text/ecmascript"
width="599"
xmlns:xlink="http://www.w3.org/1999/xlink"
zoomAndPan="magnify"
contentStyleType="text/css"
height="773"
viewBox="0 0 599 773"
preserveAspectRatio="xMidYMid meet"
xmlns="http://www.w3.org/2000/svg"
xml:base=""
version="1.0">


<image width="599"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="data:image/png;base64,iVBORw0...."
xlink:type="simple"
xlink:actuate="onLoad"
height="773"
preserveAspectRatio="xMidYMid meet"
xlink:show="embed"/>


<image width="35"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="data:image/png;base64,iVBORw0KG...."
xlink:type="simple"
xlink:actuate="onLoad"
height="463"
preserveAspectRatio="xMidYMid meet"
xlink:show="embed" />

</svg>


Anything look wrong to you about situation #2?  This seems to be my  
last snag.  Any other tips you can give would be greatly appreciated.


Thanks again,

Peter

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


Re: Combining SVG documents?

Posted by th...@kodak.com.
Hi Peter,

> On Mar 4, 2006, at 8:29 AM, thomas.deweese@kodak.com wrote:
> 
> >> How about this for an alternative:
> >>
> >> 1.  Convert all the SVG's to PNG files
> >> 2.  Add them to a document as <image> elements
> >
> >    This is certainly a viable alternative.

Peter Wagener <pe...@hypoluxo.com> wrote on 03/05/2006 12:37:24 
AM:

> I'm having trouble getting the initial embedded PNG to size itself 
> correctly when setting the original document on the JSVGCanvas.  The 
> image is larger than the initial size of the canvas, but it doesn't 
> scale down correctly.  Instead, I only see the upper-left corner of it.

> Interestingly enough, if I first set an SVG file as the document (I 
> created a blank SVG file in Illustrator), then append PNG's to that, 
> they are sized correctly.  Apparently I'm not creating my initial 
> document correctly ... ?

   The problem is that you aren't providing width/height/viewBox on
the outermost SVG element.  I'm guessing your initial document 
from Illustrator had those in it already.

   Just a comment, it would be much better to have the build up
SVG file reference the PNG file as a separate file rather than
encoding the File as Base64 and embedding.

> Also, I've noticed I'm not able to attach event listeners to image 
> elements in the same way I was with SVG elements.  Is there a 
> difference in how those should be treated?

   No.  Event listeners should work just the same on an image element
as on anything else.  Did you perhaps break having the document be
dynamic in the Canvas?



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


Re: Combining SVG documents?

Posted by Peter Wagener <pe...@hypoluxo.com>.
Hi Thomas,

On Mar 4, 2006, at 8:29 AM, thomas.deweese@kodak.com wrote:

>> How about this for an alternative:
>>
>> 1.  Convert all the SVG's to PNG files
>> 2.  Add them to a document as <image> elements
>
>    This is certainly a viable alternative.

I'm giving this a shot for now; if it ends up not panning out I'll  
feel like I've done due diligence when I go back to the graphics  
folks to ask them to simplify the SVG images.

I'm having trouble getting the initial embedded PNG to size itself  
correctly when setting the original document on the JSVGCanvas.  The  
image is larger than the initial size of the canvas, but it doesn't  
scale down correctly.  Instead, I only see the upper-left corner of it.

Here's the code:

<snip>

// Load the PNG from the file
FileInputStream fileIn = new FileInputStream(inputFile);

PNGImageDecoder decoder = new PNGImageDecoder(fileIn, null);
RenderedImage image = decoder.decodeAsRenderedImage();
fileIn.close();

// Create the document & the image element
DOMImplementation impl = SVGDOMImplementation.getDOMImplementation();
Document document = impl.createDocument(SVG_NS, "svg", null);

Element imgElement = document.createElementNS(SVG_NS, "image");

imgElement.setAttributeNS(null, "x", "0");
imgElement.setAttributeNS(null, "y", "0");
imgElement.setAttributeNS(null, "width", String.valueOf(image.getWidth 
()));
imgElement.setAttributeNS(null, "height", String.valueOf 
(image.getHeight()));

// Encode the PNG into the element
ByteArrayOutputStream outStream = new ByteArrayOutputStream();
Base64EncoderStream b64Encoder = new Base64EncoderStream(outStream);

ImageEncoder encoder = new PNGImageEncoder(b64Encoder, null);
try {
     encoder.encode(image);
     b64Encoder.close();
} catch (IOException e) {
     e.printStackTrace();
}

imgElement.setAttributeNS(XLINK_NAMESPACE_URI,
                     ATTR_XLINK_HREF,
                     DATA_PROTOCOL_PNG_PREFIX + outStream.toString());

// Attach the new element to the empty document
Element svgRoot = document.getDocumentElement();
svgRoot.appendChild(imgElement);

// Set the document on the canvas
JSVGCanvas canvas = gui.getCanvas();
canvas.setDocument(document);

</snip>


Interestingly enough, if I first set an SVG file as the document (I  
created a blank SVG file in Illustrator), then append PNG's to that,  
they are sized correctly.  Apparently I'm not creating my initial  
document correctly ... ?

Also, I've noticed I'm not able to attach event listeners to image  
elements in the same way I was with SVG elements.  Is there a  
difference in how those should be treated?


Again, thanks for your time,

Peter

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


Re: Combining SVG documents?

Posted by th...@kodak.com.
Hi Peter,

Peter Wagener <pe...@hypoluxo.com> wrote on 03/04/2006 01:36:00 
AM:

> >> Also, a more recent test of this technique was throwing
> >> BridgeException's at seemingly random times on one of the
> >> many the 'appendChild' calls.

> On Mar 2, 2006, at 9:11 PM, thomas.deweese@kodak.com wrote:

> >     What sort of bridge exception?  Out of Memory?
> 
> It's complaining about a CSS property on a <g> element being 
> invalid.  Here's the top of the stack trace:
> 
> org.apache.batik.bridge.BridgeException:
> file:/C:/temp/trident7-classes/com/W7Optics/AppClient/LMSView/shelf/ 
> drawing/T7Chassis.svg:0
> The URI "file:/C:/temp/trident7-classes/com/W7Optics/AppClient/ 
> LMSView/shelf/drawing/T7Chassis.svg#XMLID_1_"
> for a CSS property found on the element <g> is invalid
>    at org.apache.batik.bridge.CSSUtilities.convertMask(Unknown Source)

   It looks like something is 'missing' from the Document.  My 
guess from what I know is that you are copying a subtree from 
one document and appending it to another.  In the subtree you 
are copying is something like:

        mask="url(#XMLID_1_)" 

   Somewhere else in that source document is a mask element with
id="XMLID_1_".  For your copy/append to work you would have to
also copy the elements the subtree references or potentially use
xml:base to redirect URL references back to the originating doc.

   Given your situation you might look into using the 'use' element 
from SVG, or an 'image' element referencing an SVG file.

> Just for kicks, I ran the Batik Rasterizer app on a few of the SVG 
> files with the "-validate" flag; it wasn't too happy with them, so 
> apparently they're not strict SVG.

   From Illustrator they won't be "clean", but that doesn't mean they
are really bad.  Illustrator is pretty good about putting it's stuff
in a private namespace.  This won't validate against the DTD but _is_
legal SVG (basically DTD isn't powerful enough to really capture the
rules).

> Because of the exception I was seeing above, I wasn't sure if the 
> 'appendChild' method above was the best way to handle the situation. 
> I figured if I could just overlay the SVG versus combining it, maybe 
> I'd limit my issues.

   If you can use the 'use' or 'image' element to pull in the external
reference that is probably better than the appendChild approach.

> >    I would look at simplifying the graphics I have a hard
> > time understanding why these elements would need to be so
> > detailed...
> 
> Yeah, I suppose they really don't need to be.  But getting that point 
> across to the graphic designers might be tough. 

   It might be, but I would suggest that they go for a 'minimalist'
approach rather than 'photo-realistic'.  A few simple gradients, simple
line art, etc...

> How about this for an alternative:
> 
> 1.  Convert all the SVG's to PNG files
> 2.  Add them to a document as <image> elements

   This is certainly a viable alternative.

> 3.  Register an UpdateManagerListener whose job is to change the size 
> of the images on the fly.

   Why are you changing the size of the image elements?  The
SVG engine will resize the images as needed for display.

> Would that work?  What would be the best way to scale the image 
> elements appropriately?

  Just like everything else in SVG the image element will keep
it's size relative to everything else as you zoom in/out.  At some
point the graphic may turn pixilated.  You can either live with this
or you might choose to use the 'multiImage' element which allows
you to reference multiple versions of the 'image' to use at 
different magnifications (the highest level could be a reference
to an SVG file for example), take a look at
        samples/tests/spec12/structure/multi.svg

> It feels like a hack, and it does kinda beg the question of why I'd 
> use Batik in the first place.  But the ability to move the image and 
> scale it is a big hit with any users that see it.

   From your application point of view it shouldn't make much of a
difference if the content is SVG or raster images, it's just that
with raster images you need to manage the resolution issue (remember
that you could limit the zoom in, for your application so you don't
have to go overboard with the size of the images).



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


Re: Combining SVG documents?

Posted by Peter Wagener <pe...@hypoluxo.com>.
Hi Thomas,

On Mar 2, 2006, at 9:11 PM, thomas.deweese@kodak.com wrote:

> Hi Peter,
>
> Peter Wagener <pe...@hypoluxo.com> wrote on 03/02/2006  
> 09:17:31
> AM:
>
>> This works, but I'm a little worried about performance.  The
>> documents themselves are on the large side: the chassis is ~2MB, the
>> sub-documents are between 200KB and 1MB.  It's possible that a
>> chassis may have up to 20 - 30 components on the high side.
>
>    Why so large?  Given the stated purpose I would have expected
> the rack to be a fairly simple.  Similarly for the sub documents.

The original SVG came from the hardware folks' CAD design tools.   
They then passed through a few graphic artists' hands to spruce them  
up in Adobe Illustrator.  I'm not entirely sure which of those two  
camps added the most bulk!

>
>> Also, a more recent test of this technique was throwing
>> BridgeException's at seemingly random times on one of the
>> many the 'appendChild' calls.
>
>     What sort of bridge exception?  Out of Memory?

It's complaining about a CSS property on a <g> element being  
invalid.  Here's the top of the stack trace:

org.apache.batik.bridge.BridgeException:
file:/C:/temp/trident7-classes/com/W7Optics/AppClient/LMSView/shelf/ 
drawing/T7Chassis.svg:0
The URI "file:/C:/temp/trident7-classes/com/W7Optics/AppClient/ 
LMSView/shelf/drawing/T7Chassis.svg#XMLID_1_"
for a CSS property found on the element <g> is invalid
	at org.apache.batik.bridge.CSSUtilities.convertMask(Unknown Source)
	at  
org.apache.batik.bridge.AbstractGraphicsNodeBridge.buildGraphicsNode 
(Unknown Source)
	at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
	at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
	at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
	at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
	at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
	at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
	at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
	at org.apache.batik.bridge.SVGGElementBridge.handleElementAdded 
(Unknown Source)
	at  
org.apache.batik.bridge.SVGGElementBridge.handleDOMNodeInsertedEvent 
(Unknown Source)
	at org.apache.batik.bridge.BridgeContext 
$DOMNodeInsertedEventListener.handleEvent(Unknown Source)
....

Just for kicks, I ran the Batik Rasterizer app on a few of the SVG  
files with the "-validate" flag; it wasn't too happy with them, so  
apparently they're not strict SVG.

>
>> Is there a better way to accomplish this?  I've looked into using
>> Overlay's, but am struggling with how I would draw an SVG from the
>> Overlay's 'paint(...)' method.
>
>    Well you might be able to call the 'paint' method on the root of
> a GVT tree.  But I'm not sure what you are hoping to save here?

Because of the exception I was seeing above, I wasn't sure if the  
'appendChild' method above was the best way to handle the situation.   
I figured if I could just overlay the SVG versus combining it, maybe  
I'd limit my issues.

>
>> Any code snippets I could look at that do similar things?
>
>    I would look at simplifying the graphics I have a hard
> time understanding why these elements would need to be so
> detailed...

Yeah, I suppose they really don't need to be.  But getting that point  
across to the graphic designers might be tough.  How about this for  
an alternative:

1.  Convert all the SVG's to PNG files
2.  Add them to a document as <image> elements
3.  Register an UpdateManagerListener whose job is to change the size  
of the images on the fly.

Would that work?  What would be the best way to scale the image  
elements appropriately?

It feels like a hack, and it does kinda beg the question of why I'd  
use Batik in the first place.  But the ability to move the image and  
scale it is a big hit with any users that see it.


Thanks again,

Peter

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


Re: Combining SVG documents?

Posted by th...@kodak.com.
Hi Peter,

Peter Wagener <pe...@hypoluxo.com> wrote on 03/02/2006 09:17:31 
AM:

> This works, but I'm a little worried about performance.  The 
> documents themselves are on the large side: the chassis is ~2MB, the 
> sub-documents are between 200KB and 1MB.  It's possible that a 
> chassis may have up to 20 - 30 components on the high side. 

   Why so large?  Given the stated purpose I would have expected
the rack to be a fairly simple.  Similarly for the sub documents.

> Also, a more recent test of this technique was throwing 
> BridgeException's at seemingly random times on one of the 
> many the 'appendChild' calls.

    What sort of bridge exception?  Out of Memory?

> Is there a better way to accomplish this?  I've looked into using 
> Overlay's, but am struggling with how I would draw an SVG from the 
> Overlay's 'paint(...)' method.

   Well you might be able to call the 'paint' method on the root of
a GVT tree.  But I'm not sure what you are hoping to save here?

> I've also thought of rasterizing the SVG of each component, and 
> drawing that way from within an Overlay, but would I then lose 
> the ability to zoom in & out?

   You could render the component to a BufferedImage at the start
of the 'drag' operation and then just draw that.  You might need to
be careful that your BufferedImage didn't get too large.

> Any code snippets I could look at that do similar things?

   I would look at simplifying the graphics I have a hard
time understanding why these elements would need to be so
detailed...



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