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
