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
>

Reply via email to