>>Finally I think TestPDFToImage isn't really useful in different environments, we are comparing apples and oranges.
This is likely true. In fact, we've seen some tests fail when byte-level changes occur due to code changes ... but there is no difference that the human eye can detect. When I created that test I considered using a Perceptual Difference tool to compare the files, rather than a byte-for-byte comparison. One such tool is at http://pdiff.sourceforge.net/ . For a while the byte-for-byte comparison worked well enough. Perhaps we should go to PDiff or something similar. That's more complicated but likely more accurate for our purposes -- making sure that an improvement to one rendering doesn't mess up others. Daniel Wilson On Tue, Dec 15, 2009 at 1:40 PM, Andreas Lehmkuehler <[email protected]>wrote: > Hi, > > [email protected] wrote: > >> 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. >> > The Java code is platform independent, but the implementation of the jdk > isn't. Some parts of a jdk are written in java, but others are written in > other languages (mostly C, I guess) and are using system dependent > libraries, e.g. Java2D, IO etc. Furthermore not only sun publishes jdks for > different platforms, there is/was also apple, oracle, ibm and .... > Regarding our example, every jdk will create an image which (hopefully) > looks the same on each platform, but at a byte-level I doubt every image is > the same. Finally I think TestPDFToImage isn't really useful in different > environments, we are comparing apples and oranges. > > 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. >> > As I said above, regarding the java code everything is fine. > > 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 >> > > BR > Andreas Lehmkühler >
