Hi Thomas,
On Mar 2, 2006, at 9:11 PM, [EMAIL PROTECTED] wrote:
Hi Peter,
Peter Wagener <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
