[jira] [Updated] (PDFBOX-1752) Rendering PDF containing Jpeg2000 fails
[ https://issues.apache.org/jira/browse/PDFBOX-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-1752: Labels: JPEG2000 JPXFilter image imageio render (was: image imageio render) Rendering PDF containing Jpeg2000 fails --- Key: PDFBOX-1752 URL: https://issues.apache.org/jira/browse/PDFBOX-1752 Project: PDFBox Issue Type: Bug Components: Rendering Affects Versions: 1.8.2, 2.0.0 Environment: Windows 8.1 Reporter: David KELLER Labels: JPEG2000, JPXFilter, image, imageio, render Attachments: Document_20130625-190105_0001.pdf, Document_20130625-190105_0001.pdf.ghost4j.png, Document_20130625-190105_0001.pdf.icepdf.png, Document_20130625-190105_0001.pdf.jpedal.png, Document_20130625-190105_0001.pdf.pdfbox.2.0.0.png, Document_20130625-190105_0001.pdf.pdfbox.png, PDFBOX-1752-JPX.jp2, PdfToImageTest.java, doc2.pdf, doc2.pdf.jpedal.png, doc2.pdf.pdfbox.png Rendering PDF containing Jpeg2000 fails with PdfBox -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PDFBOX-1466) Rendering of pattern colorspace fails
[ https://issues.apache.org/jira/browse/PDFBOX-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-1466: Affects Version/s: 2.0.0 1.8.4 Rendering of pattern colorspace fails - Key: PDFBOX-1466 URL: https://issues.apache.org/jira/browse/PDFBOX-1466 Project: PDFBox Issue Type: Bug Components: Rendering Affects Versions: 1.7.1, 1.8.4, 2.0.0 Environment: Windows 7, JDK 1.6 / 1.7 Reporter: Maurice Koch Labels: tilingpattern Attachments: pdfbox-1466.pdf-1.png, report.pdf, report.png I was trying to print a pdf which was generated by iText v2.1.5. Unfortunately parts of it were printed in white – the filling color was missing. I could reduce the problem to the attached PDF. When trying to print with e.g. PDocument.silentPrint I get the following info message: [INFO] [org.apache.pdfbox.pdfviewer.PageDrawer] ColorSpace Pattern doesn't provide a non-stroking color, using white instead! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PDFBOX-1466) Rendering of pattern colorspace fails
[ https://issues.apache.org/jira/browse/PDFBOX-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-1466: Attachment: pdfbox-1466.pdf-1.png Here's a current rendering, it is almost perfect now. The only problem left is a weird shadow. I'm not sure whether the shadow is related to the pattern colorspace. It might be a similar problem as in PDFBOX-1954 (line width). Rendering of pattern colorspace fails - Key: PDFBOX-1466 URL: https://issues.apache.org/jira/browse/PDFBOX-1466 Project: PDFBox Issue Type: Bug Components: Rendering Affects Versions: 1.7.1, 1.8.4, 2.0.0 Environment: Windows 7, JDK 1.6 / 1.7 Reporter: Maurice Koch Labels: tilingpattern Attachments: pdfbox-1466.pdf-1.png, report.pdf, report.png I was trying to print a pdf which was generated by iText v2.1.5. Unfortunately parts of it were printed in white – the filling color was missing. I could reduce the problem to the attached PDF. When trying to print with e.g. PDocument.silentPrint I get the following info message: [INFO] [org.apache.pdfbox.pdfviewer.PageDrawer] ColorSpace Pattern doesn't provide a non-stroking color, using white instead! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PDFBOX-1466) Rendering of pattern colorspace fails
[ https://issues.apache.org/jira/browse/PDFBOX-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-1466: Fix Version/s: 2.0.0 Rendering of pattern colorspace fails - Key: PDFBOX-1466 URL: https://issues.apache.org/jira/browse/PDFBOX-1466 Project: PDFBox Issue Type: Bug Components: Rendering Affects Versions: 1.7.1, 1.8.4, 2.0.0 Environment: Windows 7, JDK 1.6 / 1.7 Reporter: Maurice Koch Labels: tilingpattern Fix For: 2.0.0 Attachments: pdfbox-1466.pdf-1.png, report.pdf, report.png I was trying to print a pdf which was generated by iText v2.1.5. Unfortunately parts of it were printed in white – the filling color was missing. I could reduce the problem to the attached PDF. When trying to print with e.g. PDocument.silentPrint I get the following info message: [INFO] [org.apache.pdfbox.pdfviewer.PageDrawer] ColorSpace Pattern doesn't provide a non-stroking color, using white instead! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1466) Rendering of pattern colorspace fails
[ https://issues.apache.org/jira/browse/PDFBOX-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934711#comment-13934711 ] Tilman Hausherr edited comment on PDFBOX-1466 at 3/14/14 7:37 AM: -- Here's a current rendering, it is almost perfect now. The only problem left is a weird shadow. I'm not sure whether the shadow is related to the pattern colorspace. It might be a similar problem as in PDFBOX-1830 and PDFBOX-1954 (line width). was (Author: tilman): Here's a current rendering, it is almost perfect now. The only problem left is a weird shadow. I'm not sure whether the shadow is related to the pattern colorspace. It might be a similar problem as in PDFBOX-1954 (line width). Rendering of pattern colorspace fails - Key: PDFBOX-1466 URL: https://issues.apache.org/jira/browse/PDFBOX-1466 Project: PDFBox Issue Type: Bug Components: Rendering Affects Versions: 1.7.1, 1.8.4, 2.0.0 Environment: Windows 7, JDK 1.6 / 1.7 Reporter: Maurice Koch Labels: tilingpattern Fix For: 2.0.0 Attachments: pdfbox-1466.pdf-1.png, report.pdf, report.png I was trying to print a pdf which was generated by iText v2.1.5. Unfortunately parts of it were printed in white – the filling color was missing. I could reduce the problem to the attached PDF. When trying to print with e.g. PDocument.silentPrint I get the following info message: [INFO] [org.apache.pdfbox.pdfviewer.PageDrawer] ColorSpace Pattern doesn't provide a non-stroking color, using white instead! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PDFBOX-1987) Provide a PDF Lexer as a base for PDF parsing
Maruan Sahyoun created PDFBOX-1987: -- Summary: Provide a PDF Lexer as a base for PDF parsing Key: PDFBOX-1987 URL: https://issues.apache.org/jira/browse/PDFBOX-1987 Project: PDFBox Issue Type: Improvement Components: Parsing Reporter: Maruan Sahyoun Priority: Minor Fix For: 2.0.0 In order to enhance the parsing process and as a foundation for a combination of the different parsers a PDF lexer should be provided. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PDFBOX-1987) Provide a PDF Lexer as a base for PDF parsing
[ https://issues.apache.org/jira/browse/PDFBOX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-1987: --- Attachment: src.zip A PDF lexer Provide a PDF Lexer as a base for PDF parsing - Key: PDFBOX-1987 URL: https://issues.apache.org/jira/browse/PDFBOX-1987 Project: PDFBox Issue Type: Improvement Components: Parsing Reporter: Maruan Sahyoun Priority: Minor Fix For: 2.0.0 Attachments: src.zip In order to enhance the parsing process and as a foundation for a combination of the different parsers a PDF lexer should be provided. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-1987) Provide a PDF Lexer as a base for PDF parsing
[ https://issues.apache.org/jira/browse/PDFBOX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934744#comment-13934744 ] Maruan Sahyoun commented on PDFBOX-1987: I attached a version of a PDF lexer together with a set of tests and some helper classes which extend RandomAccessRead to be able to read test data from strings for easier testing. The purpose is that people who are interested - and have a better programming background - can inspect and comment on the code. An are which I kept out is how to handle malformed tokens such as strings which have an unbalanced number of parenthesis. For a relaxed processing such errors should be fixed. For a strict processing such errors should be reported and potentially fixed as the process shouldn’t stop with the first error. The current idea I have in mind is that the lexer throws events in such cases which a parser could listen and react upon. Again looking for comments and ideas on this. Provide a PDF Lexer as a base for PDF parsing - Key: PDFBOX-1987 URL: https://issues.apache.org/jira/browse/PDFBOX-1987 Project: PDFBox Issue Type: Improvement Components: Parsing Reporter: Maruan Sahyoun Priority: Minor Fix For: 2.0.0 Attachments: src.zip In order to enhance the parsing process and as a foundation for a combination of the different parsers a PDF lexer should be provided. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-1847) TSA Time Signature
[
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934798#comment-13934798
]
John Hewson commented on PDFBOX-1847:
-
I'm in the process of adding this patch and making the necessary changes to
PDFBox. I have some questions and feedback which need to be discussed:
# In CreateSignature you define SHA_256_IDENTIFIER which is passed to the
getTimeStampAttribute method of TSACreator, which means the message digest
which gets created is:
{code}
MessageDigest.getInstance(2.16.840.1.101.3.4.2.1, new BouncyCastleProvider());
{code}
Why not use Java's built-in SHA-256 message digest?
# In TSACreator, the getTimeStampToken method generates an nonce as follows:
{code}
BigInteger nonce = TSAUtils.generateNonce(0, 97359710);
{code}
Where does magic value of 97359710 come from? Is it special?
# In TSACreator, creation of the nonce is immediately followed by:
{code}
log.log(Level.INFO, nonce is + nonce);
{code}
Which leaks the nonce to the log file before it has been sent to the server. I
have fixed this, but I still wanted to let you know about it.
# In TSACreator, the openTSAConnection method sets the following HTTP header:
{code}
connection.setRequestProperty(Content-Transfer-Encoding, binary);
{code}
But Content-Transfer-Encoding is a MIME header for e-mails, not HTTP
requests, is there some reason why it's there?
# In TSAUtils, the byteToASN1Object method has a try/catch for
ClassCastException, but I don't see why this exception needs catching, does
bouncy castle throw it? (It shouldn't, but it is known to do things like that).
# In TSAUtils, the generateNonce method is as follows:
{code}
public static BigInteger generateNonce(int min, int max)
{
Random rand = new Random();
Integer randomNum = rand.nextInt((max - min) + 1) + min;
BigInteger nonce = new BigInteger(randomNum.toString());
Long timeLong = System.currentTimeMillis();
Integer timeInt = timeLong != null ? timeLong.intValue() : 761820123;
return nonce.multiply((new BigInteger(timeInt.toString(;
}
{code}
There are some problems with this approach. The first is that
_java.util.Random_ is not cryptographically secure ([see
documentation|http://docs.oracle.com/javase/7/docs/api/java/util/Random.html]).
The second is that the current time is not a source of cryptographically secure
entropy, furthermore it's already included in the seed for _java.util.Random_
which means that multiplying the random nonce by the current time cannot
improve the nonce. I will fix these issues by using SecureRandom, but I wanted
to let you know about the issues with this method.
TSA Time Signature
--
Key: PDFBOX-1847
URL: https://issues.apache.org/jira/browse/PDFBOX-1847
Project: PDFBox
Issue Type: Improvement
Components: Signing
Affects Versions: 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
Fix For: 2.0.0
Attachments: CreateSignature-updated.java.patch,
TSATimeSignature.patch, resultOfSigning.jpg
When we was signing document, we was using time from our time. For more
security we can use Time Stamp server.
Trusted timestamping is the process of securely keeping track of the
creation and modification time of a document. Security here means that no one
— not even the owner of the document — should be able to change it once it
has been recorded provided that the timestamper's integrity is never
compromised.(wiki)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934798#comment-13934798
]
John Hewson edited comment on PDFBOX-1847 at 3/14/14 9:11 AM:
--
I'm in the process of adding this patch and making the necessary changes to
PDFBox. I have some questions and feedback which need to be discussed:
# In CreateSignature you define SHA_256_IDENTIFIER which is passed to the
getTimeStampAttribute method of TSACreator, which means the message digest
which gets created is:
{code}
MessageDigest.getInstance(2.16.840.1.101.3.4.2.1, new BouncyCastleProvider());
{code}
Why not use Java's built-in SHA-256 message digest?
# In TSACreator, the getTimeStampToken method generates an nonce as follows:
{code}
BigInteger nonce = TSAUtils.generateNonce(0, 97359710);
{code}
Where does magic value of 97359710 come from? Is it special?
# In TSACreator, creation of the nonce is immediately followed by:
{code}
log.log(Level.INFO, nonce is + nonce);
{code}
Which leaks the nonce to the log file before it has been sent to the server. I
have fixed this, but I still wanted to let you know about it.
# In TSACreator, the openTSAConnection method sets the following HTTP header:
{code}
connection.setRequestProperty(Content-Transfer-Encoding, binary);
{code}
But Content-Transfer-Encoding is a MIME header for e-mails, not HTTP
requests, is there some reason why it's there?
# In TSAUtils, the byteToASN1Object method has a try/catch for
ClassCastException, but I don't see why this exception needs catching, does
bouncy castle throw it? (It shouldn't, but it is known to do things like that).
# In TSAUtils, the generateNonce method is as follows:
{code}
public static BigInteger generateNonce(int min, int max)
{
Random rand = new Random();
Integer randomNum = rand.nextInt((max - min) + 1) + min;
BigInteger nonce = new BigInteger(randomNum.toString());
Long timeLong = System.currentTimeMillis();
Integer timeInt = timeLong != null ? timeLong.intValue() : 761820123;
return nonce.multiply((new BigInteger(timeInt.toString(;
}
{code}
There are some problems with this approach. The first is that
_java.util.Random_ is not cryptographically secure ([see
documentation|http://docs.oracle.com/javase/7/docs/api/java/util/Random.html]).
The second is that the current time is not a source of cryptographically secure
entropy, furthermore it's already included in the seed for _java.util.Random_
which means that multiplying the random nonce by the current time cannot
improve the nonce. I will fix these issues by using SecureRandom, but I wanted
to let you know about them.
Thanks!
was (Author: jahewson):
I'm in the process of adding this patch and making the necessary changes to
PDFBox. I have some questions and feedback which need to be discussed:
# In CreateSignature you define SHA_256_IDENTIFIER which is passed to the
getTimeStampAttribute method of TSACreator, which means the message digest
which gets created is:
{code}
MessageDigest.getInstance(2.16.840.1.101.3.4.2.1, new BouncyCastleProvider());
{code}
Why not use Java's built-in SHA-256 message digest?
# In TSACreator, the getTimeStampToken method generates an nonce as follows:
{code}
BigInteger nonce = TSAUtils.generateNonce(0, 97359710);
{code}
Where does magic value of 97359710 come from? Is it special?
# In TSACreator, creation of the nonce is immediately followed by:
{code}
log.log(Level.INFO, nonce is + nonce);
{code}
Which leaks the nonce to the log file before it has been sent to the server. I
have fixed this, but I still wanted to let you know about it.
# In TSACreator, the openTSAConnection method sets the following HTTP header:
{code}
connection.setRequestProperty(Content-Transfer-Encoding, binary);
{code}
But Content-Transfer-Encoding is a MIME header for e-mails, not HTTP
requests, is there some reason why it's there?
# In TSAUtils, the byteToASN1Object method has a try/catch for
ClassCastException, but I don't see why this exception needs catching, does
bouncy castle throw it? (It shouldn't, but it is known to do things like that).
# In TSAUtils, the generateNonce method is as follows:
{code}
public static BigInteger generateNonce(int min, int max)
{
Random rand = new Random();
Integer randomNum = rand.nextInt((max - min) + 1) + min;
BigInteger nonce = new BigInteger(randomNum.toString());
Long timeLong = System.currentTimeMillis();
Integer timeInt = timeLong != null ? timeLong.intValue() : 761820123;
return nonce.multiply((new BigInteger(timeInt.toString(;
}
{code}
There are some problems with this approach. The first is that
_java.util.Random_ is not cryptographically secure ([see
documentation|http://docs.oracle.com/javase/7/docs/api/java/util/Random.html]).
The second is that the current time is not a source
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934798#comment-13934798
]
John Hewson edited comment on PDFBOX-1847 at 3/14/14 9:12 AM:
--
I'm in the process of adding this patch and making the necessary changes to
PDFBox. I have some questions and feedback which need to be discussed:
# In CreateSignature you define SHA_256_IDENTIFIER which is passed to the
getTimeStampAttribute method of TSACreator, which means the message digest
which gets created is:
{code}
MessageDigest.getInstance(2.16.840.1.101.3.4.2.1, new BouncyCastleProvider());
{code}
Why not use Java's built-in SHA-256 message digest?
# In TSACreator, the getTimeStampToken method generates an nonce as follows:
{code}
BigInteger nonce = TSAUtils.generateNonce(0, 97359710);
{code}
Where does magic value of 97359710 come from? Is it special?
# In TSACreator, creation of the nonce is immediately followed by:
{code}
log.log(Level.INFO, nonce is + nonce);
{code}
Which leaks the nonce to the log file before it has been sent to the server. I
have fixed this, but I still wanted to let you know about it.
# In TSACreator, the openTSAConnection method sets the following HTTP header:
{code}
connection.setRequestProperty(Content-Transfer-Encoding, binary);
{code}
But Content-Transfer-Encoding is a MIME header for e-mails, not HTTP
requests, is there some reason why it's there?
# In TSAUtils, the byteToASN1Object method has a try/catch for
ClassCastException, but I don't see why this exception needs catching, does
bouncy castle throw it? (It shouldn't, but it is known to do things like that).
# In TSAUtils, the generateNonce method is as follows:
{code}
public static BigInteger generateNonce(int min, int max)
{
Random rand = new Random();
Integer randomNum = rand.nextInt((max - min) + 1) + min;
BigInteger nonce = new BigInteger(randomNum.toString());
Long timeLong = System.currentTimeMillis();
Integer timeInt = timeLong != null ? timeLong.intValue() : 761820123;
return nonce.multiply((new BigInteger(timeInt.toString(;
}
{code}
There are some problems with this approach. The first is that
_java.util.Random_ is not cryptographically secure ([see
documentation|http://docs.oracle.com/javase/7/docs/api/java/util/Random.html]).
The second is that the current time is not (on its own) a source of
cryptographically secure entropy, furthermore it's already included in the seed
for _java.util.Random_ which means that multiplying the random nonce by the
current time cannot improve the nonce. I will fix these issues by using
SecureRandom, but I wanted to let you know about them.
Thanks!
was (Author: jahewson):
I'm in the process of adding this patch and making the necessary changes to
PDFBox. I have some questions and feedback which need to be discussed:
# In CreateSignature you define SHA_256_IDENTIFIER which is passed to the
getTimeStampAttribute method of TSACreator, which means the message digest
which gets created is:
{code}
MessageDigest.getInstance(2.16.840.1.101.3.4.2.1, new BouncyCastleProvider());
{code}
Why not use Java's built-in SHA-256 message digest?
# In TSACreator, the getTimeStampToken method generates an nonce as follows:
{code}
BigInteger nonce = TSAUtils.generateNonce(0, 97359710);
{code}
Where does magic value of 97359710 come from? Is it special?
# In TSACreator, creation of the nonce is immediately followed by:
{code}
log.log(Level.INFO, nonce is + nonce);
{code}
Which leaks the nonce to the log file before it has been sent to the server. I
have fixed this, but I still wanted to let you know about it.
# In TSACreator, the openTSAConnection method sets the following HTTP header:
{code}
connection.setRequestProperty(Content-Transfer-Encoding, binary);
{code}
But Content-Transfer-Encoding is a MIME header for e-mails, not HTTP
requests, is there some reason why it's there?
# In TSAUtils, the byteToASN1Object method has a try/catch for
ClassCastException, but I don't see why this exception needs catching, does
bouncy castle throw it? (It shouldn't, but it is known to do things like that).
# In TSAUtils, the generateNonce method is as follows:
{code}
public static BigInteger generateNonce(int min, int max)
{
Random rand = new Random();
Integer randomNum = rand.nextInt((max - min) + 1) + min;
BigInteger nonce = new BigInteger(randomNum.toString());
Long timeLong = System.currentTimeMillis();
Integer timeInt = timeLong != null ? timeLong.intValue() : 761820123;
return nonce.multiply((new BigInteger(timeInt.toString(;
}
{code}
There are some problems with this approach. The first is that
_java.util.Random_ is not cryptographically secure ([see
documentation|http://docs.oracle.com/javase/7/docs/api/java/util/Random.html]).
The second is that the current time is
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934798#comment-13934798
]
John Hewson edited comment on PDFBOX-1847 at 3/14/14 9:12 AM:
--
I'm in the process of adding this patch and making the necessary changes to
PDFBox. I have some questions and feedback which need to be discussed:
# In CreateSignature you define SHA_256_IDENTIFIER which is passed to the
getTimeStampAttribute method of TSACreator, which means the message digest
which gets created is:
{code}
MessageDigest.getInstance(2.16.840.1.101.3.4.2.1, new BouncyCastleProvider());
{code}
Why not use Java's built-in SHA-256 message digest?
# In TSACreator, the getTimeStampToken method generates an nonce as follows:
{code}
BigInteger nonce = TSAUtils.generateNonce(0, 97359710);
{code}
Where does magic value of 97359710 come from? Is it special?
# In TSACreator, creation of the nonce is immediately followed by:
{code}
log.log(Level.INFO, nonce is + nonce);
{code}
Which leaks the nonce to the log file before it has been sent to the server. I
have fixed this, but I still wanted to let you know about it.
# In TSACreator, the openTSAConnection method sets the following HTTP header:
{code}
connection.setRequestProperty(Content-Transfer-Encoding, binary);
{code}
But Content-Transfer-Encoding is a MIME header for e-mails, not HTTP
requests, is there some reason why it's there?
# In TSAUtils, the byteToASN1Object method has a try/catch for
ClassCastException, but I don't see why this exception needs catching, does
bouncy castle throw it? (It shouldn't, but it is known to do things like that).
# In TSAUtils, the generateNonce method is as follows:
{code}
public static BigInteger generateNonce(int min, int max)
{
Random rand = new Random();
Integer randomNum = rand.nextInt((max - min) + 1) + min;
BigInteger nonce = new BigInteger(randomNum.toString());
Long timeLong = System.currentTimeMillis();
Integer timeInt = timeLong != null ? timeLong.intValue() : 761820123;
return nonce.multiply((new BigInteger(timeInt.toString(;
}
{code}
There are some problems with this approach. The first is that
_java.util.Random_ is not cryptographically secure ([see
documentation|http://docs.oracle.com/javase/7/docs/api/java/util/Random.html]).
The second is that the current time is not (on it's own) a source of
cryptographically secure entropy, furthermore it's already included in the seed
for _java.util.Random_ which means that multiplying the random nonce by the
current time cannot improve the nonce. I will fix these issues by using
SecureRandom, but I wanted to let you know about them.
Thanks!
was (Author: jahewson):
I'm in the process of adding this patch and making the necessary changes to
PDFBox. I have some questions and feedback which need to be discussed:
# In CreateSignature you define SHA_256_IDENTIFIER which is passed to the
getTimeStampAttribute method of TSACreator, which means the message digest
which gets created is:
{code}
MessageDigest.getInstance(2.16.840.1.101.3.4.2.1, new BouncyCastleProvider());
{code}
Why not use Java's built-in SHA-256 message digest?
# In TSACreator, the getTimeStampToken method generates an nonce as follows:
{code}
BigInteger nonce = TSAUtils.generateNonce(0, 97359710);
{code}
Where does magic value of 97359710 come from? Is it special?
# In TSACreator, creation of the nonce is immediately followed by:
{code}
log.log(Level.INFO, nonce is + nonce);
{code}
Which leaks the nonce to the log file before it has been sent to the server. I
have fixed this, but I still wanted to let you know about it.
# In TSACreator, the openTSAConnection method sets the following HTTP header:
{code}
connection.setRequestProperty(Content-Transfer-Encoding, binary);
{code}
But Content-Transfer-Encoding is a MIME header for e-mails, not HTTP
requests, is there some reason why it's there?
# In TSAUtils, the byteToASN1Object method has a try/catch for
ClassCastException, but I don't see why this exception needs catching, does
bouncy castle throw it? (It shouldn't, but it is known to do things like that).
# In TSAUtils, the generateNonce method is as follows:
{code}
public static BigInteger generateNonce(int min, int max)
{
Random rand = new Random();
Integer randomNum = rand.nextInt((max - min) + 1) + min;
BigInteger nonce = new BigInteger(randomNum.toString());
Long timeLong = System.currentTimeMillis();
Integer timeInt = timeLong != null ? timeLong.intValue() : 761820123;
return nonce.multiply((new BigInteger(timeInt.toString(;
}
{code}
There are some problems with this approach. The first is that
_java.util.Random_ is not cryptographically secure ([see
documentation|http://docs.oracle.com/javase/7/docs/api/java/util/Random.html]).
The second is that the current time
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931975#comment-13931975
]
John Hewson edited comment on PDFBOX-1847 at 3/14/14 9:14 AM:
--
Just to recap our discussion on the mailing list: this patch is going to go
into a new singing module:
{quote}
*Vakhtang Koroghlishvili:*
I think, it's time to create another project named sign-box or something like
that. At the moment I have time and I can create that project with very good
design architect and show you a patch or comitters can create that project
with existence features and then we will add new features step by step.
{quote}
and the existing non-core signing classes will be moved there too.
For anyone wondering why we would want to move the signing classes, one reason
is that not all of them are part of the PDF specification. The spec defines a
generic plug-in framework for signatures with some basic built-in
functionality, but nothing beyond that. Instead, there are various third party
signing standards, such as [PAdES|http://en.wikipedia.org/wiki/PAdES].
was (Author: jahewson):
Just to recap our discussion on the mailing list: this patch is going to go
into a new singing module:
{quote}
*Vakhtang Koroghlishvili:*
I think, it's time to create another project named sign-box or something like
that. At the moment I have time and I can create that project with very good
design architect and show you a patch or comitters can create that project
with existence features and then we will add new features step by step.
{quote}
and the existing non-core signing classes will be moved there too.
For anyone wondering why we would want to move the signing classes, one reason
is that they are not part of the PDF specification. The spec defines a generic
plug-in framework for signatures with some basic built-in functionality, but
nothing beyond that. Instead, there are various third party signing standards,
such as [PAdES|http://en.wikipedia.org/wiki/PAdES].
TSA Time Signature
--
Key: PDFBOX-1847
URL: https://issues.apache.org/jira/browse/PDFBOX-1847
Project: PDFBox
Issue Type: Improvement
Components: Signing
Affects Versions: 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
Fix For: 2.0.0
Attachments: CreateSignature-updated.java.patch,
TSATimeSignature.patch, resultOfSigning.jpg
When we was signing document, we was using time from our time. For more
security we can use Time Stamp server.
Trusted timestamping is the process of securely keeping track of the
creation and modification time of a document. Security here means that no one
— not even the owner of the document — should be able to change it once it
has been recorded provided that the timestamper's integrity is never
compromised.(wiki)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PDFBOX-1847) TSA Time Signature
[ https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934946#comment-13934946 ] vakhtang koroghlishvili commented on PDFBOX-1847: - 1. We can do it with java's build-in SHA-256 message digest too. :) you can change with it too. There is no difference :) 2. It is just a number, not special. Then it will be better if we add document hash for nonce too. 3. you are right. 4. I was testing TSA for emails. we should remove this - If we have nothing in common with emails, we shouldn't use this header. 5. I don't remember... I will test it... In additional, in.readObject() might throw java.io.EOFException or java.io.IOException. So method needs some refactoring :) 6. Sure. Then I will add document hash to the nonce too :) For more security :) TSA Time Signature -- Key: PDFBOX-1847 URL: https://issues.apache.org/jira/browse/PDFBOX-1847 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.0 Reporter: vakhtang koroghlishvili Assignee: John Hewson Fix For: 2.0.0 Attachments: CreateSignature-updated.java.patch, TSATimeSignature.patch, resultOfSigning.jpg When we was signing document, we was using time from our time. For more security we can use Time Stamp server. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.(wiki) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PDFBOX-1988) PDFBox ExtractText issue of PDF with no embedded fonts
Craig Strong created PDFBOX-1988: Summary: PDFBox ExtractText issue of PDF with no embedded fonts Key: PDFBOX-1988 URL: https://issues.apache.org/jira/browse/PDFBOX-1988 Project: PDFBox Issue Type: Bug Components: Text extraction Affects Versions: 1.8.4 Environment: Windows 7 Also, PASE on IBM i Reporter: Craig Strong Fix For: 1.8.5 I have been using PDFBox 1.8.4 to extract text from several different PDF files fine. I use the latest PDFBox app with ExtractText command line. There is one PDF that PDFBox (and iText) fails to extract any text even though I can extract the text with Adobe Reader and also pdftotext.exe part of XPdf. java -jar pdfbox-app-1.8.4.jar ExtractText Test1.pdf Out.txt. I don't want to have to rely on using pdftotext.exe from a PC since this is part of an automated application. I think the error relates to an unknown font type and having to use the few fonts installed in the jar file. I tried running the API classes and trying to force a font from a certain location but I still got errors. I thought I loaded the font with the loadTTF method but I don't know if that did anything with the font. I would really like to have this working straight from the ExtractText class anyway. Here are the errors I am getting. I tried this from both a Windows 7 PC and our IBM i in the PASE environment but I get the same errors. The section starting processEncodedText and on repeats a few times so I just included the first entries. Mar 10, 2014 3:50:44 PM org.apache.pdfbox.pdmodel.font.PDFontFactory createFont WARNING: Substituting TrueType for unknown font subtype= Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processOperator WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:375) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.ensureFontDescriptor(PDTrueTypeFont.java:221) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.init(PDTrueTypeFont.java:119) at org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:121) at org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:204) at org.apache.pdfbox.util.PDFStreamEngine.getFonts(PDFStreamEngine.java:604) at org.apache.pdfbox.util.operator.SetTextFont.process(SetTextFont.java:54) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) at org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) at org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456) at org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381) at org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340) at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:275) at org.apache.pdfbox.ExtractText.main(ExtractText.java:85) at org.apache.pdfbox.PDFBox.main(PDFBox.java:58) Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processEncodedText WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:355) at org.apache.pdfbox.util.operator.ShowText.process(ShowText.java:45) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) at org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) at org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456) at org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381) at org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340) at
[jira] [Updated] (PDFBOX-1988) PDFBox ExtractText issue of PDF with no embedded fonts
[ https://issues.apache.org/jira/browse/PDFBOX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Strong updated PDFBOX-1988: - Attachment: Test1.pdf Problem PDF with no embedded fonts. PDFBox ExtractText issue of PDF with no embedded fonts -- Key: PDFBOX-1988 URL: https://issues.apache.org/jira/browse/PDFBOX-1988 Project: PDFBox Issue Type: Bug Components: Text extraction Affects Versions: 1.8.4 Environment: Windows 7 Also, PASE on IBM i Reporter: Craig Strong Labels: patch Fix For: 1.8.5 Attachments: Test1.pdf Original Estimate: 120h Remaining Estimate: 120h I have been using PDFBox 1.8.4 to extract text from several different PDF files fine. I use the latest PDFBox app with ExtractText command line. There is one PDF that PDFBox (and iText) fails to extract any text even though I can extract the text with Adobe Reader and also pdftotext.exe part of XPdf. java -jar pdfbox-app-1.8.4.jar ExtractText Test1.pdf Out.txt. I don't want to have to rely on using pdftotext.exe from a PC since this is part of an automated application. I think the error relates to an unknown font type and having to use the few fonts installed in the jar file. I tried running the API classes and trying to force a font from a certain location but I still got errors. I thought I loaded the font with the loadTTF method but I don't know if that did anything with the font. I would really like to have this working straight from the ExtractText class anyway. Here are the errors I am getting. I tried this from both a Windows 7 PC and our IBM i in the PASE environment but I get the same errors. The section starting processEncodedText and on repeats a few times so I just included the first entries. Mar 10, 2014 3:50:44 PM org.apache.pdfbox.pdmodel.font.PDFontFactory createFont WARNING: Substituting TrueType for unknown font subtype= Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processOperator WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:375) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.ensureFontDescriptor(PDTrueTypeFont.java:221) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.init(PDTrueTypeFont.java:119) at org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:121) at org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:204) at org.apache.pdfbox.util.PDFStreamEngine.getFonts(PDFStreamEngine.java:604) at org.apache.pdfbox.util.operator.SetTextFont.process(SetTextFont.java:54) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) at org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) at org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456) at org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381) at org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340) at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:275) at org.apache.pdfbox.ExtractText.main(ExtractText.java:85) at org.apache.pdfbox.PDFBox.main(PDFBox.java:58) Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processEncodedText WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:355) at org.apache.pdfbox.util.operator.ShowText.process(ShowText.java:45) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at
[jira] [Commented] (PDFBOX-1983) Unable to add TIF images, CCITTFactory not working
[ https://issues.apache.org/jira/browse/PDFBOX-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935295#comment-13935295 ] Tilman Hausherr commented on PDFBOX-1983: - I added a test in rev 1577618. Note the part at the end of the code, it's unclear to me if ximage.getImage() should return an image. (Currently it doesn't) Unable to add TIF images, CCITTFactory not working -- Key: PDFBOX-1983 URL: https://issues.apache.org/jira/browse/PDFBOX-1983 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 2.0.0 Reporter: Joel Kääpä Assignee: Tilman Hausherr Fix For: 2.0.0 Attachments: G4.tif, huhu.pdf As used in the AddImageToPDF example, the following line generates an error with tif image: PDImageXObject ximage = CCITTFactory.createFromRandomAccess(document, new RandomAccessFile(new File(imagePath), r)); java.io.IOException: Stream was not read at org.apache.pdfbox.cos.COSStream.getDecodeResult(COSStream.java:235) at org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.init(PDImageXObject.java:80) at org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.init(PDImageXObject.java:70) at org.apache.pdfbox.pdmodel.graphics.image.CCITTFactory.createFromRandomAccess(CCITTFactory.java:50) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1983) Unable to add TIF images, CCITTFactory not working
[ https://issues.apache.org/jira/browse/PDFBOX-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935295#comment-13935295 ] Tilman Hausherr edited comment on PDFBOX-1983 at 3/14/14 5:34 PM: -- I added a test in rev 1577618 and 1577619. Note the part at the end of the code, it's unclear to me if ximage.getImage() should return an image. (Currently it doesn't) was (Author: tilman): I added a test in rev 1577618. Note the part at the end of the code, it's unclear to me if ximage.getImage() should return an image. (Currently it doesn't) Unable to add TIF images, CCITTFactory not working -- Key: PDFBOX-1983 URL: https://issues.apache.org/jira/browse/PDFBOX-1983 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 2.0.0 Reporter: Joel Kääpä Assignee: Tilman Hausherr Fix For: 2.0.0 Attachments: G4.tif, huhu.pdf As used in the AddImageToPDF example, the following line generates an error with tif image: PDImageXObject ximage = CCITTFactory.createFromRandomAccess(document, new RandomAccessFile(new File(imagePath), r)); java.io.IOException: Stream was not read at org.apache.pdfbox.cos.COSStream.getDecodeResult(COSStream.java:235) at org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.init(PDImageXObject.java:80) at org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.init(PDImageXObject.java:70) at org.apache.pdfbox.pdmodel.graphics.image.CCITTFactory.createFromRandomAccess(CCITTFactory.java:50) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1969) JPEGFactory bug
[ https://issues.apache.org/jira/browse/PDFBOX-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935328#comment-13935328 ] Tilman Hausherr edited comment on PDFBOX-1969 at 3/14/14 5:52 PM: -- While writing the test for the CCITTFactory (PDFBOX-1983), I thought I'd write a test for this class as well, before reading here / noticing that there was already a test in the example package. The test for createFromImage() failed with the now familiar Stream was not read exception. I'll correct that one this weekend unless someone else does it first. I remember that someone said on the dev list that the signature images didn't appear. This might be caused by this bug. In the meantime, I have committed a first version of the test in rev 1577622, with only one of two tests active. was (Author: tilman): While writing the test for the CCITTFactory (PDFBOX-1983), I thought I'd write a test for this class as well, before noticing that there was already a test in the example package. The test for createFromImage() failed with the now familiar Stream was not read exception. I'll correct that one this weekend unless someone else does it first. I remember that someone said on the dev list that the signature images didn't appear. This might be caused by this bug. In the meantime, I have committed a first version of the test in rev 1577622, with only one of two tests active. JPEGFactory bug --- Key: PDFBOX-1969 URL: https://issues.apache.org/jira/browse/PDFBOX-1969 Project: PDFBox Issue Type: Bug Reporter: Steven Burg Attempted to run the RubberStampWithImage sample and received the following errors: Exception in thread main java.lang.NullPointerException at org.apache.pdfbox.pdmodel.graphics.image.JPEGFactory.createFromStream(JPEGFactory.java:72) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.doIt(RubberStampWithImage.java:93) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.main(RubberStampWithImage.java:185) This happens with any jog I tested with. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (PDFBOX-1969) JPEGFactory bug
[ https://issues.apache.org/jira/browse/PDFBOX-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr reopened PDFBOX-1969: - While writing the test for the CCITTFactory (PDFBOX-1983), I thought I'd write a test for this class as well, before noticing that there was already a test in the example package. The test for createFromImage() failed with the now familiar Stream was not read exception. I'll correct that one this weekend unless someone else does it first. I remember that someone said on the dev list that the signature images didn't appear. This might be caused by this bug. In the meantime, I have committed a first version of the test in rev 1577622, with only one of two tests active. JPEGFactory bug --- Key: PDFBOX-1969 URL: https://issues.apache.org/jira/browse/PDFBOX-1969 Project: PDFBox Issue Type: Bug Reporter: Steven Burg Attempted to run the RubberStampWithImage sample and received the following errors: Exception in thread main java.lang.NullPointerException at org.apache.pdfbox.pdmodel.graphics.image.JPEGFactory.createFromStream(JPEGFactory.java:72) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.doIt(RubberStampWithImage.java:93) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.main(RubberStampWithImage.java:185) This happens with any jog I tested with. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-1988) PDFBox ExtractText issue of PDF with no embedded fonts
[ https://issues.apache.org/jira/browse/PDFBOX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935427#comment-13935427 ] John Hewson commented on PDFBOX-1988: - The attached file uses the Courier Bold font which is one of the standard 14 fonts which do not need to be embedded, so this looks like a bug in PDFBox rather than a font embedding issue. PDFBox ExtractText issue of PDF with no embedded fonts -- Key: PDFBOX-1988 URL: https://issues.apache.org/jira/browse/PDFBOX-1988 Project: PDFBox Issue Type: Bug Components: Text extraction Affects Versions: 1.8.4 Environment: Windows 7 Also, PASE on IBM i Reporter: Craig Strong Labels: patch Fix For: 1.8.5 Attachments: Test1.pdf Original Estimate: 120h Remaining Estimate: 120h I have been using PDFBox 1.8.4 to extract text from several different PDF files fine. I use the latest PDFBox app with ExtractText command line. There is one PDF that PDFBox (and iText) fails to extract any text even though I can extract the text with Adobe Reader and also pdftotext.exe part of XPdf. java -jar pdfbox-app-1.8.4.jar ExtractText Test1.pdf Out.txt. I don't want to have to rely on using pdftotext.exe from a PC since this is part of an automated application. I think the error relates to an unknown font type and having to use the few fonts installed in the jar file. I tried running the API classes and trying to force a font from a certain location but I still got errors. I thought I loaded the font with the loadTTF method but I don't know if that did anything with the font. I would really like to have this working straight from the ExtractText class anyway. Here are the errors I am getting. I tried this from both a Windows 7 PC and our IBM i in the PASE environment but I get the same errors. The section starting processEncodedText and on repeats a few times so I just included the first entries. Mar 10, 2014 3:50:44 PM org.apache.pdfbox.pdmodel.font.PDFontFactory createFont WARNING: Substituting TrueType for unknown font subtype= Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processOperator WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:375) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.ensureFontDescriptor(PDTrueTypeFont.java:221) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.init(PDTrueTypeFont.java:119) at org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:121) at org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:204) at org.apache.pdfbox.util.PDFStreamEngine.getFonts(PDFStreamEngine.java:604) at org.apache.pdfbox.util.operator.SetTextFont.process(SetTextFont.java:54) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) at org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) at org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456) at org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381) at org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340) at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:275) at org.apache.pdfbox.ExtractText.main(ExtractText.java:85) at org.apache.pdfbox.PDFBox.main(PDFBox.java:58) Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processEncodedText WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:355) at org.apache.pdfbox.util.operator.ShowText.process(ShowText.java:45) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554)
[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression
[ https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935432#comment-13935432 ] Tilman Hausherr commented on PDFBOX-1975: - I added a CCITT G4 compressed file as yet another test file in rev 1577653. Improve TestImageIOUtils unit tests to check image resolution and compression - Key: PDFBOX-1975 URL: https://issues.apache.org/jira/browse/PDFBOX-1975 Project: PDFBox Issue Type: Task Components: Utilities Affects Versions: 2.0.0 Reporter: Tilman Hausherr Assignee: Tilman Hausherr Priority: Minor Labels: imageio, test, tiff Fix For: 2.0.0 Because of the problems with recent changes (see PDFBOX-1963), I will improve the unit tests so that image resolution and compression is checked. I found out that JPEGs don't have a resolution, BMP had the wrong resolution. The fault wasn't in the java TIFF writer as I thought before, it is in the java PNG writer, which uses the PixelSize values wrongly, i.e. it interprets them as pixels per mm instead of mm per pixel as per specification. The JPEG writer throws an exception JFIF APP0 must be first marker after SOI. The BMP writer can set the resolution, but the BMP reader doesn't read it. (Some of this might be different depending on the version) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1988) PDFBox ExtractText issue of PDF with no embedded fonts
[
https://issues.apache.org/jira/browse/PDFBOX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935533#comment-13935533
]
Tilman Hausherr edited comment on PDFBOX-1988 at 3/14/14 8:15 PM:
--
Text extraction always works with the 2.0 version.
Rendering is bad with the 2.0 version. I'm able to render the file properly
with 2.0 by making two changes:
- adding
{code}
dic.setName( COSName.TYPE, COSName.TRUE_TYPE.toString() );
{code}
after the Substituting TrueType for unknown font subtype= warning
(I'm not committing this because I prefer to have another opinion. The idea is
that if we are to fake a TT font, that we should attach the type)
- adding a line for Courier-Bold in the PDFBox_External_Fonts.properties file.
was (Author: tilman):
Rendering is also bad.
PDFBox ExtractText issue of PDF with no embedded fonts
--
Key: PDFBOX-1988
URL: https://issues.apache.org/jira/browse/PDFBOX-1988
Project: PDFBox
Issue Type: Bug
Components: Rendering, Text extraction
Affects Versions: 1.8.4
Environment: Windows 7
Also, PASE on IBM i
Reporter: Craig Strong
Labels: patch
Fix For: 1.8.5
Attachments: Test1.pdf
Original Estimate: 120h
Remaining Estimate: 120h
I have been using PDFBox 1.8.4 to extract text from several different PDF
files fine. I use the latest PDFBox app with ExtractText command line.
There is one PDF that PDFBox (and iText) fails to extract any text even
though I can extract the text with Adobe Reader and also pdftotext.exe part
of XPdf. java -jar pdfbox-app-1.8.4.jar ExtractText Test1.pdf Out.txt. I
don't want to have to rely on using pdftotext.exe from a PC since this is
part of an automated application. I think the error relates to an unknown
font type and having to use the few fonts installed in the jar file. I tried
running the API classes and trying to force a font from a certain location
but I still got errors. I thought I loaded the font with the loadTTF method
but I don't know if that did anything with the font. I would really like to
have this working straight from the ExtractText class anyway.
Here are the errors I am getting. I tried this from both a Windows 7 PC and
our IBM i in the PASE environment but I get the same errors. The section
starting processEncodedText and on repeats a few times so I just included the
first entries.
Mar 10, 2014 3:50:44 PM org.apache.pdfbox.pdmodel.font.PDFontFactory
createFont
WARNING: Substituting TrueType for unknown font subtype=
Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine
processOperator
WARNING: java.lang.NullPointerException
Throwable occurred: java.lang.NullPointerException
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:375)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.ensureFontDescriptor(PDTrueTypeFont.java:221)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.init(PDTrueTypeFont.java:119)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:121)
at
org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:204)
at
org.apache.pdfbox.util.PDFStreamEngine.getFonts(PDFStreamEngine.java:604)
at
org.apache.pdfbox.util.operator.SetTextFont.process(SetTextFont.java:54)
at
org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554)
at
org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268)
at
org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235)
at
org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215)
at
org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456)
at
org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381)
at
org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340)
at
org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:275)
at org.apache.pdfbox.ExtractText.main(ExtractText.java:85)
at org.apache.pdfbox.PDFBox.main(PDFBox.java:58)
Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine
processEncodedText
WARNING:
[jira] [Reopened] (PDFBOX-1946) Running within an Applet has many AccessControlException 's
[ https://issues.apache.org/jira/browse/PDFBOX-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hewson reopened PDFBOX-1946: - I've encountered a case where this fix masks a bug in PDFBox. In PDFBOX-1988 a bug causes the font in PDFStreamEngine to be null, which should cause an NPE, causing the user to file a bug report. In 1.8.4 this happens, but in 1.8.5 and 2.0 it does not, because it's been wrapped with if (font != null) so the NPE is silently swallowed. We need to find some other way of fixing the null font issue, identifying exactly why it is null in an applet and perhaps just substituting a default font such as PDType1.HELVETICA so that null remains an invalid value. I've removed the fix from PDFStreamEngine in revision 1577725 in trunk and 1577728 in 1.8, and am re-opening this issue. Running within an Applet has many AccessControlException 's --- Key: PDFBOX-1946 URL: https://issues.apache.org/jira/browse/PDFBOX-1946 Project: PDFBox Issue Type: Wish Affects Versions: 1.8.4 Environment: Running within an Applet Reporter: Fred Andrews Labels: Security Fix For: 1.8.5, 2.0.0 Attachments: patch.zip I've identified 6 modules that should be modified to avoid AccessControlException's while running within an Applet. My solution would be to catch each AccessControlException and then use a default or continue on. For most of these, that is probably the best solution, for a few especially PDFStreamEngine someone may have a better idea. The modules that have issues: pdfbox\pdfparser\BaseParser -- line 131 call to Boolean.getBoolean, line 170 call to Integer.getInteger pdfbox\util\PDFTextStripper -- line 79 call to System.getProperty() pdfbox\util\ResourceLoader -- line 67 call to getSystemClassLoader() pdfbox\pdmodel\graphics\color\PDColorState -- line 50, call to Color.getColor pdfbox/encoding/Encoding -- line 78, call to System.getProperty pdfbox\util\PDFStreamEngine -- Line 351 364 check for font == null (will be null if had resource loading problems) Not sure what the best way is to proceed. Please advise. Thanks -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PDFBOX-1988) PDFBox ExtractText issue of PDF with no embedded fonts
[ https://issues.apache.org/jira/browse/PDFBOX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hewson resolved PDFBOX-1988. - Resolution: Fixed Fix Version/s: 2.0.0 Revision 1577682 adds a new getName method to COSDictionary for connivence and a new COSName.EMPTY value. It also does some cleaning up of COSName such as removing the JavaDoc which was not meaningful. Revision 1577683 adds the ability to get a COSName from a COSDictionary for connivence. I've made the fix to PDFontFactory in revision 1577725 in trunk and 1577728 in 1.8 PDFBox ExtractText issue of PDF with no embedded fonts -- Key: PDFBOX-1988 URL: https://issues.apache.org/jira/browse/PDFBOX-1988 Project: PDFBox Issue Type: Bug Components: Rendering, Text extraction Affects Versions: 1.8.4 Environment: Windows 7 Also, PASE on IBM i Reporter: Craig Strong Labels: patch Fix For: 1.8.5, 2.0.0 Attachments: Test1.pdf Original Estimate: 120h Remaining Estimate: 120h I have been using PDFBox 1.8.4 to extract text from several different PDF files fine. I use the latest PDFBox app with ExtractText command line. There is one PDF that PDFBox (and iText) fails to extract any text even though I can extract the text with Adobe Reader and also pdftotext.exe part of XPdf. java -jar pdfbox-app-1.8.4.jar ExtractText Test1.pdf Out.txt. I don't want to have to rely on using pdftotext.exe from a PC since this is part of an automated application. I think the error relates to an unknown font type and having to use the few fonts installed in the jar file. I tried running the API classes and trying to force a font from a certain location but I still got errors. I thought I loaded the font with the loadTTF method but I don't know if that did anything with the font. I would really like to have this working straight from the ExtractText class anyway. Here are the errors I am getting. I tried this from both a Windows 7 PC and our IBM i in the PASE environment but I get the same errors. The section starting processEncodedText and on repeats a few times so I just included the first entries. Mar 10, 2014 3:50:44 PM org.apache.pdfbox.pdmodel.font.PDFontFactory createFont WARNING: Substituting TrueType for unknown font subtype= Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processOperator WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:375) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.ensureFontDescriptor(PDTrueTypeFont.java:221) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.init(PDTrueTypeFont.java:119) at org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:121) at org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:204) at org.apache.pdfbox.util.PDFStreamEngine.getFonts(PDFStreamEngine.java:604) at org.apache.pdfbox.util.operator.SetTextFont.process(SetTextFont.java:54) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) at org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) at org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456) at org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381) at org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340) at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:275) at org.apache.pdfbox.ExtractText.main(ExtractText.java:85) at org.apache.pdfbox.PDFBox.main(PDFBox.java:58) Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processEncodedText WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at
[jira] [Commented] (PDFBOX-1988) PDFBox ExtractText issue of PDF with no embedded fonts
[
https://issues.apache.org/jira/browse/PDFBOX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935693#comment-13935693
]
John Hewson commented on PDFBOX-1988:
-
{quote}
adding a line for Courier-Bold in the PDFBox_External_Fonts.properties file.
{quote}
Courier-Bold is one of the Standard 14 fonts, it's not an external font.
PDFBox ExtractText issue of PDF with no embedded fonts
--
Key: PDFBOX-1988
URL: https://issues.apache.org/jira/browse/PDFBOX-1988
Project: PDFBox
Issue Type: Bug
Components: Rendering, Text extraction
Affects Versions: 1.8.4
Environment: Windows 7
Also, PASE on IBM i
Reporter: Craig Strong
Labels: patch
Fix For: 1.8.5, 2.0.0
Attachments: Test1.pdf
Original Estimate: 120h
Remaining Estimate: 120h
I have been using PDFBox 1.8.4 to extract text from several different PDF
files fine. I use the latest PDFBox app with ExtractText command line.
There is one PDF that PDFBox (and iText) fails to extract any text even
though I can extract the text with Adobe Reader and also pdftotext.exe part
of XPdf. java -jar pdfbox-app-1.8.4.jar ExtractText Test1.pdf Out.txt. I
don't want to have to rely on using pdftotext.exe from a PC since this is
part of an automated application. I think the error relates to an unknown
font type and having to use the few fonts installed in the jar file. I tried
running the API classes and trying to force a font from a certain location
but I still got errors. I thought I loaded the font with the loadTTF method
but I don't know if that did anything with the font. I would really like to
have this working straight from the ExtractText class anyway.
Here are the errors I am getting. I tried this from both a Windows 7 PC and
our IBM i in the PASE environment but I get the same errors. The section
starting processEncodedText and on repeats a few times so I just included the
first entries.
Mar 10, 2014 3:50:44 PM org.apache.pdfbox.pdmodel.font.PDFontFactory
createFont
WARNING: Substituting TrueType for unknown font subtype=
Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine
processOperator
WARNING: java.lang.NullPointerException
Throwable occurred: java.lang.NullPointerException
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:375)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.ensureFontDescriptor(PDTrueTypeFont.java:221)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.init(PDTrueTypeFont.java:119)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:121)
at
org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:204)
at
org.apache.pdfbox.util.PDFStreamEngine.getFonts(PDFStreamEngine.java:604)
at
org.apache.pdfbox.util.operator.SetTextFont.process(SetTextFont.java:54)
at
org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554)
at
org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268)
at
org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235)
at
org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215)
at
org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456)
at
org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381)
at
org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340)
at
org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:275)
at org.apache.pdfbox.ExtractText.main(ExtractText.java:85)
at org.apache.pdfbox.PDFBox.main(PDFBox.java:58)
Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine
processEncodedText
WARNING: java.lang.NullPointerException
Throwable occurred: java.lang.NullPointerException
at
org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:355)
at org.apache.pdfbox.util.operator.ShowText.process(ShowText.java:45)
at
org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554)
[jira] [Issue Comment Deleted] (PDFBOX-1988) PDFBox ExtractText issue of PDF with no embedded fonts
[
https://issues.apache.org/jira/browse/PDFBOX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson updated PDFBOX-1988:
Comment: was deleted
(was: {quote}
adding a line for Courier-Bold in the PDFBox_External_Fonts.properties file.
{quote}
Courier-Bold is one of the Standard 14 fonts, it's not an external font. Also
it's a Type 1 font.)
PDFBox ExtractText issue of PDF with no embedded fonts
--
Key: PDFBOX-1988
URL: https://issues.apache.org/jira/browse/PDFBOX-1988
Project: PDFBox
Issue Type: Bug
Components: Rendering, Text extraction
Affects Versions: 1.8.4
Environment: Windows 7
Also, PASE on IBM i
Reporter: Craig Strong
Labels: patch
Fix For: 1.8.5, 2.0.0
Attachments: Test1.pdf
Original Estimate: 120h
Remaining Estimate: 120h
I have been using PDFBox 1.8.4 to extract text from several different PDF
files fine. I use the latest PDFBox app with ExtractText command line.
There is one PDF that PDFBox (and iText) fails to extract any text even
though I can extract the text with Adobe Reader and also pdftotext.exe part
of XPdf. java -jar pdfbox-app-1.8.4.jar ExtractText Test1.pdf Out.txt. I
don't want to have to rely on using pdftotext.exe from a PC since this is
part of an automated application. I think the error relates to an unknown
font type and having to use the few fonts installed in the jar file. I tried
running the API classes and trying to force a font from a certain location
but I still got errors. I thought I loaded the font with the loadTTF method
but I don't know if that did anything with the font. I would really like to
have this working straight from the ExtractText class anyway.
Here are the errors I am getting. I tried this from both a Windows 7 PC and
our IBM i in the PASE environment but I get the same errors. The section
starting processEncodedText and on repeats a few times so I just included the
first entries.
Mar 10, 2014 3:50:44 PM org.apache.pdfbox.pdmodel.font.PDFontFactory
createFont
WARNING: Substituting TrueType for unknown font subtype=
Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine
processOperator
WARNING: java.lang.NullPointerException
Throwable occurred: java.lang.NullPointerException
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:375)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.ensureFontDescriptor(PDTrueTypeFont.java:221)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.init(PDTrueTypeFont.java:119)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:121)
at
org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:204)
at
org.apache.pdfbox.util.PDFStreamEngine.getFonts(PDFStreamEngine.java:604)
at
org.apache.pdfbox.util.operator.SetTextFont.process(SetTextFont.java:54)
at
org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554)
at
org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268)
at
org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235)
at
org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215)
at
org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456)
at
org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381)
at
org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340)
at
org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:275)
at org.apache.pdfbox.ExtractText.main(ExtractText.java:85)
at org.apache.pdfbox.PDFBox.main(PDFBox.java:58)
Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine
processEncodedText
WARNING: java.lang.NullPointerException
Throwable occurred: java.lang.NullPointerException
at
org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:355)
at org.apache.pdfbox.util.operator.ShowText.process(ShowText.java:45)
at
org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554)
[jira] [Commented] (PDFBOX-1988) PDFBox ExtractText issue of PDF with no embedded fonts
[ https://issues.apache.org/jira/browse/PDFBOX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935699#comment-13935699 ] John Hewson commented on PDFBOX-1988: - Tilman, I checked with my fix in revision 1577725 and 2.0 rendering is now good. PDFBox ExtractText issue of PDF with no embedded fonts -- Key: PDFBOX-1988 URL: https://issues.apache.org/jira/browse/PDFBOX-1988 Project: PDFBox Issue Type: Bug Components: Rendering, Text extraction Affects Versions: 1.8.4 Environment: Windows 7 Also, PASE on IBM i Reporter: Craig Strong Labels: patch Fix For: 1.8.5, 2.0.0 Attachments: Test1.pdf Original Estimate: 120h Remaining Estimate: 120h I have been using PDFBox 1.8.4 to extract text from several different PDF files fine. I use the latest PDFBox app with ExtractText command line. There is one PDF that PDFBox (and iText) fails to extract any text even though I can extract the text with Adobe Reader and also pdftotext.exe part of XPdf. java -jar pdfbox-app-1.8.4.jar ExtractText Test1.pdf Out.txt. I don't want to have to rely on using pdftotext.exe from a PC since this is part of an automated application. I think the error relates to an unknown font type and having to use the few fonts installed in the jar file. I tried running the API classes and trying to force a font from a certain location but I still got errors. I thought I loaded the font with the loadTTF method but I don't know if that did anything with the font. I would really like to have this working straight from the ExtractText class anyway. Here are the errors I am getting. I tried this from both a Windows 7 PC and our IBM i in the PASE environment but I get the same errors. The section starting processEncodedText and on repeats a few times so I just included the first entries. Mar 10, 2014 3:50:44 PM org.apache.pdfbox.pdmodel.font.PDFontFactory createFont WARNING: Substituting TrueType for unknown font subtype= Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processOperator WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:375) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.ensureFontDescriptor(PDTrueTypeFont.java:221) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.init(PDTrueTypeFont.java:119) at org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:121) at org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:204) at org.apache.pdfbox.util.PDFStreamEngine.getFonts(PDFStreamEngine.java:604) at org.apache.pdfbox.util.operator.SetTextFont.process(SetTextFont.java:54) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) at org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) at org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456) at org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381) at org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340) at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:275) at org.apache.pdfbox.ExtractText.main(ExtractText.java:85) at org.apache.pdfbox.PDFBox.main(PDFBox.java:58) Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processEncodedText WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:355) at org.apache.pdfbox.util.operator.ShowText.process(ShowText.java:45) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at
[jira] [Commented] (PDFBOX-1969) JPEGFactory bug
[ https://issues.apache.org/jira/browse/PDFBOX-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935702#comment-13935702 ] Tilman Hausherr commented on PDFBOX-1969: - I first isolated the JPEG only stuff to deal with shorter code. I then applied a similar change than I did in CCITT. The test now works. An image-to-pdf test I did (temporarly modified the example to use that method) also worked. What I couldn't test is whether the alpha thing works, i.e. whether it is possible to put a semi transparent jpeg in a PDF. This was done in rev 1577734 and rev 1577735. John, please review this, if you want. JPEGFactory bug --- Key: PDFBOX-1969 URL: https://issues.apache.org/jira/browse/PDFBOX-1969 Project: PDFBox Issue Type: Bug Reporter: Steven Burg Attempted to run the RubberStampWithImage sample and received the following errors: Exception in thread main java.lang.NullPointerException at org.apache.pdfbox.pdmodel.graphics.image.JPEGFactory.createFromStream(JPEGFactory.java:72) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.doIt(RubberStampWithImage.java:93) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.main(RubberStampWithImage.java:185) This happens with any jog I tested with. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-1988) PDFBox ExtractText issue of PDF with no embedded fonts
[ https://issues.apache.org/jira/browse/PDFBOX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935713#comment-13935713 ] Tilman Hausherr commented on PDFBOX-1988: - Yeah, works great! PDFBox ExtractText issue of PDF with no embedded fonts -- Key: PDFBOX-1988 URL: https://issues.apache.org/jira/browse/PDFBOX-1988 Project: PDFBox Issue Type: Bug Components: Rendering, Text extraction Affects Versions: 1.8.4 Environment: Windows 7 Also, PASE on IBM i Reporter: Craig Strong Labels: patch Fix For: 1.8.5, 2.0.0 Attachments: Test1.pdf Original Estimate: 120h Remaining Estimate: 120h I have been using PDFBox 1.8.4 to extract text from several different PDF files fine. I use the latest PDFBox app with ExtractText command line. There is one PDF that PDFBox (and iText) fails to extract any text even though I can extract the text with Adobe Reader and also pdftotext.exe part of XPdf. java -jar pdfbox-app-1.8.4.jar ExtractText Test1.pdf Out.txt. I don't want to have to rely on using pdftotext.exe from a PC since this is part of an automated application. I think the error relates to an unknown font type and having to use the few fonts installed in the jar file. I tried running the API classes and trying to force a font from a certain location but I still got errors. I thought I loaded the font with the loadTTF method but I don't know if that did anything with the font. I would really like to have this working straight from the ExtractText class anyway. Here are the errors I am getting. I tried this from both a Windows 7 PC and our IBM i in the PASE environment but I get the same errors. The section starting processEncodedText and on repeats a few times so I just included the first entries. Mar 10, 2014 3:50:44 PM org.apache.pdfbox.pdmodel.font.PDFontFactory createFont WARNING: Substituting TrueType for unknown font subtype= Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processOperator WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.loadDescriptorDictionary(PDTrueTypeFont.java:375) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.ensureFontDescriptor(PDTrueTypeFont.java:221) at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.init(PDTrueTypeFont.java:119) at org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:121) at org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:204) at org.apache.pdfbox.util.PDFStreamEngine.getFonts(PDFStreamEngine.java:604) at org.apache.pdfbox.util.operator.SetTextFont.process(SetTextFont.java:54) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) at org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) at org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:456) at org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:381) at org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:340) at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:275) at org.apache.pdfbox.ExtractText.main(ExtractText.java:85) at org.apache.pdfbox.PDFBox.main(PDFBox.java:58) Mar 10, 2014 3:50:45 PM org.apache.pdfbox.util.PDFStreamEngine processEncodedText WARNING: java.lang.NullPointerException Throwable occurred: java.lang.NullPointerException at org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:355) at org.apache.pdfbox.util.operator.ShowText.process(ShowText.java:45) at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:554) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[ https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935714#comment-13935714 ] John Hewson edited comment on PDFBOX-1847 at 3/14/14 9:55 PM: -- 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, as it is always the same when the document contents is the same. was (Author: jahewson): 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom. TSA Time Signature -- Key: PDFBOX-1847 URL: https://issues.apache.org/jira/browse/PDFBOX-1847 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.0 Reporter: vakhtang koroghlishvili Assignee: John Hewson Fix For: 2.0.0 Attachments: CreateSignature-updated.java.patch, TSATimeSignature.patch, resultOfSigning.jpg When we was signing document, we was using time from our time. For more security we can use Time Stamp server. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.(wiki) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[ https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935714#comment-13935714 ] John Hewson edited comment on PDFBOX-1847 at 3/14/14 9:54 PM: -- 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom. was (Author: jahewson): 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom. TSA Time Signature -- Key: PDFBOX-1847 URL: https://issues.apache.org/jira/browse/PDFBOX-1847 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.0 Reporter: vakhtang koroghlishvili Assignee: John Hewson Fix For: 2.0.0 Attachments: CreateSignature-updated.java.patch, TSATimeSignature.patch, resultOfSigning.jpg When we was signing document, we was using time from our time. For more security we can use Time Stamp server. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.(wiki) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[ https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935714#comment-13935714 ] John Hewson edited comment on PDFBOX-1847 at 3/14/14 9:56 PM: -- 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, as it is always the same when the document contents are the same. was (Author: jahewson): 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, as it is always the same when the document contents is the same. TSA Time Signature -- Key: PDFBOX-1847 URL: https://issues.apache.org/jira/browse/PDFBOX-1847 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.0 Reporter: vakhtang koroghlishvili Assignee: John Hewson Fix For: 2.0.0 Attachments: CreateSignature-updated.java.patch, TSATimeSignature.patch, resultOfSigning.jpg When we was signing document, we was using time from our time. For more security we can use Time Stamp server. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.(wiki) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[ https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935714#comment-13935714 ] John Hewson edited comment on PDFBOX-1847 at 3/14/14 9:59 PM: -- 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, e.g. the hash is always the same when the document contents are the same. was (Author: jahewson): 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, as it is always the same when the document contents are the same. TSA Time Signature -- Key: PDFBOX-1847 URL: https://issues.apache.org/jira/browse/PDFBOX-1847 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.0 Reporter: vakhtang koroghlishvili Assignee: John Hewson Fix For: 2.0.0 Attachments: CreateSignature-updated.java.patch, TSATimeSignature.patch, resultOfSigning.jpg When we was signing document, we was using time from our time. For more security we can use Time Stamp server. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.(wiki) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[ https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935714#comment-13935714 ] John Hewson edited comment on PDFBOX-1847 at 3/14/14 10:00 PM: --- 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, e.g. the hash is always the same when the document contents are the same. In fact, if multiplying by the hash causes the value to overflow you will actually loose entropy and decrease security. was (Author: jahewson): 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, e.g. the hash is always the same when the document contents are the same. TSA Time Signature -- Key: PDFBOX-1847 URL: https://issues.apache.org/jira/browse/PDFBOX-1847 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.0 Reporter: vakhtang koroghlishvili Assignee: John Hewson Fix For: 2.0.0 Attachments: CreateSignature-updated.java.patch, TSATimeSignature.patch, resultOfSigning.jpg When we was signing document, we was using time from our time. For more security we can use Time Stamp server. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.(wiki) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[ https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935714#comment-13935714 ] John Hewson edited comment on PDFBOX-1847 at 3/14/14 10:02 PM: --- 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, e.g. the hash is always the same when the document contents are the same. In fact, if multiplying by the hash causes the value to overflow you will actually loose entropy, decreasing security. was (Author: jahewson): 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, e.g. the hash is always the same when the document contents are the same. In fact, if multiplying by the hash causes the value to overflow you will actually loose entropy and decrease security. TSA Time Signature -- Key: PDFBOX-1847 URL: https://issues.apache.org/jira/browse/PDFBOX-1847 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.0 Reporter: vakhtang koroghlishvili Assignee: John Hewson Fix For: 2.0.0 Attachments: CreateSignature-updated.java.patch, TSATimeSignature.patch, resultOfSigning.jpg When we was signing document, we was using time from our time. For more security we can use Time Stamp server. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.(wiki) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[ https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935714#comment-13935714 ] John Hewson edited comment on PDFBOX-1847 at 3/14/14 10:03 PM: --- 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, e.g. the hash is always the same when the document contents are the same. In fact, if multiplying by the hash causes the nonce to overflow you will actually loose entropy resulting in less security. was (Author: jahewson): 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, e.g. the hash is always the same when the document contents are the same. In fact, if multiplying by the hash causes the nonce to overflow you will actually loose entropy resulting in lower security. TSA Time Signature -- Key: PDFBOX-1847 URL: https://issues.apache.org/jira/browse/PDFBOX-1847 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.0 Reporter: vakhtang koroghlishvili Assignee: John Hewson Fix For: 2.0.0 Attachments: CreateSignature-updated.java.patch, TSATimeSignature.patch, resultOfSigning.jpg When we was signing document, we was using time from our time. For more security we can use Time Stamp server. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.(wiki) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature
[ https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935714#comment-13935714 ] John Hewson edited comment on PDFBOX-1847 at 3/14/14 10:03 PM: --- 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, e.g. the hash is always the same when the document contents are the same. In fact, if multiplying by the hash causes the nonce to overflow you will actually loose entropy resulting in lower security. was (Author: jahewson): 1. Ok, will use Java's SHA-256 2. Ok, will use the a 32-bit range instead. 3. :) 4. Ok, will remove the header 5. Yes, please do. The IOExceptions are fine, it's just the fact that ClassCastException should not be thrown by bouncy castle (but it could be possible). 6. I would advise against using your own sources of entropy, SecureRandom is already able to provide cryptographically secure random numbers and the document hash is almost certainly less random than the randomness produced by SecureRandom, e.g. the hash is always the same when the document contents are the same. In fact, if multiplying by the hash causes the value to overflow you will actually loose entropy resulting in lower security. TSA Time Signature -- Key: PDFBOX-1847 URL: https://issues.apache.org/jira/browse/PDFBOX-1847 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.0 Reporter: vakhtang koroghlishvili Assignee: John Hewson Fix For: 2.0.0 Attachments: CreateSignature-updated.java.patch, TSATimeSignature.patch, resultOfSigning.jpg When we was signing document, we was using time from our time. For more security we can use Time Stamp server. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one — not even the owner of the document — should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.(wiki) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PDFBOX-1969) JPEGFactory bug
[ https://issues.apache.org/jira/browse/PDFBOX-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-1969: Fix Version/s: 2.0.0 JPEGFactory bug --- Key: PDFBOX-1969 URL: https://issues.apache.org/jira/browse/PDFBOX-1969 Project: PDFBox Issue Type: Bug Affects Versions: 2.0.0 Reporter: Steven Burg Fix For: 2.0.0 Attempted to run the RubberStampWithImage sample and received the following errors: Exception in thread main java.lang.NullPointerException at org.apache.pdfbox.pdmodel.graphics.image.JPEGFactory.createFromStream(JPEGFactory.java:72) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.doIt(RubberStampWithImage.java:93) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.main(RubberStampWithImage.java:185) This happens with any jog I tested with. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PDFBOX-1969) JPEGFactory bug
[ https://issues.apache.org/jira/browse/PDFBOX-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-1969: Affects Version/s: 2.0.0 JPEGFactory bug --- Key: PDFBOX-1969 URL: https://issues.apache.org/jira/browse/PDFBOX-1969 Project: PDFBox Issue Type: Bug Affects Versions: 2.0.0 Reporter: Steven Burg Fix For: 2.0.0 Attempted to run the RubberStampWithImage sample and received the following errors: Exception in thread main java.lang.NullPointerException at org.apache.pdfbox.pdmodel.graphics.image.JPEGFactory.createFromStream(JPEGFactory.java:72) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.doIt(RubberStampWithImage.java:93) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.main(RubberStampWithImage.java:185) This happens with any jog I tested with. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-1969) JPEGFactory bug
[ https://issues.apache.org/jira/browse/PDFBOX-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935918#comment-13935918 ] John Hewson commented on PDFBOX-1969: - Thanks, that's great. I've never encountered a transparent JPEG, though they are part of the spec. Maybe I can make one in Photoshop. JPEGFactory bug --- Key: PDFBOX-1969 URL: https://issues.apache.org/jira/browse/PDFBOX-1969 Project: PDFBox Issue Type: Bug Affects Versions: 2.0.0 Reporter: Steven Burg Fix For: 2.0.0 Attempted to run the RubberStampWithImage sample and received the following errors: Exception in thread main java.lang.NullPointerException at org.apache.pdfbox.pdmodel.graphics.image.JPEGFactory.createFromStream(JPEGFactory.java:72) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.doIt(RubberStampWithImage.java:93) at org.apache.pdfbox.examples.pdmodel.RubberStampWithImage.main(RubberStampWithImage.java:185) This happens with any jog I tested with. -- This message was sent by Atlassian JIRA (v6.2#6252)
