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 George Armhold <ar...@cs.rutgers.edu> on 2004/07/30 01:04:39 UTC
NPE in SVGAbstractTranscoder.transcode after recent CVS updates
Hi,
I am finally getting around to updating my Batik CVS and testing
Thomas' recent fixes
(http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg04022.html)
and I found something that seems to have broken. My batik build is
the absolute latest from CVS.
My code does the following, which used to work prior to the new batik
changes: I install a doc in a JSVGComponent, allow the user to
interactively modify the doc. Then I load a new doc, and when I get a
managerStopped event, I know it's "safe" to access the old doc, using
the ImageTranscoder to rasterize it. When I do this, I get the
following stack trace:
java.lang.NullPointerException
at
org.apache.batik.bridge.SVGImageElementBridge.dispose(SVGImageElementBridge.java:716)
at
org.apache.batik.bridge.AbstractGraphicsNodeBridge.disposeTree(AbstractGraphicsNodeBridge.java:276)
at
org.apache.batik.bridge.AbstractGraphicsNodeBridge.disposeTree(AbstractGraphicsNodeBridge.java:279)
at
org.apache.batik.bridge.SVGUseElementBridge.buildCompositeGraphicsNode(SVGUseElementBridge.java:215)
at
org.apache.batik.bridge.SVGUseElementBridge.createGraphicsNode(SVGUseElementBridge.java:121)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:220)
at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:186)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:226)
at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:186)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:226)
at org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:186)
at org.apache.batik.bridge.GVTBuilder.build(GVTBuilder.java:108)
at
org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(SVGAbstractTranscoder.java:238)
at
org.apache.batik.transcoder.image.ImageTranscoder.transcode(ImageTranscoder.java:122)
at
org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(XMLAbstractTranscoder.java:174)
at
org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(SVGAbstractTranscoder.java:188)
at
edu.rutgers.elearning.util.SVGRasterizer.rasterizeSVG(SVGRasterizer.java:80)
at
edu.rutgers.elearning.presenter.DisplaySlideHelper._saveSlide(DisplaySlideHelper.java:240)
at
edu.rutgers.elearning.presenter.DisplaySlideHelper.access$200(DisplaySlideHelper.java:27)
at
edu.rutgers.elearning.presenter.DisplaySlideHelper$2.managerStopped(DisplaySlideHelper.java:122)
at org.apache.batik.swing.svg.JSVGComponent$9.run(JSVGComponent.java:1702)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
Could this be related to the recent memory leak fix in the
BridgeContext? Is watching for "managerStopped" no longer the
recommended way to determine when it's safe to access an unloaded doc?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: NPE in SVGAbstractTranscoder.transcode after recent CVS updates
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> The attached patch should fix two issues (including this one) I
> recently noticed with the last commit. Sorry for the regression.
The patch seems to work, thanks. It's good to have you back. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: NPE in SVGAbstractTranscoder.transcode after recent CVS updates
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi George,
The attached patch should fix two issues (including this one) I
recently noticed with the last commit. Sorry for the regression.
These and a few other changes will be in CVS shortly (perhaps
tonight, or over the weekend).
George Armhold wrote:
> Hi,
>
> I am finally getting around to updating my Batik CVS and testing
> Thomas' recent fixes
> (http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg04022.html)
> and I found something that seems to have broken. My batik build is
> the absolute latest from CVS.
>
> My code does the following, which used to work prior to the new batik
> changes: I install a doc in a JSVGComponent, allow the user to
> interactively modify the doc. Then I load a new doc, and when I get a
> managerStopped event, I know it's "safe" to access the old doc, using
> the ImageTranscoder to rasterize it. When I do this, I get the
> following stack trace:
>
> java.lang.NullPointerException
> at
> org.apache.batik.bridge.SVGImageElementBridge.dispose(SVGImageElementBridge.java:716)
>
> at
> org.apache.batik.bridge.AbstractGraphicsNodeBridge.disposeTree(AbstractGraphicsNodeBridge.java:276)
>
> at
> org.apache.batik.bridge.AbstractGraphicsNodeBridge.disposeTree(AbstractGraphicsNodeBridge.java:279)
>
> at
> org.apache.batik.bridge.SVGUseElementBridge.buildCompositeGraphicsNode(SVGUseElementBridge.java:215)
>
> at
> org.apache.batik.bridge.SVGUseElementBridge.createGraphicsNode(SVGUseElementBridge.java:121)
>
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:220)
> at
> org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:186)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:226)
> at
> org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:186)
> at
> org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:226)
> at
> org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:186)
> at org.apache.batik.bridge.GVTBuilder.build(GVTBuilder.java:108)
> at
> org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(SVGAbstractTranscoder.java:238)
>
> at
> org.apache.batik.transcoder.image.ImageTranscoder.transcode(ImageTranscoder.java:122)
>
> at
> org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(XMLAbstractTranscoder.java:174)
>
> at
> org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(SVGAbstractTranscoder.java:188)
>
> at
> edu.rutgers.elearning.util.SVGRasterizer.rasterizeSVG(SVGRasterizer.java:80)
>
> at
> edu.rutgers.elearning.presenter.DisplaySlideHelper._saveSlide(DisplaySlideHelper.java:240)
>
> at
> edu.rutgers.elearning.presenter.DisplaySlideHelper.access$200(DisplaySlideHelper.java:27)
>
> at
> edu.rutgers.elearning.presenter.DisplaySlideHelper$2.managerStopped(DisplaySlideHelper.java:122)
>
> at
> org.apache.batik.swing.svg.JSVGComponent$9.run(JSVGComponent.java:1702)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
> at
> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
>
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
>
> at
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
> at
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
>
>
> Could this be related to the recent memory leak fix in the
> BridgeContext? Is watching for "managerStopped" no longer the
> recommended way to determine when it's safe to access an unloaded doc?
>
> Thanks.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
Re: GVT Renderer
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Carsten,
This is not really a bug in GVT. There are two things you
are probably missing. The first is that the stroke is centered on the
outline of the shape. So in this case you have 1.5 pixels of stroke
inside the rect and 1.5 pixels of stroke outside the rect.
Your SVG element indicates that the area 0,0->110,110 should
be rendered. This fully includes the rectangle but only part
of the stroke. If you added 'viewBox="-1.5 -1.5 114 114"
(and upped width/height to 114) it would render your 3 pixel
stroke.
The reason you get a 2 pixel stroke on the left/top and
a 1 pixel stroke on the bottom/right is due to a bias that
the JDK introduces so that x=0 runs through the center of the
left most pixel in the display (this makes it so lines drawn
at integer locations aren't anti-aliased.
Carsten Birn wrote:
> Hi
>
> I think i found a bug in the Batik GVT Renderer.
>
> I have an example:
> - - - - - - - - - - - - - - - - - - - - -
> <svg
> version="1.0"
> width="111"
> height="111"
> id="rectangle"
> xmlns="http://www.w3.org/2000/svg">
>
> <rect
> x="0"
> y="0"
> width="111"
> height="111"
> fill="lightblue"
> stroke="black"
> stroke-width="3"
> />
> </svg>
> - - - - - - - - - - - - - - - - - - - - - -
> As attachment is a screenshot from Squiggle (Manipulated with Gimp)
> It shows that the top/left bound is 2px and the bottom/right is 1 px
> I had expected the rect stroke to be 3px. when i increas the total width/height in <SVG> the strokes changes but
> are still false.
>
> How can i determine the correct size of the above example?
> Any one with same experiences...?
>
> Carsten Birn
>
>
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
GVT Renderer
Posted by Carsten Birn <Ca...@rose.de>.
Hi
I think i found a bug in the Batik GVT Renderer.
I have an example:
- - - - - - - - - - - - - - - - - - - - -
<svg
version="1.0"
width="111"
height="111"
id="rectangle"
xmlns="http://www.w3.org/2000/svg">
<rect
x="0"
y="0"
width="111"
height="111"
fill="lightblue"
stroke="black"
stroke-width="3"
/>
</svg>
- - - - - - - - - - - - - - - - - - - - - -
As attachment is a screenshot from Squiggle (Manipulated with Gimp)
It shows that the top/left bound is 2px and the bottom/right is 1 px
I had expected the rect stroke to be 3px. when i increas the total width/height in <SVG> the strokes changes but
are still false.
How can i determine the correct size of the above example?
Any one with same experiences...?
Carsten Birn