Hi,

Jukka Zitting wrote:
Hi,

On Tue, Dec 8, 2009 at 8:53 PM,  <[email protected]> wrote:
--- 
pdfbox/trunk/src/main/java/org/apache/pdfbox/util/operator/SetNonStrokingSeparation.java
 (original)
+++ 
pdfbox/trunk/src/main/java/org/apache/pdfbox/util/operator/SetNonStrokingSeparation.java
 Tue Dec  8 19:53:17 2009
@@ -56,17 +56,10 @@
    {
        PDColorState colorInstance = 
context.getGraphicsState().getNonStrokingColor();
        PDColorSpace colorSpace = colorInstance.getColorSpace();
-        List<COSBase> argList = arguments;

-        if (colorSpace instanceof PDSeparation)
-        {
-            PDSeparation sep = (PDSeparation) colorSpace;
-            colorSpace = sep.getAlternateColorSpace();
-            argList = sep.getColorValues().toList();
-        }
-
        if (colorSpace != null)
        {
+            List<COSBase> argList = arguments;
            OperatorProcessor newOperator = null;
            if (colorSpace instanceof PDDeviceGray)
            {
@@ -91,6 +84,9 @@
            else if (colorSpace instanceof PDSeparation)
            {
                newOperator = new SetNonStrokingSeparation();
+                PDSeparation sep = (PDSeparation) colorSpace;
+                colorSpace = sep.getAlternateColorSpace();
+                argList = sep.getColorValues().toList();
            }

            if (newOperator != null)

I'm not exactly sure what goes wrong here, but I started getting a
StackOverflowException from the TestPDFToImage test case after this
change. I reverted this part of the code in revision 889752.
I wanted to simplify the code, but my changes are calling a new SetNonStrokingSeparation-operator within a SetNonStrokingSeparation-operator, which leads to a stack overflow because of the recursion. I've fixed the same issue in SetStrokingSeparation (890429) and another issue in SetStrokingColor (890428).

PS. TestPDFToImage still doesn't pass for me by default, and I only
noted this change of failure because I was looking at why the test
fails for me in the first place.
I had the same experience here on my linux box. Perhaps, it's a plattform dependent issue. The images are created by platform dependent code within the jdk and therefore probably not every created byte is the same on different platforms.

BR,

Jukka Zitting

BR
Andreas Lehmkühler

Reply via email to