Hi,
I have spent a bit of time investigating this issue and found that
the cause stems from a line of code in Batik. When the composite
graphic node is initially created it uses the following to determine
whether or not to create a clip associated with the object:
Class: org.apache.batik.bridge.CSSUtilities;
==================================
/**
* Returns true if the 'overflow' property indicates that an
* additional clip is required, false otherwise. An additional
* clip is needed if the 'overflow' property is 'scroll' or
* 'hidden'.
*
* @param e the element with the 'overflow' property
*/
public static boolean convertOverflow(Element e) {
Value v = getComputedStyle(e, SVGCSSEngine.OVERFLOW_INDEX);
String s = v.getStringValue();
return (s.charAt(0) == 'h') || (s.charAt(0) == 's');
}
==================================
As can be seen, because 'auto' and 'visible' do not match the two
characters in the method, the clip is left as null. Because of this,
much (much!) further down the line in FOP, a check is made and
because there is no clip the graphics state is left as it is (dashed)
and the line is drawn:
Class: org.apache.fop.svg.PDFGraphics2D.java:610
==================================
Shape imclip = getClip();
boolean newClip = paintingState.checkClip(imclip);
boolean newTransform = paintingState.checkTransform(trans)
&& !trans.isIdentity();
**if (newClip || newTransform) {
saveGraphicsState();
if (newTransform) {
concatMatrix(tranvals);
}
if (newClip) {
writeClip(imclip);
}
}
==================================
You'll notice that in the comment for the convertOverflow method, it
states that an additional clip is required for scroll or hidden, but
it is clearly not working correctly for anything except those two. It
might therefore be worth posting a bug or asking someone on their
mailing list to follow up and check to see if that method is doing
what it is supposed to.
Best Regards,
Robert Meyer
> Date: Tue, 29 May 2012 00:48:44 +0100
> From: [email protected]
> To: [email protected]
> Subject: Re: Wrong SVG "path" rendering caused by "overflow" attribute
>
>
> Thanks for the excellent test case! I will investigate if no else
does it.
>
> Note: incidentally your example does not run in fop-trunk due to a
> regression bug with formatting of doubles.
>
> On 5/28/12 3:04 AM, Jan Hilberath wrote:
> > Hello,
> >
> > I found that depending on the value of the "overflow" attribute, the
> > stroke of "path" elements may be rendered wrong.
> >
> > Having defined multiple paths, setting one of them to be dashed with
> > "stroke-dasharray" causes subsequent paths to be dashed too, if the
> > overflow attribute is set to "auto" or "visible".
> >
> > It seems to only happen when using the InputHandler.renderTo()
method.
> > I tried the following ways to render the SVG:
> >
> > 1) InputHandler.renderTo()
> > Draws the paths incorrectly, i.e. subsequent paths have dashed
stroke
> > when "auto" or "visible" is used.
> >
> > 2) PDFTranscoder.transcode()
> > Renders correctly.
> >
> > 3) Batik Squiggle
> > Renders correctly.
> >
> > Versions used:
> >
> > batik 1.7
> > fop 1.0
> > xmlgraphics-commons 1.4
> >
> > A sample maven project that demonstrates the issue is available here:
> >
> > http://www.hilberath.de/tmp/fop/svg_test.zip
> >
> > I would appreciate if someone could have a look at this.
> >
> > Thank you,
> >
> > Jan
>
