Re: TestPDFToImage isn't platform independent? (was Re: svn commit: r888550 - in /pdfbox/trunk/src/main/java/org/apache/pdfbox/util/operator: SetNonStrokingSeparation.java SetStrokingSeparation.java)

[Daniel Wilson <wi...@gmail.com>]

>>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 <an...@lehmi.de>wrote:

> Hi,
>
> Adam@swmc.com 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 <an...@lehmi.de>
>> To:
>> dev@pdfbox.apache.org
>> 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,  <le...@apache.org> 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
>