You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Ad...@swmc.com on 2009/12/14 20:04:33 UTC
Re: svn commit: r888550 - in
/pdfbox/trunk/src/main/java/org/apache/pdfbox/util/operator:
SetNonStrokingSeparation.java SetStrokingSeparation.java
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 <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
? 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.
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
>
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 Andreas Lehmkuehler <an...@lehmi.de>.
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