I have a Swing program that tries to load several SVG documents using several JSVGCanvases at the same time. These images all have within them some <image> tags that import the same other external SVG documents. Sample import: <image x="2214.0" y="9.0" transform="scale(0.5)" width="313.0" xlink:href="../images/logo1.svg" height="163.0" preserveAspectRatio="xMaxYMax meet"/> When loading these documents at the same time, it appears there is some sort of race condition that causes the exception below from all the images, and they all fail to load. Note that the <image>'s URL references an SVG file, so I'm not sure why Toolkit.createImage() is being used (as it appears) but I don't understand the inner workings. 2006-07-11 19:31:56,991 [AWT-EventQueue-0] ERROR: BasicUserAgent Error: org.apache.batik.bridge.BridgeException: http://test1.example.com/maps/map1.svg.gz:-1 The URI "http://test1.example.com/imgs/../test/logo1.svg" on element <image> can't be opened because: JDK URL is corrupt or unsupported variant at org.apache.batik.swing.svg.JSVGComponent$BridgeUserAgent.getBrokenLinkDocument(Unknown Source) at org.apache.batik.swing.svg.JSVGComponent$26Query.run(Unknown Source) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199) at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) Notes: - This only occurs when multiple JSVGCanvases are attempting to load and build their documents at the same time. - This only occurs when the imported file is SVG. When I rasterize it to PNG and import that instead, the problem goes away. This seems like it must be a bug in Batik's document caching subsystem.
Does this problem still occur? If so, could you provide a small standalone test? The document caching code does synchronise on accesses to the cache, so it's not immediately obvious to me where the problem lies.
I haven't seen this happen lately; however, a very similar problem was just reported today on the batik-users mailing list... perhaps this could be another manifestation of the same problem? Note this posting seems to imply a simple way to reproduce the bug: http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/200709.mbox/%3c759ff3b10709250407y6949716aq9397fe9bbff611bf@mail.gmail.com%3e
I can confirm that this bug still occurs. I get the 'URL is corrupt or unsupported variant' error when I have a transparent png between 7.32mb and 7.79mb. Every png under 7.32mb worked. Bumping the size up just a bit to 7.79mb caused batik to fail. All of my tests seemed to show the issue was size related.
My suspcion is that you are simply running out of memory. How large (in pixels) is the PNG image? By default Java only allows it's self to allocate ~64MB of memory. This can be changed with the -Xmx command line option to java.
I have noticed that Batik takes ALOT of memory, so comment # 3 above occurred with batik having 1 GB of memory allocated to it. The PNG was 5184px x 2592px. (In reply to comment #4) > My suspcion is that you are simply running out of memory. > How large (in pixels) is the PNG image? > By default Java only allows it's self to allocate ~64MB > of memory. This can be changed with the -Xmx command line > option to java. >