What do you mean about the bytes not being the same on different platforms? Doesn't all code in PDFBox interact with the JVM, and then the JVM would have the platform specific code? The reason I ask is two fold: 1.) This seems to defeat the entire concept of Java code being platform independent. 2.) Because I'm compiling PDFBox in Windows and deploying to Linux and I haven't seen any issues and want to make sure it stays that way. If this means I should compile on Linux, then I will.
Thanks, Adam From: Andreas Lehmkuehler <[email protected]> To: [email protected] Date: 12/14/2009 10:56 Subject: Re: svn commit: r888550 - in /pdfbox/trunk/src/main/java/org/apache/pdfbox/util/operator: SetNonStrokingSeparation.java SetStrokingSeparation.java 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 ? Click here to submit conditions This email and any content within or attached hereto from Sun West Mortgage Company, Inc. is confidential and/or legally privileged. The information is intended only for the use of the individual or entity named on this email. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this email information is strictly prohibited, and that the documents should be returned to this office immediately by email. Receipt by anyone other than the intended recipient is not a waiver of any privilege. Please do not include your social security number, account number, or any other personal or financial information in the content of the email. Should you have any questions, please call (800) 453 7884.
