You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Andreas Lehmkuehler <an...@lehmi.de> on 2009/12/15 19:40:04 UTC
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)
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
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)
Posted by 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
>