Re: Wrong SVG "path" rendering caused by "overflow" attribute
I opened a bugzilla issue (with a fix) here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53431
A possible workaround that does not require a fix is to place the SVG
paths with no dasharrays at the top (i.e., before any dashed line).
On 6/13/12 12:43 AM, Luis Bernardo wrote:
This is a good investigation but I think it is not the final answer.
If instead of generating PDF we generate PS the output is correct, and
the same convertOverflow() method from Batik is called. Hence, I think
there is a bug in FOP (in the rendering of the PDF), not in Batik.
On 6/1/12 3:57 PM, Robert Meyer wrote:
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: lmpmberna...@gmail.com
> To: fop-dev@xmlgraphics.apache.org
> 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
>
Re: Wrong SVG "path" rendering caused by "overflow" attribute
This is a good investigation but I think it is not the final answer. If
instead of generating PDF we generate PS the output is correct, and the
same convertOverflow() method from Batik is called. Hence, I think there
is a bug in FOP (in the rendering of the PDF), not in Batik.
On 6/1/12 3:57 PM, Robert Meyer wrote:
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: lmpmberna...@gmail.com
> To: fop-dev@xmlgraphics.apache.org
> 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
>
RE: Wrong SVG "path" rendering caused by "overflow" attribute
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: lmpmberna...@gmail.com
> To: fop-dev@xmlgraphics.apache.org
> 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
>
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
