[jira] [Commented] (PDFBOX-5157) allow to make timestamp only signature "LTV"
[
https://issues.apache.org/jira/browse/PDFBOX-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17319813#comment-17319813
]
Ralf Hauser commented on PDFBOX-5157:
-
Thanks - tested [https://svn.apache.org/r1888679] - works like charm !
> allow to make timestamp only signature "LTV"
>
>
> Key: PDFBOX-5157
> URL: https://issues.apache.org/jira/browse/PDFBOX-5157
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 3.0.0 PDFBox
>Reporter: Ralf Hauser
>Priority: Minor
> Attachments: timestamped_PDFBOX-5157.pdf
>
>
> To make TestCreateSignature.testCreateSignedTimeStamp() timestamp.pdf
> (ETSI.RFC3161) conformant with LTV, I had to enhance AddValidationInformation
> :
>
> {noformat}
> ### Eclipse Workspace Patch 1.0
> #P pdfbox
> Index:
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> ===
> ---
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (revision 1885032)
> +++
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (working copy)
> @@ -30,6 +30,7 @@
> import java.security.cert.X509CRL;
> import java.security.cert.X509Certificate;
> import java.util.Calendar;
> +import java.util.Date;
> import java.util.HashSet;
> import java.util.Set;
>
> @@ -355,9 +356,15 @@
> // This certificate has been OCSP-checked before
> return;
> }
> - OcspHelper ocspHelper = new OcspHelper(
> + Date time = null;
> + if (null == signDate) {
> + time = new Date(); //should rather take timestampTime
> + } else {
> + time = signDate.getTime();
> + }
> + OcspHelper ocspHelper = new OcspHelper(
> certInfo.getCertificate(),
> - signDate.getTime(),
> + time,
> certInfo.getIssuerCertificate(),
> new HashSet<>(certInformationHelper.getCertificateSet()),
> certInfo.getOcspUrl());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5157) allow to make timestamp only signature "LTV"
[
https://issues.apache.org/jira/browse/PDFBOX-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Hauser updated PDFBOX-5157:
Attachment: timestamped_PDFBOX-5157.pdf
> allow to make timestamp only signature "LTV"
>
>
> Key: PDFBOX-5157
> URL: https://issues.apache.org/jira/browse/PDFBOX-5157
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 3.0.0 PDFBox
>Reporter: Ralf Hauser
>Priority: Minor
> Attachments: timestamped_PDFBOX-5157.pdf
>
>
> To make TestCreateSignature.testCreateSignedTimeStamp() timestamp.pdf
> (ETSI.RFC3161) conformant with LTV, I had to enhance AddValidationInformation
> :
>
> {noformat}
> ### Eclipse Workspace Patch 1.0
> #P pdfbox
> Index:
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> ===
> ---
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (revision 1885032)
> +++
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (working copy)
> @@ -30,6 +30,7 @@
> import java.security.cert.X509CRL;
> import java.security.cert.X509Certificate;
> import java.util.Calendar;
> +import java.util.Date;
> import java.util.HashSet;
> import java.util.Set;
>
> @@ -355,9 +356,15 @@
> // This certificate has been OCSP-checked before
> return;
> }
> - OcspHelper ocspHelper = new OcspHelper(
> + Date time = null;
> + if (null == signDate) {
> + time = new Date(); //should rather take timestampTime
> + } else {
> + time = signDate.getTime();
> + }
> + OcspHelper ocspHelper = new OcspHelper(
> certInfo.getCertificate(),
> - signDate.getTime(),
> + time,
> certInfo.getIssuerCertificate(),
> new HashSet<>(certInformationHelper.getCertificateSet()),
> certInfo.getOcspUrl());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5157) allow to make timestamp only signature "LTV"
[
https://issues.apache.org/jira/browse/PDFBOX-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17319086#comment-17319086
]
Ralf Hauser commented on PDFBOX-5157:
-
the test output [^timestamped_PDFBOX-5157.pdf] as per your request
> allow to make timestamp only signature "LTV"
>
>
> Key: PDFBOX-5157
> URL: https://issues.apache.org/jira/browse/PDFBOX-5157
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 3.0.0 PDFBox
>Reporter: Ralf Hauser
>Priority: Minor
> Attachments: timestamped_PDFBOX-5157.pdf
>
>
> To make TestCreateSignature.testCreateSignedTimeStamp() timestamp.pdf
> (ETSI.RFC3161) conformant with LTV, I had to enhance AddValidationInformation
> :
>
> {noformat}
> ### Eclipse Workspace Patch 1.0
> #P pdfbox
> Index:
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> ===
> ---
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (revision 1885032)
> +++
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (working copy)
> @@ -30,6 +30,7 @@
> import java.security.cert.X509CRL;
> import java.security.cert.X509Certificate;
> import java.util.Calendar;
> +import java.util.Date;
> import java.util.HashSet;
> import java.util.Set;
>
> @@ -355,9 +356,15 @@
> // This certificate has been OCSP-checked before
> return;
> }
> - OcspHelper ocspHelper = new OcspHelper(
> + Date time = null;
> + if (null == signDate) {
> + time = new Date(); //should rather take timestampTime
> + } else {
> + time = signDate.getTime();
> + }
> + OcspHelper ocspHelper = new OcspHelper(
> certInfo.getCertificate(),
> - signDate.getTime(),
> + time,
> certInfo.getIssuerCertificate(),
> new HashSet<>(certInformationHelper.getCertificateSet()),
> certInfo.getOcspUrl());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5157) allow to make timestamp only signature "LTV"
[
https://issues.apache.org/jira/browse/PDFBOX-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17319032#comment-17319032
]
Ralf Hauser commented on PDFBOX-5157:
-
> But why would signDate (comes from {{signature.getSignDate()}}) be null in
> the first place?
Because the timestamp.pdf from your Test
TestCreateSignature.testCreateSignedTimeStamp() ist not a *normal* signature,
but "only" ETSI.RFC3161-compliant.
Shall I add the output of the test ?
> allow to make timestamp only signature "LTV"
>
>
> Key: PDFBOX-5157
> URL: https://issues.apache.org/jira/browse/PDFBOX-5157
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 3.0.0 PDFBox
>Reporter: Ralf Hauser
>Priority: Minor
>
> To make TestCreateSignature.testCreateSignedTimeStamp() timestamp.pdf
> (ETSI.RFC3161) conformant with LTV, I had to enhance AddValidationInformation
> :
>
> {noformat}
> ### Eclipse Workspace Patch 1.0
> #P pdfbox
> Index:
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> ===
> ---
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (revision 1885032)
> +++
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (working copy)
> @@ -30,6 +30,7 @@
> import java.security.cert.X509CRL;
> import java.security.cert.X509Certificate;
> import java.util.Calendar;
> +import java.util.Date;
> import java.util.HashSet;
> import java.util.Set;
>
> @@ -355,9 +356,15 @@
> // This certificate has been OCSP-checked before
> return;
> }
> - OcspHelper ocspHelper = new OcspHelper(
> + Date time = null;
> + if (null == signDate) {
> + time = new Date(); //should rather take timestampTime
> + } else {
> + time = signDate.getTime();
> + }
> + OcspHelper ocspHelper = new OcspHelper(
> certInfo.getCertificate(),
> - signDate.getTime(),
> + time,
> certInfo.getIssuerCertificate(),
> new HashSet<>(certInformationHelper.getCertificateSet()),
> certInfo.getOcspUrl());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5157) allow to make timestamp only signature "LTV"
[
https://issues.apache.org/jira/browse/PDFBOX-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Hauser updated PDFBOX-5157:
Issue Type: Improvement (was: Bug)
> allow to make timestamp only signature "LTV"
>
>
> Key: PDFBOX-5157
> URL: https://issues.apache.org/jira/browse/PDFBOX-5157
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 3.0.0 PDFBox
>Reporter: Ralf Hauser
>Priority: Minor
>
> To make TestCreateSignature.testCreateSignedTimeStamp() timestamp.pdf
> (ETSI.RFC3161) conformant with LTV, I had to enhance AddValidationInformation
> :
>
> ### Eclipse Workspace Patch 1.0
> #P pdfbox
> Index:
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> ===
> ---
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (revision 1885032)
> +++
> examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
> (working copy)
> @@ -30,6 +30,7 @@
> import java.security.cert.X509CRL;
> import java.security.cert.X509Certificate;
> import java.util.Calendar;
> +import java.util.Date;
> import java.util.HashSet;
> import java.util.Set;
>
> @@ -355,9 +356,15 @@
> // This certificate has been OCSP-checked before
> return;
> }
> - OcspHelper ocspHelper = new OcspHelper(
> + Date time = null;
> + if (null == signDate) {
> + time = new Date(); //should rather take timestampTime
> + } else {
> + time = signDate.getTime();
> + }
> + OcspHelper ocspHelper = new OcspHelper(
> certInfo.getCertificate(),
> - signDate.getTime(),
> + time,
> certInfo.getIssuerCertificate(),
> new HashSet<>(certInformationHelper.getCertificateSet()),
> certInfo.getOcspUrl());
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5157) allow to make timestamp only signature "LTV"
Ralf Hauser created PDFBOX-5157:
---
Summary: allow to make timestamp only signature "LTV"
Key: PDFBOX-5157
URL: https://issues.apache.org/jira/browse/PDFBOX-5157
Project: PDFBox
Issue Type: Bug
Affects Versions: 3.0.0 PDFBox
Reporter: Ralf Hauser
To make TestCreateSignature.testCreateSignedTimeStamp() timestamp.pdf
(ETSI.RFC3161) conformant with LTV, I had to enhance AddValidationInformation :
### Eclipse Workspace Patch 1.0
#P pdfbox
Index:
examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
===
---
examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
(revision 1885032)
+++
examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
(working copy)
@@ -30,6 +30,7 @@
import java.security.cert.X509CRL;
import java.security.cert.X509Certificate;
import java.util.Calendar;
+import java.util.Date;
import java.util.HashSet;
import java.util.Set;
@@ -355,9 +356,15 @@
// This certificate has been OCSP-checked before
return;
}
- OcspHelper ocspHelper = new OcspHelper(
+ Date time = null;
+ if (null == signDate) {
+ time = new Date(); //should rather take timestampTime
+ } else {
+ time = signDate.getTime();
+ }
+ OcspHelper ocspHelper = new OcspHelper(
certInfo.getCertificate(),
- signDate.getTime(),
+ time,
certInfo.getIssuerCertificate(),
new HashSet<>(certInformationHelper.getCertificateSet()),
certInfo.getOcspUrl());
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-135) AES Support
[ https://issues.apache.org/jira/browse/PDFBOX-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17282866#comment-17282866 ] Ralf Hauser commented on PDFBOX-135: another test file in https://github.com/LibrePDF/OpenPDF/issues/375 > AES Support > --- > > Key: PDFBOX-135 > URL: https://issues.apache.org/jira/browse/PDFBOX-135 > Project: PDFBox > Issue Type: New Feature > Components: Writing >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 1.4.0 > > > [imported from SourceForge] > http://sourceforge.net/tracker/index.php?group_id=78314=552832=1432143 > Originally submitted by nobody on 2006-02-15 05:05. > Hi, it should be right time now to add AES support > which is in default enabled on all encrypted PDF > documents made by Adobe Acrobat 7.0. > Since AES is supported by java JCE it should not be a > big deal. Currently only Big Faceless PDF Library seems > to support it. > Thanks for big help. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5070) LTV: allow to gather OCSP responses before signing
[ https://issues.apache.org/jira/browse/PDFBOX-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267756#comment-17267756 ] Ralf Hauser commented on PDFBOX-5070: - Initial thoughts how to implement this: 1) the LTV info (preferrably ocspResp from AddValidationInformation.addOscpData() or super-short CRLs) should be retrieved before setting the M Date in the SIG dictionary (see PDFBOX-5076 whether this should be set at all in the case an rfc3161 timestamp is added) in PDSignature.setSignDate() in Create*Signature*.java examples 2) possibly already at this time, also a fake ValidationSignedTimeStamp should be requested to learn what the tsa's Certificate is (unless we have a solid guess ahead of this) 3) in which data structure should that be held until it is handed over to AddValidationInformation.java ? Would CertInformationCollector be a viable candidate ? > LTV: allow to gather OCSP responses before signing > --- > > Key: PDFBOX-5070 > URL: https://issues.apache.org/jira/browse/PDFBOX-5070 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Minor > > Then, the OCSP responses lifetime does not start after signature time. > This obviously only can work if the signing cert serial# is known prior to > signing (see PDFBOX-2776 comment-17220875 ) > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2512) OutOfMemory while signing large documents
[
https://issues.apache.org/jira/browse/PDFBOX-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263931#comment-17263931
]
Ralf Hauser commented on PDFBOX-2512:
-
and even more continuation in PDFBOX-5068
> OutOfMemory while signing large documents
> -
>
> Key: PDFBOX-2512
> URL: https://issues.apache.org/jira/browse/PDFBOX-2512
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing, Signing
>Affects Versions: 1.8.7
>Reporter: Thomas Chojecki
>Assignee: Thomas Chojecki
>Priority: Major
> Fix For: 1.8.8
>
> Attachments: keystore.p12
>
>
> While working with large documents, we found some memory issues.
> 1. The method close() in the COSDocument, clones the objectpool and does not
> clean it properly. The cloning in getObjects() cause a OutOfMemory exception.
> 2.The COSWriter copy the whole pdf into the memory for signing and does not
> use BufferedInputStream for the FileInputStream which also has a big
> performance impact. (PDFBOX-1798)
> 3. The cloning of COSStreams cause a OutOfMemory exception
> I used the CreateSignature example with a about 150 MB big document from here:
> https://cdn-reichelt.de/bilder/downloads/reichelt_01-2015_DE_B_HQ.pdf
> Additionaly I add a RandomAccessFile to the PDDocument.load in the
> CreateSignature class.
> PDDocument doc = PDDocument.load(document,new RandomAccessFile(new
> File("d:\\temp.bin"), "rw")); (this prevent the OOM for the third case)
> The use of a BuffedInputStream in case two, will increase the signing speed
> from more than 5 minutes to less than 1 minute.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263205#comment-17263205 ] Ralf Hauser commented on PDFBOX-5068: - another one already during the initial load of a 143 MB pdf with Xmx70m ERROR [main] (TestSuite.java:1307) - Java heap space java.lang.OutOfMemoryError: Java heap space at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57) at java.nio.ByteBuffer.allocate(ByteBuffer.java:335) at org.apache.pdfbox.io.RandomAccessReadBufferedFile.createView(RandomAccessReadBufferedFile.java:260) at org.apache.pdfbox.pdfparser.COSParser.createRandomAccessReadView(COSParser.java:598) at org.apache.pdfbox.cos.COSDocument.createCOSStream(COSDocument.java:185) at org.apache.pdfbox.pdfparser.COSParser.parseCOSStream(COSParser.java:912) at org.apache.pdfbox.pdfparser.COSParser.parseFileObject(COSParser.java:705) at org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:630) at org.apache.pdfbox.pdfparser.COSParser.dereferenceCOSObject(COSParser.java:585) at org.apache.pdfbox.cos.COSObject.getObject(COSObject.java:115) at org.apache.pdfbox.pdfparser.COSParser.searchForTrailerItems(COSParser.java:1907) at org.apache.pdfbox.pdfparser.COSParser.rebuildTrailer(COSParser.java:1876) at org.apache.pdfbox.pdfparser.COSParser.retrieveTrailer(COSParser.java:263) at org.apache.pdfbox.pdfparser.PDFParser.initialParse(PDFParser.java:127) at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:180) at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:154) at org.apache.pdfbox.Loader.loadPDF(Loader.java:338) at org.apache.pdfbox.Loader.loadPDF(Loader.java:311) at org.apache.pdfbox.Loader.loadPDF(Loader.java:239) > OutOfMemory while signing large documents - continued > - > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: RandomAccessReadBufferDiag.java, minimum.pdf > > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > > This assumes the patch of PDFBOX-5067 already in place - or using > CreateVisibleSignature2.java as starting point -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5076) remove the signing time from CMS signed attributes
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262618#comment-17262618 ] Ralf Hauser commented on PDFBOX-5076: - see PDFBOX-5077 > remove the signing time from CMS signed attributes > -- > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: minimum_20210111_065849-sig.pdf, > minimum_20210111_115524-PDFBOX-5076_noCMSsigTimesig.pdf, > patch-PDFBOX-5076.txt, patch-PDFBOX-5076_noCmsSigningTime.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5077) PAdES signing: adding an ESS signing-certificate
Ralf Hauser created PDFBOX-5077: --- Summary: PAdES signing: adding an ESS signing-certificate Key: PDFBOX-5077 URL: https://issues.apache.org/jira/browse/PDFBOX-5077 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.23 Reporter: Ralf Hauser As per PDFBOX-5076, # add a ESS signing-certificate[-v2] attribute # change the subfilter # ... -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5076) remove the signing time from CMS signed attributes
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5076: Summary: remove the signing time from CMS signed attributes (was: make the signing time from CMS signed attributes) > remove the signing time from CMS signed attributes > -- > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: minimum_20210111_065849-sig.pdf, > minimum_20210111_115524-PDFBOX-5076_noCMSsigTimesig.pdf, > patch-PDFBOX-5076.txt, patch-PDFBOX-5076_noCmsSigningTime.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5076) make the signing time from CMS signed attributes
[
https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262584#comment-17262584
]
Ralf Hauser commented on PDFBOX-5076:
-
Thanks for the valuable input, [~mkl] .
So, I did the following:
# create a new patch to fulfil "there is a _requirement_ never to provide the
CMS {{signing-time}} attribute": [^patch-PDFBOX-5076_noCmsSigningTime.txt]
# tested it with [^minimum_20210111_115524-PDFBOX-5076_noCMSsigTimesig.pdf] -
Acrobat appears to fine with it
# Updated the issue title accordingly
> make the signing time from CMS signed attributes
>
>
> Key: PDFBOX-5076
> URL: https://issues.apache.org/jira/browse/PDFBOX-5076
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: minimum_20210111_065849-sig.pdf,
> minimum_20210111_115524-PDFBOX-5076_noCMSsigTimesig.pdf,
> patch-PDFBOX-5076.txt, patch-PDFBOX-5076_noCmsSigningTime.txt
>
>
> As both come from your local computer, the should be aligned
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5076) make the signing time from CMS signed attributes
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5076: Attachment: patch-PDFBOX-5076_noCmsSigningTime.txt > make the signing time from CMS signed attributes > > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: minimum_20210111_065849-sig.pdf, > minimum_20210111_115524-PDFBOX-5076_noCMSsigTimesig.pdf, > patch-PDFBOX-5076.txt, patch-PDFBOX-5076_noCmsSigningTime.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5076) make the signing time from CMS signed attributes
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5076: Attachment: minimum_20210111_115524-PDFBOX-5076_noCMSsigTimesig.pdf > make the signing time from CMS signed attributes > > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: minimum_20210111_065849-sig.pdf, > minimum_20210111_115524-PDFBOX-5076_noCMSsigTimesig.pdf, > patch-PDFBOX-5076.txt, patch-PDFBOX-5076_noCmsSigningTime.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5076) make the signing time from CMS signed attributes
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5076: Summary: make the signing time from CMS signed attributes (was: make the signing time in Pdf and CMS signed attributes the same) > make the signing time from CMS signed attributes > > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: minimum_20210111_065849-sig.pdf, patch-PDFBOX-5076.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5076) make the signing time in Pdf and CMS signed attributes the same
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5076: Summary: make the signing time in Pdf and CMS signed attributes the same (was: make the signing time in PDf and CMS signed attributes the same) > make the signing time in Pdf and CMS signed attributes the same > --- > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: minimum_20210111_065849-sig.pdf, patch-PDFBOX-5076.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-5076) make the signing time in PDf and CMS signed attributes the same
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262522#comment-17262522 ] Ralf Hauser edited comment on PDFBOX-5076 at 1/11/21, 9:34 AM: --- when using the new example, with https://issues.apache.org/jira/secure/attachment/13018274/minimum.pdf as input you get [^minimum_20210111_065849-sig.pdf] . was (Author: hau...@acm.org): when using the new example, with [^minimum.pdf] as input you get [^minimum_20210111_065849-sig.pdf] . > make the signing time in PDf and CMS signed attributes the same > --- > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: minimum_20210111_065849-sig.pdf, patch-PDFBOX-5076.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5076) make the signing time in PDf and CMS signed attributes the same
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262522#comment-17262522 ] Ralf Hauser commented on PDFBOX-5076: - when using the new example, with [^minimum.pdf] as input you get [^minimum_20210111_065849-sig.pdf] . > make the signing time in PDf and CMS signed attributes the same > --- > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: minimum_20210111_065849-sig.pdf, patch-PDFBOX-5076.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5076) make the signing time in PDf and CMS signed attributes the same
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5076: Attachment: minimum_20210111_065849-sig.pdf > make the signing time in PDf and CMS signed attributes the same > --- > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: minimum_20210111_065849-sig.pdf, patch-PDFBOX-5076.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5076) make the signing time in PDf and CMS signed attributes the same
[ https://issues.apache.org/jira/browse/PDFBOX-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5076: Attachment: patch-PDFBOX-5076.txt > make the signing time in PDf and CMS signed attributes the same > --- > > Key: PDFBOX-5076 > URL: https://issues.apache.org/jira/browse/PDFBOX-5076 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: patch-PDFBOX-5076.txt > > > As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5076) make the signing time in PDf and CMS signed attributes the same
Ralf Hauser created PDFBOX-5076: --- Summary: make the signing time in PDf and CMS signed attributes the same Key: PDFBOX-5076 URL: https://issues.apache.org/jira/browse/PDFBOX-5076 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.23 Reporter: Ralf Hauser As both come from your local computer, the should be aligned -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261269#comment-17261269
]
Ralf Hauser commented on PDFBOX-5067:
-
Hope the closeQuietly() line fills the gap with
[^patch_PDFBOX-5067_CreateVisibleSignature.b.txt] .
If it really was only that one line, I happily encourage you to just add it or
similar minor things in the future without getting back to me.
([https://svn.apache.org/r1885267] after all still ignores the valuable
suggestion of [~msahyoun] )
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch5067_CreateVisibleSignature.txt,
> patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt,
> patch_PDFBOX-5067_CreateVisibleSignature.a.txt,
> patch_PDFBOX-5067_CreateVisibleSignature.b.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Hauser updated PDFBOX-5067:
Attachment: patch_PDFBOX-5067_CreateVisibleSignature.b.txt
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch5067_CreateVisibleSignature.txt,
> patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt,
> patch_PDFBOX-5067_CreateVisibleSignature.a.txt,
> patch_PDFBOX-5067_CreateVisibleSignature.b.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Hauser updated PDFBOX-5067:
Attachment: patch_PDFBOX-5067_CreateVisibleSignature.a.txt
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch5067_CreateVisibleSignature.txt,
> patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt,
> patch_PDFBOX-5067_CreateVisibleSignature.a.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261037#comment-17261037
]
Ralf Hauser commented on PDFBOX-5067:
-
Sorry, the 2nd use "doc" was forgotten - now it is there and should accelerate
the execution [^patch5067_CreateVisibleSignature.txt]
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch5067_CreateVisibleSignature.txt,
> patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt,
> patch_PDFBOX-5067_CreateVisibleSignature.a.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260435#comment-17260435 ] Ralf Hauser commented on PDFBOX-5068: - Xmx12m was on the basis of CreateVisibleSignature.java With CreateVisibleSignature2.java, it dies java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:3236) at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118) at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153) at org.apache.fontbox.pfb.PfbParser.readPfbInput(PfbParser.java:171) at org.apache.fontbox.pfb.PfbParser.(PfbParser.java:101) at org.apache.fontbox.type1.Type1Font.createWithPFB(Type1Font.java:54) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider$FSFontInfo.getType1Font(FileSystemFontProvider.java:267) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider$FSFontInfo.getFont(FileSystemFontProvider.java:131) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:452) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:392) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:366) at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:146) at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:68) at org.apache.pdfbox.examples.signature.CreateVisibleSignature2.createVisualSignatureTemplate(CreateVisibleSignature2.java:398) at org.apache.pdfbox.examples.signature.CreateVisibleSignature2.signPDF(CreateVisibleSignature2.java:253) For CreateVisibleSignature2.java, I had to increase to Xmx19m > OutOfMemory while signing large documents - continued > - > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: RandomAccessReadBufferDiag.java, minimum.pdf > > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > > This assumes the patch of PDFBOX-5067 already in place - or using > CreateVisibleSignature2.java as starting point -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[
https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260305#comment-17260305
]
Ralf Hauser commented on PDFBOX-5068:
-
Just for reference, did a test with [^minimum.pdf] . It still creates a
correctly signed pdf with -Xmx as low as {color:#de350b}_*12*_{color}m .
Conclusion: albeit theoretically probably reachable, pdfbox is a long way away
from "constant memory signing"
> OutOfMemory while signing large documents - continued
> -
>
> Key: PDFBOX-5068
> URL: https://issues.apache.org/jira/browse/PDFBOX-5068
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: RandomAccessReadBufferDiag.java, minimum.pdf
>
>
> Continuation of PDFBOX-2512
>
> in COSWriter.prepareIncrement(), for the test case
> cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys,
> cosDoc.getObjectFromPool() gets an object that is not just referencing some
> part of the input document, but duplicates it (which is unavoidable in the
> case where they are decompressed with FlateFilter - albeit this could
> possibly be done "lazy")
> -Xmx20m 746/5925
> -Xmx25m 1615/5925
> -Xmx30m 2800/5925
> -Xmx40m 3872/5925
> -Xmx55m 5773/5925
> With 60m, it gets them all, but dies later with less telling
> java.lang.OutOfMemoryError: GC overhead limit exceeded
>
> This assumes the patch of PDFBOX-5067 already in place - or using
> CreateVisibleSignature2.java as starting point
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5068: Attachment: minimum.pdf > OutOfMemory while signing large documents - continued > - > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: RandomAccessReadBufferDiag.java, minimum.pdf > > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > > This assumes the patch of PDFBOX-5067 already in place - or using > CreateVisibleSignature2.java as starting point -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260283#comment-17260283
]
Ralf Hauser commented on PDFBOX-5067:
-
[~tilman], I tend to make fields protected to facilitate sub-classing. But if
you prefer them being private, go for it!
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch5067_CreateVisibleSignature.txt,
> patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259482#comment-17259482
]
Ralf Hauser commented on PDFBOX-5067:
-
[~msahyoun] thanks for the hint! This would be used as described in
[^patch5067_CreateVisibleSignature.txt]
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch5067_CreateVisibleSignature.txt,
> patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Hauser updated PDFBOX-5067:
Attachment: patch5067_CreateVisibleSignature.txt
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch5067_CreateVisibleSignature.txt,
> patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258941#comment-17258941 ] Ralf Hauser commented on PDFBOX-5068: - As the out-of-memory heap space happened in COSStream.java:218, I analyzed what is happening there with the help of [^RandomAccessReadBufferDiag.java] As the stack-trace shows, the prepareIncrement in COSWriter.write() appears to be the problem. i) With my test file "programWinter2015.pdf" (see PDFBOX-4297 for the signed version of it), the approx 6000 Objects all have a size up to 30K. This in itself is not a problem. ii) As it looks that approx half of them are read, but likely one after another and always sequentially except for a 1 byte rewind (so no or very little RandomAccess jumping), this is not necessarily a memory problem. The problem seems to be that the RandomAccessReadBuffer consumes its contents in the constructor and not when it's content is really read. 1) So, it could be helpful refactoring this class into a "Lazy/OnDemand" way. With that possibly ~50% of the prepareIncrement memory usage would disappear since they seem to never be read in our signature use-case. (This implies that the FlateFilter.decode is also done lazy in a (chained) Inputstream) 2) If after reading, they would be immediately deallocated, this might even lead to constant memory requirements for prepareIncrement() (this only applies if iii) no single object is really large [so no embedded movies of GB size] and iv) my assumption is correct that each object is only read once - I haven't thoroughly checked that) Being even more radical, the FileOutputStream in the end is not written using the objectKeys map assembled with prepareIncrement but uses the RandomAccessInputStream in COSWriter.writeExternalSignature() that hopefully is constant memory too. 3) So, if we do not control whether the page size/-orientation where the signature shall be placed is really correct, probably most of the prepareIncrement parsing is not needed at all for signing (no clue what happens if a visible signature is supposed to be placed outside a page ;) - or on page 20 if the document has only 10 pages) > OutOfMemory while signing large documents - continued > - > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: RandomAccessReadBufferDiag.java > > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > > This assumes the patch of PDFBOX-5067 already in place - or using > CreateVisibleSignature2.java as starting point -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5068: Attachment: RandomAccessReadBufferDiag.java > OutOfMemory while signing large documents - continued > - > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > Attachments: RandomAccessReadBufferDiag.java > > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > > This assumes the patch of PDFBOX-5067 already in place - or using > CreateVisibleSignature2.java as starting point -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5068: Description: Continuation of PDFBOX-2512 in COSWriter.prepareIncrement(), for the test case cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, cosDoc.getObjectFromPool() gets an object that is not just referencing some part of the input document, but duplicates it (which is unavoidable in the case where they are decompressed with FlateFilter - albeit this could possibly be done "lazy") -Xmx20m 746/5925 -Xmx25m 1615/5925 -Xmx30m 2800/5925 -Xmx40m 3872/5925 -Xmx55m 5773/5925 With 60m, it gets them all, but dies later with less telling java.lang.OutOfMemoryError: GC overhead limit exceeded This assumes the patch of PDFBOX-5067 already in place - or using CreateVisibleSignature2.java as starting point was: Continuation of PDFBOX-2512 in COSWriter.prepareIncrement(), for the test case cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, cosDoc.getObjectFromPool() gets an object that is not just referencing some part of the input document, but duplicates it (which is unavoidable in the case where they are decompressed with FlateFilter - albeit this could possibly be done "lazy") -Xmx20m 746/5925 -Xmx25m 1615/5925 -Xmx30m 2800/5925 -Xmx40m 3872/5925 -Xmx55m 5773/5925 With 60m, it gets them all, but dies later with less telling java.lang.OutOfMemoryError: GC overhead limit exceeded This assumes the patch of PDFBOX-5067 already in place - or using > OutOfMemory while signing large documents - continued > - > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > > This assumes the patch of PDFBOX-5067 already in place - or using > CreateVisibleSignature2.java as starting point -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5068: Description: Continuation of PDFBOX-2512 in COSWriter.prepareIncrement(), for the test case cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, cosDoc.getObjectFromPool() gets an object that is not just referencing some part of the input document, but duplicates it (which is unavoidable in the case where they are decompressed with FlateFilter - albeit this could possibly be done "lazy") -Xmx20m 746/5925 -Xmx25m 1615/5925 -Xmx30m 2800/5925 -Xmx40m 3872/5925 -Xmx55m 5773/5925 With 60m, it gets them all, but dies later with less telling java.lang.OutOfMemoryError: GC overhead limit exceeded This assumes the patch of PDFBOX-5067 already in place - or using was: Continuation of PDFBOX-2512 in COSWriter.prepareIncrement(), for the test case cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, cosDoc.getObjectFromPool() gets an object that is not just referencing some part of the input document, but duplicates it (which is unavoidable in the case where they are decompressed with FlateFilter - albeit this could possibly be done "lazy") -Xmx20m 746/5925 -Xmx25m 1615/5925 -Xmx30m 2800/5925 -Xmx40m 3872/5925 -Xmx55m 5773/5925 With 60m, it gets them all, but dies later with less telling java.lang.OutOfMemoryError: GC overhead limit exceeded This assumes the patch of PDFBOX-5067 already in place > OutOfMemory while signing large documents - continued > - > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > > This assumes the patch of PDFBOX-5067 already in place - or using -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258683#comment-17258683
]
Ralf Hauser commented on PDFBOX-5067:
-
You say "... _returns a PDDocument, which is then partly lost_"
What is the problem with that ?
It is the decision of the user of PDVisibleSignDesigner whether to "loose" the
PDDocument or reuse it with benefits.
For example, in CreateVisibleSignature1.java I can use it with significant
speed/memory benefits, with CreateVisibleSignature2.java it will be ignored (it
has been allocated in memory anyway, the change extends the lifetime in memory
in the latter case only for microseconds).
Is it really a problem to "empower" the end-user/-programmer in this way by
making one version of the method "public"?
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5070) LTV: allow to gather OCSP responses before signing
[ https://issues.apache.org/jira/browse/PDFBOX-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5070: Description: Then, the OCSP responses lifetime does not start after signature time. This obviously only can work if the signing cert serial# is known prior to signing (see PDFBOX-2776 comment-17220875 ) was: Then, the OCSP responses lifetime does not start after signature time. This obviously only can work if the signing cert serial# is known prior to signing (see PDFBOX-2776#comment-17220875 ) > LTV: allow to gather OCSP responses before signing > --- > > Key: PDFBOX-5070 > URL: https://issues.apache.org/jira/browse/PDFBOX-5070 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Minor > > Then, the OCSP responses lifetime does not start after signature time. > This obviously only can work if the signing cert serial# is known prior to > signing (see PDFBOX-2776 comment-17220875 ) > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5070) LTV: allow to gather OCSP responses before signing
Ralf Hauser created PDFBOX-5070: --- Summary: LTV: allow to gather OCSP responses before signing Key: PDFBOX-5070 URL: https://issues.apache.org/jira/browse/PDFBOX-5070 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.23 Reporter: Ralf Hauser Then, the OCSP responses lifetime does not start after signature time. This obviously only can work if the signing cert serial# is known prior to signing (see PDFBOX-2776#comment-17220875 ) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258030#comment-17258030
]
Ralf Hauser commented on PDFBOX-5067:
-
Thanks for the commit of the "uncontroversial".
Tried to make the 2nd half also acceptable with [^patch_PDFBOX-5067.txt]
What do you think ?
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Hauser updated PDFBOX-5067:
Attachment: patch_PDFBOX-5067.txt
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch_PDFBOX-2512.txt, patch_PDFBOX-5067.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
[
https://issues.apache.org/jira/browse/PDFBOX-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257857#comment-17257857
]
Ralf Hauser commented on PDFBOX-5067:
-
Thanks for the feedback
I tested it on the basis of CreateVisibleSignature2.java ( also with setupMixed
15MB )
It needed 8 MB more Xmx (==> 69m). But PDDocument was only loaded once, so in
this case, the getter is not used. Although when you close
PDVisibleSignDesigner it would be deallocated anyway.
> Some of the constructors set that field, some don't (the one that calls
> {{calculatePageSizeFromStream}})
I only added it where the test did a Loader.loadPDF() - there may well be more
places it could be added. But still, I assume it is quicker and not that worse
for the memory if the load only happens once.
> make PDVisibleSignDesigner memory aware
> ---
>
> Key: PDFBOX-5067
> URL: https://issues.apache.org/jira/browse/PDFBOX-5067
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: patch_PDFBOX-2512.txt
>
>
> PDFBOX-2512 might have failed earlier if I hadn't used
> MemoryUsageSetting.setupMixed(1500)
> to limit the memory usage of PDDocument document to 15 MB in
> CreateVisibleSignature in
>
> a) setVisibleSignDesigner() and used the now memory-aware constructor of
> PDVisibleSignDesigner
> and
> b) in signPDF(), reused PDDocument
> setTsaUrl(tsaUrl);
> PDDocument doc = null;
> if (null != visibleSignDesigner) {
> doc = visibleSignDesigner.getDocument();
> }
> if (null == doc) {
> doc = Loader.loadPDF(inputFile, memoryUsageSetting);
> }
> // creating output document and prepare the IO streams.
> ...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5068: Description: Continuation of PDFBOX-2512 in COSWriter.prepareIncrement(), for the test case cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, cosDoc.getObjectFromPool() gets an object that is not just referencing some part of the input document, but duplicates it (which is unavoidable in the case where they are decompressed with FlateFilter - albeit this could possibly be done "lazy") -Xmx20m 746/5925 -Xmx25m 1615/5925 -Xmx30m 2800/5925 -Xmx40m 3872/5925 -Xmx55m 5773/5925 With 60m, it gets them all, but dies later with less telling java.lang.OutOfMemoryError: GC overhead limit exceeded This assumes the patch of PDFBOX-5067 already in place was: Continuation of PDFBOX-2512 in COSWriter.prepareIncrement(), for the test case cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, cosDoc.getObjectFromPool() gets an object that is not just referencing some part of the input document, but duplicates it (which is unavoidable in the case where they are decompressed with FlateFilter - albeit this could possibly be done "lazy") -Xmx20m 746/5925 -Xmx25m 1615/5925 -Xmx30m 2800/5925 -Xmx40m 3872/5925 -Xmx55m 5773/5925 With 60m, it gets them all, but dies later with less telling java.lang.OutOfMemoryError: GC overhead limit exceeded > OutOfMemory while signing large documents - continued > - > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > > This assumes the patch of PDFBOX-5067 already in place -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5068) OutOfMemory while signing large documents - continued
[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5068: Summary: OutOfMemory while signing large documents - continued (was: OutOfMemory while signing large documents) > OutOfMemory while signing large documents - continued > - > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.23 >Reporter: Ralf Hauser >Priority: Major > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5068) OutOfMemory while signing large documents
Ralf Hauser created PDFBOX-5068: --- Summary: OutOfMemory while signing large documents Key: PDFBOX-5068 URL: https://issues.apache.org/jira/browse/PDFBOX-5068 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 2.0.23 Reporter: Ralf Hauser Continuation of PDFBOX-2512 in COSWriter.prepareIncrement(), for the test case cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, cosDoc.getObjectFromPool() gets an object that is not just referencing some part of the input document, but duplicates it (which is unavoidable in the case where they are decompressed with FlateFilter - albeit this could possibly be done "lazy") -Xmx20m 746/5925 -Xmx25m 1615/5925 -Xmx30m 2800/5925 -Xmx40m 3872/5925 -Xmx55m 5773/5925 With 60m, it gets them all, but dies later with less telling java.lang.OutOfMemoryError: GC overhead limit exceeded -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2512) OutOfMemory while signing large documents
[
https://issues.apache.org/jira/browse/PDFBOX-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257721#comment-17257721
]
Ralf Hauser commented on PDFBOX-2512:
-
ok, let's address this in PDFBOX-5067
> OutOfMemory while signing large documents
> -
>
> Key: PDFBOX-2512
> URL: https://issues.apache.org/jira/browse/PDFBOX-2512
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing, Signing
>Affects Versions: 1.8.7
>Reporter: Thomas Chojecki
>Assignee: Thomas Chojecki
>Priority: Major
> Fix For: 1.8.8
>
> Attachments: keystore.p12
>
>
> While working with large documents, we found some memory issues.
> 1. The method close() in the COSDocument, clones the objectpool and does not
> clean it properly. The cloning in getObjects() cause a OutOfMemory exception.
> 2.The COSWriter copy the whole pdf into the memory for signing and does not
> use BufferedInputStream for the FileInputStream which also has a big
> performance impact. (PDFBOX-1798)
> 3. The cloning of COSStreams cause a OutOfMemory exception
> I used the CreateSignature example with a about 150 MB big document from here:
> https://cdn-reichelt.de/bilder/downloads/reichelt_01-2015_DE_B_HQ.pdf
> Additionaly I add a RandomAccessFile to the PDDocument.load in the
> CreateSignature class.
> PDDocument doc = PDDocument.load(document,new RandomAccessFile(new
> File("d:\\temp.bin"), "rw")); (this prevent the OOM for the third case)
> The use of a BuffedInputStream in case two, will increase the signing speed
> from more than 5 minutes to less than 1 minute.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5067) make PDVisibleSignDesigner memory aware
Ralf Hauser created PDFBOX-5067:
---
Summary: make PDVisibleSignDesigner memory aware
Key: PDFBOX-5067
URL: https://issues.apache.org/jira/browse/PDFBOX-5067
Project: PDFBox
Issue Type: Improvement
Components: Signing
Affects Versions: 2.0.23
Reporter: Ralf Hauser
Attachments: patch_PDFBOX-2512.txt
PDFBOX-2512 might have failed earlier if I hadn't used
MemoryUsageSetting.setupMixed(1500)
to limit the memory usage of PDDocument document to 15 MB in
CreateVisibleSignature in
a) setVisibleSignDesigner() and used the now memory-aware constructor of
PDVisibleSignDesigner
and
b) in signPDF(), reused PDDocument
setTsaUrl(tsaUrl);
PDDocument doc = null;
if (null != visibleSignDesigner) {
doc = visibleSignDesigner.getDocument();
}
if (null == doc) {
doc = Loader.loadPDF(inputFile, memoryUsageSetting);
}
// creating output document and prepare the IO streams.
...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2512) OutOfMemory while signing large documents
[
https://issues.apache.org/jira/browse/PDFBOX-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257716#comment-17257716
]
Ralf Hauser commented on PDFBOX-2512:
-
Did a quick test with [^programWinter2015_20210103_091853-sig_LTV.pdf] 35MB
when doing -Xmx70m , the signature works
with -Xmx50m
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.lang.StringBuilder.toString(StringBuilder.java:407)
at org.apache.pdfbox.pdfparser.BaseParser.readLong(BaseParser.java:1281)
at
org.apache.pdfbox.pdfparser.BaseParser.readObjectNumber(BaseParser.java:1212)
at
org.apache.pdfbox.pdfparser.PDFObjectStreamParser.privateReadObjectNumbers(PDFObjectStreamParser.java:104)
at
org.apache.pdfbox.pdfparser.PDFObjectStreamParser.parseObject(PDFObjectStreamParser.java:77)
at
org.apache.pdfbox.pdfparser.COSParser.parseObjectStreamObject(COSParser.java:779)
at
org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:637)
at
org.apache.pdfbox.pdfparser.COSParser.dereferenceCOSObject(COSParser.java:586)
at org.apache.pdfbox.cos.COSObject.getObject(COSObject.java:115)
at org.apache.pdfbox.pdfwriter.COSWriter.prepareIncrement(COSWriter.java:327)
at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1425)
at org.apache.pdfbox.pdmodel.PDDocument.saveIncremental(PDDocument.java:997)
...
with -Xmx30m
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3236)
at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:191)
at org.apache.pdfbox.cos.COSStream.createView(COSStream.java:218)
at
org.apache.pdfbox.pdfparser.PDFObjectStreamParser.(PDFObjectStreamParser.java:48)
at
org.apache.pdfbox.pdfparser.COSParser.parseObjectStreamObject(COSParser.java:778)
at
org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:637)
at
org.apache.pdfbox.pdfparser.COSParser.dereferenceCOSObject(COSParser.java:586)
at org.apache.pdfbox.cos.COSObject.getObject(COSObject.java:115)
at org.apache.pdfbox.pdfwriter.COSWriter.prepareIncrement(COSWriter.java:327)
at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1425)
at org.apache.pdfbox.pdmodel.PDDocument.saveIncremental(PDDocument.java:997)
at
org.apache.pdfbox.examples.signature.CreateVisibleSignature.signPDF(CreateVisibleSignature.java:...
...
> OutOfMemory while signing large documents
> -
>
> Key: PDFBOX-2512
> URL: https://issues.apache.org/jira/browse/PDFBOX-2512
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing, Signing
>Affects Versions: 1.8.7
>Reporter: Thomas Chojecki
>Assignee: Thomas Chojecki
>Priority: Major
> Fix For: 1.8.8
>
> Attachments: keystore.p12
>
>
> While working with large documents, we found some memory issues.
> 1. The method close() in the COSDocument, clones the objectpool and does not
> clean it properly. The cloning in getObjects() cause a OutOfMemory exception.
> 2.The COSWriter copy the whole pdf into the memory for signing and does not
> use BufferedInputStream for the FileInputStream which also has a big
> performance impact. (PDFBOX-1798)
> 3. The cloning of COSStreams cause a OutOfMemory exception
> I used the CreateSignature example with a about 150 MB big document from here:
> https://cdn-reichelt.de/bilder/downloads/reichelt_01-2015_DE_B_HQ.pdf
> Additionaly I add a RandomAccessFile to the PDDocument.load in the
> CreateSignature class.
> PDDocument doc = PDDocument.load(document,new RandomAccessFile(new
> File("d:\\temp.bin"), "rw")); (this prevent the OOM for the third case)
> The use of a BuffedInputStream in case two, will increase the signing speed
> from more than 5 minutes to less than 1 minute.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5066) ShowSignature: say which digest algorithm was used, detect forged content
[
https://issues.apache.org/jira/browse/PDFBOX-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Hauser updated PDFBOX-5066:
Description:
1) SHA256 is was used by the signer to get the content digests of
target/pdfs/notCertified_368835_Sig_en_201026090509.pdf , this should be
mentioned like
System.out.println("Signature found");
so maybe
System.out.println("Signature algorithm: "+algo);
where 'algo' is for example "sha256WithRSAEncryption" (as per
[http://oidref.com/1.2.840.113549.1.1.11])
2) for subFilter="adbe.x509.rsa_sha1" it is not detected, if the pdf content is
altered.
See also PDFBOX-4297
was:
1) SHA256 is was used by the signer to get the content digests of
target/pdfs/notCertified_368835_Sig_en_201026090509.pdf , this should be
mentioned like
System.out.println("Signature found");
so maybe
System.out.println("Signature algorithm: "+algo);
where 'algo' is for example "sha256WithRSAEncryption" (as per
[http://oidref.com/1.2.840.113549.1.1.11])
2) for subFilter="adbe.x509.rsa_sha1" it is not detected, if the pdf content
is altered.
> ShowSignature: say which digest algorithm was used, detect forged content
> -
>
> Key: PDFBOX-5066
> URL: https://issues.apache.org/jira/browse/PDFBOX-5066
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Minor
>
> 1) SHA256 is was used by the signer to get the content digests of
> target/pdfs/notCertified_368835_Sig_en_201026090509.pdf , this should be
> mentioned like
> System.out.println("Signature found");
> so maybe
> System.out.println("Signature algorithm: "+algo);
> where 'algo' is for example "sha256WithRSAEncryption" (as per
> [http://oidref.com/1.2.840.113549.1.1.11])
> 2) for subFilter="adbe.x509.rsa_sha1" it is not detected, if the pdf content
> is altered.
>
> See also PDFBOX-4297
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5066) ShowSignature: say which digest algorithm was used, detect forged content
[
https://issues.apache.org/jira/browse/PDFBOX-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Hauser updated PDFBOX-5066:
Description:
1) SHA256 is was used by the signer to get the content digests of
target/pdfs/notCertified_368835_Sig_en_201026090509.pdf , this should be
mentioned like
System.out.println("Signature found");
so maybe
System.out.println("Signature algorithm: "+algo);
where 'algo' is for example "sha256WithRSAEncryption" (as per
[http://oidref.com/1.2.840.113549.1.1.11])
2) for subFilter="adbe.x509.rsa_sha1" it is not detected, if the pdf content
is altered.
was:
1) SHA256 is was used by the signer to get the content digests of
target/pdfs/notCertified_368835_Sig_en_201026090509.pdf , this should be
mentioned like
System.out.println("Signature found");
so maybe
System.out.println("Signature algorithm: "+algo);
where also is for example "sha256WithRSAEncryption" (as per
http://oidref.com/1.2.840.113549.1.1.11)
2) for subFilter="adbe.x509.rsa_sha1" it is not detected, if the pdf content is
altered.
> ShowSignature: say which digest algorithm was used, detect forged content
> -
>
> Key: PDFBOX-5066
> URL: https://issues.apache.org/jira/browse/PDFBOX-5066
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.23
>Reporter: Ralf Hauser
>Priority: Minor
>
> 1) SHA256 is was used by the signer to get the content digests of
> target/pdfs/notCertified_368835_Sig_en_201026090509.pdf , this should be
> mentioned like
> System.out.println("Signature found");
> so maybe
> System.out.println("Signature algorithm: "+algo);
> where 'algo' is for example "sha256WithRSAEncryption" (as per
> [http://oidref.com/1.2.840.113549.1.1.11])
> 2) for subFilter="adbe.x509.rsa_sha1" it is not detected, if the pdf content
> is altered.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5066) ShowSignature: say which digest algorithm was used, detect forged content
Ralf Hauser created PDFBOX-5066:
---
Summary: ShowSignature: say which digest algorithm was used,
detect forged content
Key: PDFBOX-5066
URL: https://issues.apache.org/jira/browse/PDFBOX-5066
Project: PDFBox
Issue Type: Improvement
Components: Signing
Affects Versions: 2.0.23
Reporter: Ralf Hauser
1) SHA256 is was used by the signer to get the content digests of
target/pdfs/notCertified_368835_Sig_en_201026090509.pdf , this should be
mentioned like
System.out.println("Signature found");
so maybe
System.out.println("Signature algorithm: "+algo);
where also is for example "sha256WithRSAEncryption" (as per
http://oidref.com/1.2.840.113549.1.1.11)
2) for subFilter="adbe.x509.rsa_sha1" it is not detected, if the pdf content is
altered.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[ https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257693#comment-17257693 ] Ralf Hauser commented on PDFBOX-4297: - Please find with programWinter2015_20210103_091853-sig_LTV.pdf a bigger test file. > We could change the code of ShowSignature, but then we'd probably get > criticism for being slow. if streams are properly implemented, they might even be quicker as there will not be any memory-pages swapping by the operating system > Allow to space efficiently analyse large PDFs > - > > Key: PDFBOX-4297 > URL: https://issues.apache.org/jira/browse/PDFBOX-4297 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Reporter: Ralf Hauser >Priority: Major > Attachments: programWinter2015_20210103_091853-sig_LTV.pdf > > > Assume you get a 300+MB large pdf and need to know > 1) the file names of embedded files if any > 2) whether it is encrypted (symmetric or asymmetric) > 3) certification level (and whether it is signed) > This should not use more than 5 MB (extra) memory > > P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle > large PDF files" > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[ https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-4297: Attachment: programWinter2015_20210103_091853-sig_LTV.pdf > Allow to space efficiently analyse large PDFs > - > > Key: PDFBOX-4297 > URL: https://issues.apache.org/jira/browse/PDFBOX-4297 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Reporter: Ralf Hauser >Priority: Major > Attachments: programWinter2015_20210103_091853-sig_LTV.pdf > > > Assume you get a 300+MB large pdf and need to know > 1) the file names of embedded files if any > 2) whether it is encrypted (symmetric or asymmetric) > 3) certification level (and whether it is signed) > This should not use more than 5 MB (extra) memory > > P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle > large PDF files" > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[
https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257682#comment-17257682
]
Ralf Hauser commented on PDFBOX-4297:
-
Re 3b) "whether it is signed" [correctly]
Looking at ShowSignature.java unfortunately, it is not yet memory-efficient.
For example in ShowSignature.checkContentValueWithFile(File file, int[]
byteRange, byte[] contents), the memory usage grows linearly with the file size
due to the contents byte-array.
But there is hope since
a) in showSignature() when
switch (subFilter)
is executed, the "adbe.*" convert the "byte[] contents" back into a stream.
(albeit I do not see that in this case, it is verified whether the document
is altered or not)
b) verifyPKCS7() probably could work with a stream instead of "byte[] contents"
because the
bouncycastle classes also have stream approaches.
(CMSSignedData has constructors with streams instead of byte[] )
So to begin,
i) PDSignature.getContents(InputStream pdfFile) should be amended with a sibling
public InputStream getSignedContentStream(InputStream pdfFile) throws
IOException
{
try (COSFilterInputStream fis = new COSFilterInputStream(pdfFile,
getByteRange()))
{
return fis;
}
}
ii) verifyETSIdotRFC3161() should be refactored to work with streams and not
the content byte[]
> Allow to space efficiently analyse large PDFs
> -
>
> Key: PDFBOX-4297
> URL: https://issues.apache.org/jira/browse/PDFBOX-4297
> Project: PDFBox
> Issue Type: Improvement
> Components: Parsing
>Reporter: Ralf Hauser
>Priority: Major
>
> Assume you get a 300+MB large pdf and need to know
> 1) the file names of embedded files if any
> 2) whether it is encrypted (symmetric or asymmetric)
> 3) certification level (and whether it is signed)
> This should not use more than 5 MB (extra) memory
>
> P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle
> large PDF files"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5003) Analyze signatures where DSS / LTV is inside the signature
[
https://issues.apache.org/jira/browse/PDFBOX-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221350#comment-17221350
]
Ralf Hauser commented on PDFBOX-5003:
-
Yes, for QV_RCA1_RCA3_CPCPS_V4_11.pdf
COSDictionary dssDict =
docCatalog.getCOSObject().getCOSDictionary(COSName.getPDFName("DSS"));
is null.
So it stores its little CRL with 18 revoked entries somewhere else
(ThisUpdate: 2012-12-31, nextUpdate:
2013-12-31, CRLNumber: 78 , crlIssr CN=QuoVadis Root Certification Author...)
> Analyze signatures where DSS / LTV is inside the signature
> --
>
> Key: PDFBOX-5003
> URL: https://issues.apache.org/jira/browse/PDFBOX-5003
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 3.0.0 PDFBox
>Reporter: Ralf Hauser
>Priority: Major
> Attachments: CH_ISBsigValidatRep_368811.pdf,
> image-2020-10-27-12-27-32-843.png
>
>
> This is an extension of PDFBOX-4297
> E.g. in CH_ISBsigValidatRep_368811.pdf they are not where 4297 exptects them .
>
> Possibly,
> [https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignature] gives
> further insights.
> (another test case is QV_RCA1_RCA3_CPCPS_V4_11.pdf from previous versions of
> TestCreateSignature.testAddValidationInformation() - PDFBOX-2776)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5003) Analyze signatures where DSS / LTV is inside the signature
[ https://issues.apache.org/jira/browse/PDFBOX-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221345#comment-17221345 ] Ralf Hauser commented on PDFBOX-5003: - [#comment-17221331] thanks for the hint - you may be right that I explicitely trusted it once in the past (albeit then, Acrobat is kind of misleading) > Analyze signatures where DSS / LTV is inside the signature > -- > > Key: PDFBOX-5003 > URL: https://issues.apache.org/jira/browse/PDFBOX-5003 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 3.0.0 PDFBox >Reporter: Ralf Hauser >Priority: Major > Attachments: CH_ISBsigValidatRep_368811.pdf, > image-2020-10-27-12-27-32-843.png > > > This is an extension of PDFBOX-4297 > E.g. in CH_ISBsigValidatRep_368811.pdf they are not where 4297 exptects them . > > Possibly, > [https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignature] gives > further insights. > (another test case is QV_RCA1_RCA3_CPCPS_V4_11.pdf from previous versions of > TestCreateSignature.testAddValidationInformation() - PDFBOX-2776) > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5003) Analyze signatures where DSS / LTV is inside the signature
[ https://issues.apache.org/jira/browse/PDFBOX-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-5003: Attachment: image-2020-10-27-12-27-32-843.png > Analyze signatures where DSS / LTV is inside the signature > -- > > Key: PDFBOX-5003 > URL: https://issues.apache.org/jira/browse/PDFBOX-5003 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 3.0.0 PDFBox >Reporter: Ralf Hauser >Priority: Major > Attachments: CH_ISBsigValidatRep_368811.pdf, > image-2020-10-27-12-27-32-843.png > > > This is an extension of PDFBOX-4297 > E.g. in CH_ISBsigValidatRep_368811.pdf they are not where 4297 exptects them . > > Possibly, > [https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignature] gives > further insights. > (another test case is QV_RCA1_RCA3_CPCPS_V4_11.pdf from previous versions of > TestCreateSignature.testAddValidationInformation() - PDFBOX-2776) > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5003) Analyze signatures where DSS / LTV is inside the signature
[ https://issues.apache.org/jira/browse/PDFBOX-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221327#comment-17221327 ] Ralf Hauser commented on PDFBOX-5003: - !image-2020-10-27-12-27-32-843.png! at least Acrobat does find LTV info > Analyze signatures where DSS / LTV is inside the signature > -- > > Key: PDFBOX-5003 > URL: https://issues.apache.org/jira/browse/PDFBOX-5003 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 3.0.0 PDFBox >Reporter: Ralf Hauser >Priority: Major > Attachments: CH_ISBsigValidatRep_368811.pdf, > image-2020-10-27-12-27-32-843.png > > > This is an extension of PDFBOX-4297 > E.g. in CH_ISBsigValidatRep_368811.pdf they are not where 4297 exptects them . > > Possibly, > [https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignature] gives > further insights. > (another test case is QV_RCA1_RCA3_CPCPS_V4_11.pdf from previous versions of > TestCreateSignature.testAddValidationInformation() - PDFBOX-2776) > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5003) Analyze signatures where DSS / LTV is inside the signature
Ralf Hauser created PDFBOX-5003: --- Summary: Analyze signatures where DSS / LTV is inside the signature Key: PDFBOX-5003 URL: https://issues.apache.org/jira/browse/PDFBOX-5003 Project: PDFBox Issue Type: Improvement Components: Signing Affects Versions: 3.0.0 PDFBox Reporter: Ralf Hauser Attachments: CH_ISBsigValidatRep_368811.pdf This is an extension of PDFBOX-4297 E.g. in CH_ISBsigValidatRep_368811.pdf they are not where 4297 exptects them . Possibly, [https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignature] gives further insights. (another test case is QV_RCA1_RCA3_CPCPS_V4_11.pdf from previous versions of TestCreateSignature.testAddValidationInformation() - PDFBOX-2776) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[ https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-2776: Attachment: shortLivedCrlAsLTV-sig.pdf > support "Long Term Validation" signature extensions (LTV) > - > > Key: PDFBOX-2776 > URL: https://issues.apache.org/jira/browse/PDFBOX-2776 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter: Ralf Hauser >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: certified_368835_Sig_de_201026171017_LTV.pdf, > nonSigPdf-sig1.pdf, notCertified_368835_Sig_en_201026090509.pdf, > notCertified_368835_Sig_en_201026090509_report.png, shortLivedCrlAsLTV-sig.pdf > > > in recent acrobat readers, every signature is commented w.r.t. "LTV" > ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification > referenced as part 4 in > http://en.wikipedia.org/wiki/PAdES > It would be great if pdf signatures created with PDFBox would assist in > creatign those. > Target test setup: > 1) input of an unsigned PDF-1.5 document > 2) signature with > a) local key pair > b) hsm > c) remote signature service (e.g. via soap) > 3) add ocsp response for LTV (crls typically are larger) > ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled" > see also PDFBOX-1848 > more in > http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[ https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221165#comment-17221165 ] Ralf Hauser commented on PDFBOX-2776: - [~mkl] <> Seems that provider shortLivedCrlAsLTV-sig.pdf solve it with a small, long-lasting CRL ... > support "Long Term Validation" signature extensions (LTV) > - > > Key: PDFBOX-2776 > URL: https://issues.apache.org/jira/browse/PDFBOX-2776 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter: Ralf Hauser >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: certified_368835_Sig_de_201026171017_LTV.pdf, > nonSigPdf-sig1.pdf, notCertified_368835_Sig_en_201026090509.pdf, > notCertified_368835_Sig_en_201026090509_report.png > > > in recent acrobat readers, every signature is commented w.r.t. "LTV" > ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification > referenced as part 4 in > http://en.wikipedia.org/wiki/PAdES > It would be great if pdf signatures created with PDFBox would assist in > creatign those. > Target test setup: > 1) input of an unsigned PDF-1.5 document > 2) signature with > a) local key pair > b) hsm > c) remote signature service (e.g. via soap) > 3) add ocsp response for LTV (crls typically are larger) > ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled" > see also PDFBOX-1848 > more in > http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[ https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-2776: Attachment: certified_368835_Sig_de_201026171017_LTV.pdf > support "Long Term Validation" signature extensions (LTV) > - > > Key: PDFBOX-2776 > URL: https://issues.apache.org/jira/browse/PDFBOX-2776 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter: Ralf Hauser >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: certified_368835_Sig_de_201026171017_LTV.pdf, > nonSigPdf-sig1.pdf, notCertified_368835_Sig_en_201026090509.pdf, > notCertified_368835_Sig_en_201026090509_report.png > > > in recent acrobat readers, every signature is commented w.r.t. "LTV" > ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification > referenced as part 4 in > http://en.wikipedia.org/wiki/PAdES > It would be great if pdf signatures created with PDFBox would assist in > creatign those. > Target test setup: > 1) input of an unsigned PDF-1.5 document > 2) signature with > a) local key pair > b) hsm > c) remote signature service (e.g. via soap) > 3) add ocsp response for LTV (crls typically are larger) > ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled" > see also PDFBOX-1848 > more in > http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[ https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220792#comment-17220792 ] Ralf Hauser commented on PDFBOX-2776: - Re [#comment-17220723] > What you can do, though, is adding validation related information together > with the signature (using Adobe's Revocation Information signed attribute or > maybe even a DSS in the signed document revision). And at least in the old iText2.1.7 this is not that hard - see certified_368835_Sig_de_201026171017_LTV.pdf > support "Long Term Validation" signature extensions (LTV) > - > > Key: PDFBOX-2776 > URL: https://issues.apache.org/jira/browse/PDFBOX-2776 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter: Ralf Hauser >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: nonSigPdf-sig1.pdf, > notCertified_368835_Sig_en_201026090509.pdf, > notCertified_368835_Sig_en_201026090509_report.png > > > in recent acrobat readers, every signature is commented w.r.t. "LTV" > ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification > referenced as part 4 in > http://en.wikipedia.org/wiki/PAdES > It would be great if pdf signatures created with PDFBox would assist in > creatign those. > Target test setup: > 1) input of an unsigned PDF-1.5 document > 2) signature with > a) local key pair > b) hsm > c) remote signature service (e.g. via soap) > 3) add ocsp response for LTV (crls typically are larger) > ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled" > see also PDFBOX-1848 > more in > http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[ https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220789#comment-17220789 ] Ralf Hauser edited comment on PDFBOX-4297 at 10/26/20, 4:09 PM: RE [#comment-17211657] What are the test methods for point 1) - 3) ? was (Author: hau...@acm.org): RE PDFBOX-4297#comment-17211657 What are the test methods for point 1) - 3) ? > Allow to space efficiently analyse large PDFs > - > > Key: PDFBOX-4297 > URL: https://issues.apache.org/jira/browse/PDFBOX-4297 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Reporter: Ralf Hauser >Priority: Major > > Assume you get a 300+MB large pdf and need to know > 1) the file names of embedded files if any > 2) whether it is encrypted (symmetric or asymmetric) > 3) certification level (and whether it is signed) > This should not use more than 5 MB (extra) memory > > P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle > large PDF files" > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[ https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220789#comment-17220789 ] Ralf Hauser edited comment on PDFBOX-4297 at 10/26/20, 4:08 PM: RE PDFBOX-4297#comment-17211657 What are the test methods for point 1) - 3) ? was (Author: hau...@acm.org): RE https://issues.apache.org/jira/browse/PDFBOX-4297?focusedCommentId=17211657=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17211657 What are the test methods for point 1) - 3) ? > Allow to space efficiently analyse large PDFs > - > > Key: PDFBOX-4297 > URL: https://issues.apache.org/jira/browse/PDFBOX-4297 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Reporter: Ralf Hauser >Priority: Major > > Assume you get a 300+MB large pdf and need to know > 1) the file names of embedded files if any > 2) whether it is encrypted (symmetric or asymmetric) > 3) certification level (and whether it is signed) > This should not use more than 5 MB (extra) memory > > P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle > large PDF files" > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[ https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220789#comment-17220789 ] Ralf Hauser commented on PDFBOX-4297: - RE comment-17211657 What are the test methods for point 1) - 3) ? > Allow to space efficiently analyse large PDFs > - > > Key: PDFBOX-4297 > URL: https://issues.apache.org/jira/browse/PDFBOX-4297 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Reporter: Ralf Hauser >Priority: Major > > Assume you get a 300+MB large pdf and need to know > 1) the file names of embedded files if any > 2) whether it is encrypted (symmetric or asymmetric) > 3) certification level (and whether it is signed) > This should not use more than 5 MB (extra) memory > > P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle > large PDF files" > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[ https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220789#comment-17220789 ] Ralf Hauser edited comment on PDFBOX-4297 at 10/26/20, 4:07 PM: RE https://issues.apache.org/jira/browse/PDFBOX-4297?focusedCommentId=17211657=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17211657 What are the test methods for point 1) - 3) ? was (Author: hau...@acm.org): RE comment-17211657 What are the test methods for point 1) - 3) ? > Allow to space efficiently analyse large PDFs > - > > Key: PDFBOX-4297 > URL: https://issues.apache.org/jira/browse/PDFBOX-4297 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Reporter: Ralf Hauser >Priority: Major > > Assume you get a 300+MB large pdf and need to know > 1) the file names of embedded files if any > 2) whether it is encrypted (symmetric or asymmetric) > 3) certification level (and whether it is signed) > This should not use more than 5 MB (extra) memory > > P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle > large PDF files" > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[ https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220572#comment-17220572 ] Ralf Hauser commented on PDFBOX-2776: - notCertified_368835_Sig_en_201026090509.pdf would a good imput for the TestCreateSignature().testAddValidationInformation() that at least in my current Acrobat Viewer turns all green The remaining problem is "have LTV" in a pdf whose signature is "certified" > support "Long Term Validation" signature extensions (LTV) > - > > Key: PDFBOX-2776 > URL: https://issues.apache.org/jira/browse/PDFBOX-2776 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter: Ralf Hauser >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: nonSigPdf-sig1.pdf, > notCertified_368835_Sig_en_201026090509.pdf > > > in recent acrobat readers, every signature is commented w.r.t. "LTV" > ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification > referenced as part 4 in > http://en.wikipedia.org/wiki/PAdES > It would be great if pdf signatures created with PDFBox would assist in > creatign those. > Target test setup: > 1) input of an unsigned PDF-1.5 document > 2) signature with > a) local key pair > b) hsm > c) remote signature service (e.g. via soap) > 3) add ocsp response for LTV (crls typically are larger) > ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled" > see also PDFBOX-1848 > more in > http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[ https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-2776: Attachment: notCertified_368835_Sig_en_201026090509.pdf > support "Long Term Validation" signature extensions (LTV) > - > > Key: PDFBOX-2776 > URL: https://issues.apache.org/jira/browse/PDFBOX-2776 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter: Ralf Hauser >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: nonSigPdf-sig1.pdf, > notCertified_368835_Sig_en_201026090509.pdf > > > in recent acrobat readers, every signature is commented w.r.t. "LTV" > ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification > referenced as part 4 in > http://en.wikipedia.org/wiki/PAdES > It would be great if pdf signatures created with PDFBox would assist in > creatign those. > Target test setup: > 1) input of an unsigned PDF-1.5 document > 2) signature with > a) local key pair > b) hsm > c) remote signature service (e.g. via soap) > 3) add ocsp response for LTV (crls typically are larger) > ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled" > see also PDFBOX-1848 > more in > http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[ https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217290#comment-17217290 ] Ralf Hauser commented on PDFBOX-2776: - The missing certs for nonSigPdf-sig1.pdf -BEGIN CERTIFICATE- MIIGSDCCBDCgAwIBAgIUJdImmyZN874twOb0zLbPOIfe2VkwDQYJKoZIhvcNAQEF BQAweTELMAkGA1UEBhMCQk0xGTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxJTAj BgNVBAsTHFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxKDAmBgNVBAMTH1F1 b1ZhZGlzIE5vIFJlbGlhbmNlIFJvb3QgQ0EgRzIwHhcNMTEwODEwMTMwNDM3WhcN MjEwODA1MTgwOTI4WjBOMQswCQYDVQQGEwJCTTEZMBcGA1UEChMQUXVvVmFkaXMg TGltaXRlZDEkMCIGA1UEAxMbUXVvVmFkaXMgTm8gUmVsaWFuY2UgSUNBIEcyMIIC IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuFsvyep6Wk4YOd1cDAiC8noN czq5knmSEjpdKSVr2HaezTxXLcGZOk2X6P23lyTxTjH4wlL21cRjyK1/GmnL2SI6 I8992bO/Xmf+G/Y6Fywvk29LsJipHdNxqzcEf+dR617OPVoP04rr4kAl/kX41/sa dXAHoGC+oKejTv5fPaDvYX19A/j0LRWBUnySP2AlSQXyy5iWJ5GBJurrSjSOBOHw TVBQTy2EkrS13vvGrnvvZY0xcrjbQvKgiLTpL52uxcsbzLFlrfMrSCs6G7/Fcl8G eHvA/gro6e2HKOB3chpANuKrk0bzKolVKYEQVVe3QwK39/ZeSA1m4/jdwEByqDaJ QI0vfrcY61B1wKNLkVfjEC4Mj+hDp3EOkP42OrTCqEytnV7X1keFd9l5QGgvVQru ox9mG3k6F3YJNAUpAqjQyLcYkymRWEFSK7qrExt7F4PQjVWEdHTWLfVP00zMITmh aOf05HN5n8aVcV+AfXLk83LI6CN2tNVSlaxDPcVczdnbp0x2tZ5YNIElfWAc2HFH uOyAsvcZMsxUoRZdjgf23eOwwLP9v8bXRI37wbOUTuub73IHpJPzWDIcc8LwqYpe Jg+lMUeWODkm/xqV+5Q0E6e7hYTVboqhBC3KgTmIZtNshU1g1vypg8IGwRKYwkVy B2dyZddlKjKdLolHI0ECAwEAAaOB8jCB7zAPBgNVHRMBAf8EBTADAQH/MBEGA1Ud IAQKMAgwBgYEVR0gADA8BggrBgEFBQcBAQQwMC4wLAYIKwYBBQUHMAGGIGh0dHA6 Ly9vY3NwZHIucXVvdmFkaXNnbG9iYWwuY29tMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBSv0O8d+An5NBEf1FdW+eA7pmHENzA7BgNVHR8ENDAyMDCgLqAshipo dHRwOi8vY3JsLnF1b3ZhZGlzZ2xvYmFsLmNvbS9xdm5yY2FnMi5jcmwwHQYDVR0O BBYEFPV4QT2oQhcfIr69ThBHw2izixg1MA0GCSqGSIb3DQEBBQUAA4ICAQAXbWNe RapvWyAlYeBQzNXKoGB70dN2dgVhLmnfgRAYC6WmIy8UKWt1OoeqX1ztftAq2oVg 3ObZ3Ud+U4pzE2C7YB7rkETrHMks0Z0TfKlFLtU0I1bih494o93txU/MnK8PFPqE TinCS2qiupG4hFyOVEgdbPcNRmBZtlxqkmys6rqrF+Kf6NV4vjBYY0YNNQBcyRu/ nJD/C8QALt2OfmnYFTomO5lTPFsvrysj+XEAus97sVqDG9zreDZT5w0SdLyyrm1K hHWFCQWm3O2o0igme4hlY9OvoQOfXJ8WQLZO/H54XdqFRL9liP3/vuIrERp9Rlme O9/JeAYpzpJ/vUQRWq7tt2YgGG15sMmD8m8AurDayD1xu391chjEUFhU67dqVgXw ni6KFHLC05DFzzS/igmsiwhxkmtXqdLrPBc9tKP15MQaY9MK7mnCliZYrlY0Ynnu OjvBfRu+fZZgW9KhUDU8Fz211UKZvdtutVdEFUgrSPSP+01BaeMjgoqoFEthC5AC nqwI1ugTFULUUbzQgWEgTyNqXiUYtr60/IYk5DoZHiJfbrjVt4uG6va+BDI+e9u8 6x8gMlGeJERQoE/wxpoSJkWM5KWE23wXUitEHAO2IgiKPcyiBa50TEe/eK3WDo9u rvT89ovptps1Z4D6Zl7WFnIJuI3k8mCXWnkl9Q== -END CERTIFICATE- -BEGIN CERTIFICATE- MIIF4zCCA8ugAwIBAgIUb+hkbaVtQEL4Cn75Hf92Ml0TY7EwDQYJKoZIhvcNAQEF BQAweTELMAkGA1UEBhMCQk0xGTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxJTAj BgNVBAsTHFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxKDAmBgNVBAMTH1F1 b1ZhZGlzIE5vIFJlbGlhbmNlIFJvb3QgQ0EgRzIwHhcNMTEwODA1MTgwOTI4WhcN MjEwODA1MTgwOTI4WjB5MQswCQYDVQQGEwJCTTEZMBcGA1UEChMQUXVvVmFkaXMg TGltaXRlZDElMCMGA1UECxMcUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEo MCYGA1UEAxMfUXVvVmFkaXMgTm8gUmVsaWFuY2UgUm9vdCBDQSBHMjCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAJdyE2e1rsufqr2+llJFg0Oo9EnTvTw/ Scne0ZbBIOeBUIspNnGTQ/nTKL7/BaM52CM73bbiDoEOG2utz9pLfAJOSYYzXRQr ecWdUA7/0ru+FRfGzXIQj07G5m/FYRWQOs2NO0mm65iUpxedn3QuX7MqvaLnZemY SQXGiNjkqOqFCGFw2FtSFH9LV/B45MO2GW/MaydlUGqMFJzX97QqEFzqO80gwNBe /0p1O6U5OvqY6BSFTIAXApYJYSl4etLSzmbH0JQgA4DglWtV4KPYNhn40ouPNhQa sVGYPquwwqdiDFjE9fzKQQdo+aid6WBnsELiXSbHr1t4WcFgwOZN5CEs68j8L3e4 OuDozrr4nmwLkuXuUkUbez0Z7w12ISPbnKd+GlXkVP9SCwqOtqF/lQTaEuk2NWuv vrb0AziFhopHXRlNnBARuhWREy3+kpRgp7uV5prUjHmvRijtJKwCthmg0slC7g+E 3paqIcFApvkYEYzK0RD4pa/HdiOe+x8qQyWq8fI0+RUshsm9zYgsBQexVcQJ62NI ztEFKhm0KxHTGph7Cy+pewfaNFsjRN1fudSwmPSNQbPfNsv3hVYl0mnDwYSfWJsd l90XBbTUDudi13m6OiOa3CyqEJSNYTswH1F2sTPQunMa1yojw2RcKgrN8zS9MDw4 7y/OXbhQiHOTAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQD AgEGMB8GA1UdIwQYMBaAFK/Q7x34Cfk0ER/UV1b54DumYcQ3MB0GA1UdDgQWBBSv 0O8d+An5NBEf1FdW+eA7pmHENzANBgkqhkiG9w0BAQUFAAOCAgEAXpTQpmOYqgWx jbSnwOdTd3MMcfzvZBH4zmNRY9t4gORfy7Fz9EvIjqHRe+mLM4pmdG1mwcURkat/ knpUp+ONt6u9iifGvQ8027MMCSQ0KHmS6PfFWAW8EDxZPInTxhWYCBnnJdIG7wdb X9AQpF7RRTy1vXTzMSXfo/+E+1zOLKcfUK1vMR5eB87rrkXe0bEJZQud36W379hy 71j5TWlLgaSNootVsggapnj8M5WV5QW3iyF9V9/Qg2Fr0JZ1dUMJu8WDiOTKb3i5 st5EcRLUmSVwcG9eHJhM69jTNxVgA1HtgMdYyGHPuaLwNBnBpJ1n1TXyzZ7lxavj OwjRrFKmiqs7tbw07nuVJRI/hioMI5Vsqca8NLu8SC6p2klvQEr8dn/gWvt7gTAo 0E4I/El/F9SMKkWQlG6pjgDZPh63ZyHuQhGA1D2+tZYHtkFn+3CpQGoPCONZyf5J SsTEzANelS3kAS4oApRBU38YFj0xzjQdmzWuh0dIdZubRuC/0rHQDbHtsiuQRk8V HJICVj3EjWAbZkW3eMV8kDaLn3x8rPe92KgmI9XT9/C2ZZfnWX/fUah8nAwD5WdW bI9Lie7+KxsVovqg3Zpmiu16OVGJp6yWSX3vsuBO+06R+i73ZxFpooNSF9dkiJPn 8GSeh2lu6LhTwLl5yHBJ7Vcxu9cALW8= -END CERTIFICATE- > support "Long Term Validation" signature extensions (LTV) > - > > Key: PDFBOX-2776 > URL: https://issues.apache.org/jira/browse/PDFBOX-2776 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter:
[jira] [Commented] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[ https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216834#comment-17216834 ] Ralf Hauser commented on PDFBOX-2776: - Please add a test case that does all the steps 1-3 and 4) takes the signing time e.g. from [http://tsa.pki.admin.ch/tsa] (rfc3161) It seems that the current TestCreateSignature().testAddValidationInformation() only works with already signed pdfs see also PDFBOX-4994 > support "Long Term Validation" signature extensions (LTV) > - > > Key: PDFBOX-2776 > URL: https://issues.apache.org/jira/browse/PDFBOX-2776 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter: Ralf Hauser >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: nonSigPdf-sig1.pdf > > > in recent acrobat readers, every signature is commented w.r.t. "LTV" > ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification > referenced as part 4 in > http://en.wikipedia.org/wiki/PAdES > It would be great if pdf signatures created with PDFBox would assist in > creatign those. > Target test setup: > 1) input of an unsigned PDF-1.5 document > 2) signature with > a) local key pair > b) hsm > c) remote signature service (e.g. via soap) > 3) add ocsp response for LTV (crls typically are larger) > ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled" > see also PDFBOX-1848 > more in > http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[ https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-2776: Attachment: nonSigPdf-sig1.pdf > support "Long Term Validation" signature extensions (LTV) > - > > Key: PDFBOX-2776 > URL: https://issues.apache.org/jira/browse/PDFBOX-2776 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter: Ralf Hauser >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: nonSigPdf-sig1.pdf > > > in recent acrobat readers, every signature is commented w.r.t. "LTV" > ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification > referenced as part 4 in > http://en.wikipedia.org/wiki/PAdES > It would be great if pdf signatures created with PDFBox would assist in > creatign those. > Target test setup: > 1) input of an unsigned PDF-1.5 document > 2) signature with > a) local key pair > b) hsm > c) remote signature service (e.g. via soap) > 3) add ocsp response for LTV (crls typically are larger) > ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled" > see also PDFBOX-1848 > more in > http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)
[
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216743#comment-17216743
]
Ralf Hauser commented on PDFBOX-2776:
-
Testing with:
System.setProperty("org.apache.pdfbox.examples.pdmodel.tsa","http://tsa.pki.admin.ch/tsa;);
TestCreateSignature.init();
new TestCreateSignature().testAddValidationInformation();
Still looking for a good test file. The attached is a proposal, for the
sig-cert used therein, there is both a current OCSP and CRL available
OCSP (-Wed Oct 21 15:55:00 CEST 2020):
The certificate was not revoked. According to the OCSP
Response from: http://ocspdr.quovadisglobal.com , created 20201019_1555
CertID
ser#: 2e4540e4f6993bbe4f737f3d6841df0485582bf, validity of OCSP-Response
till:20201021_1555
CRL (-Thu Oct 22 14:33:53 CEST 2020):
Found a valid CRL in the local cache. Issued on Oct 19, 2020,
next update on Oct 22, 2020.
size 467KB
> support "Long Term Validation" signature extensions (LTV)
> -
>
> Key: PDFBOX-2776
> URL: https://issues.apache.org/jira/browse/PDFBOX-2776
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.0
>Reporter: Ralf Hauser
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: nonSigPdf-sig1.pdf
>
>
> in recent acrobat readers, every signature is commented w.r.t. "LTV"
> ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification
> referenced as part 4 in
> http://en.wikipedia.org/wiki/PAdES
> It would be great if pdf signatures created with PDFBox would assist in
> creatign those.
> Target test setup:
> 1) input of an unsigned PDF-1.5 document
> 2) signature with
> a) local key pair
> b) hsm
> c) remote signature service (e.g. via soap)
> 3) add ocsp response for LTV (crls typically are larger)
> ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled"
> see also PDFBOX-1848
> more in
> http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4994) please track whether revocation information is present/added
Ralf Hauser created PDFBOX-4994: --- Summary: please track whether revocation information is present/added Key: PDFBOX-4994 URL: https://issues.apache.org/jira/browse/PDFBOX-4994 Project: PDFBox Issue Type: Improvement Reporter: Ralf Hauser Attachments: patch2776.txt, patch2776test.txt see also PDFBOX-2776 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4993) if infile is missing, say which one
Ralf Hauser created PDFBOX-4993:
---
Summary: if infile is missing, say which one
Key: PDFBOX-4993
URL: https://issues.apache.org/jira/browse/PDFBOX-4993
Project: PDFBox
Issue Type: Improvement
Affects Versions: 3.0.0 PDFBox
Reporter: Ralf Hauser
### Eclipse Workspace Patch 1.0
#P pdfbox
Index:
examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
===
---
examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
(revision 1882597)
+++
examples/src/main/java/org/apache/pdfbox/examples/signature/validation/AddValidationInformation.java
(working copy)
@@ -98,7 +98,13 @@
{
if (inFile == null || !inFile.exists())
{
-throw new FileNotFoundException("Document for signing does not
exist");
+String err = "Document for signing ";
+if (null == inFile) {
+ err += "is null";
+} else {
+ err += "does not exist "+inFile.getAbsolutePath();
+}
+ throw new FileNotFoundException(err);
}
try (PDDocument doc = Loader.loadPDF(inFile);
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4990) say which resource not found when a font is missing
[
https://issues.apache.org/jira/browse/PDFBOX-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215893#comment-17215893
]
Ralf Hauser commented on PDFBOX-4990:
-
same please with /org/apache/pdfbox/resources/ttf/LiberationSans-Regular.ttf in
FontMapperImpl.java
> say which resource not found when a font is missing
> ---
>
> Key: PDFBOX-4990
> URL: https://issues.apache.org/jira/browse/PDFBOX-4990
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 3.0.0 PDFBox
>Reporter: Ralf Hauser
>Priority: Minor
>
> ### Eclipse Workspace Patch 1.0
> #P pdfbox
> Index:
> pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java
> ===
> --- pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java
> (revision 1882597)
> +++ pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java
> (working copy)
> @@ -117,10 +117,13 @@
> try (InputStream resourceAsStream =
> PDType1Font.class.getResourceAsStream(resourceName);
> InputStream afmStream = new BufferedInputStream(resourceAsStream))
> {
> + if (null == resourceAsStream) {
> + throw new IOException("resource '"+resourceName+"' not found");
> + }
> AFMParser parser = new AFMParser(afmStream);
> FontMetrics metric = parser.parse(true);
> FONTS.put(fontName, metric);
> - }
> + }
> }
>
> /**
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4991) say when GlyphList is not found what was sought for
Ralf Hauser created PDFBOX-4991:
---
Summary: say when GlyphList is not found what was sought for
Key: PDFBOX-4991
URL: https://issues.apache.org/jira/browse/PDFBOX-4991
Project: PDFBox
Issue Type: Improvement
Reporter: Ralf Hauser
### Eclipse Workspace Patch 1.0
#P pdfbox
Index:
pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/GlyphList.java
===
--- pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/GlyphList.java
(revision 1882597)
+++ pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/GlyphList.java
(working copy)
@@ -49,8 +49,12 @@
{
String path = "/org/apache/pdfbox/resources/glyphlist/";
//no need to use a BufferedInputSteam here, as GlyphList uses a
BufferedReader
-try (InputStream resourceAsStream =
GlyphList.class.getResourceAsStream(path + filename))
+String fullFileName = path + filename;
+try (InputStream resourceAsStream =
GlyphList.class.getResourceAsStream(fullFileName))
{
+ if (null == resourceAsStream) {
+ throw new RuntimeException("GlyphList
'"+fullFileName+"' not found");
+ }
return new GlyphList(resourceAsStream, numberOfEntries);
}
catch (IOException e)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4990) say which resource not found when a font is missing
Ralf Hauser created PDFBOX-4990:
---
Summary: say which resource not found when a font is missing
Key: PDFBOX-4990
URL: https://issues.apache.org/jira/browse/PDFBOX-4990
Project: PDFBox
Issue Type: Improvement
Affects Versions: 3.0.0 PDFBox
Reporter: Ralf Hauser
### Eclipse Workspace Patch 1.0
#P pdfbox
Index: pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java
===
--- pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java
(revision 1882597)
+++ pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java
(working copy)
@@ -117,10 +117,13 @@
try (InputStream resourceAsStream =
PDType1Font.class.getResourceAsStream(resourceName);
InputStream afmStream = new BufferedInputStream(resourceAsStream))
{
+ if (null == resourceAsStream) {
+ throw new IOException("resource '"+resourceName+"' not found");
+ }
AFMParser parser = new AFMParser(afmStream);
FontMetrics metric = parser.parse(true);
FONTS.put(fontName, metric);
- }
+ }
}
/**
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-236) PDF parse signature version
[ https://issues.apache.org/jira/browse/PDFBOX-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212305#comment-17212305 ] Ralf Hauser commented on PDFBOX-236: see also PDFBOX-4297 > PDF parse signature version > --- > > Key: PDFBOX-236 > URL: https://issues.apache.org/jira/browse/PDFBOX-236 > Project: PDFBox > Issue Type: Bug > Components: Signing >Assignee: Thomas Chojecki >Priority: Minor > Fix For: 1.6.0 > > > [imported from SourceForge] > http://sourceforge.net/tracker/index.php?group_id=78314=552833=1636977 > Originally submitted by dlapdfuser on 2007-01-16 09:49. > When parsing a pdf that has been signed multiple times, the field values > parsed are the ones from the first signing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[ https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207887#comment-17207887 ] Ralf Hauser commented on PDFBOX-4297: - 4) it would be great to obtain the PKCS7 signature-block (e.g. as byte-array) as return object > Allow to space efficiently analyse large PDFs > - > > Key: PDFBOX-4297 > URL: https://issues.apache.org/jira/browse/PDFBOX-4297 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Reporter: Ralf Hauser >Priority: Major > > Assume you get a 300+MB large pdf and need to know > 1) the file names of embedded files if any > 2) whether it is encrypted (symmetric or asymmetric) > 3) certification level (and whether it is signed) > This should not use more than 5 MB (extra) memory > > P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle > large PDF files" > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[ https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164485#comment-17164485 ] Ralf Hauser commented on PDFBOX-4297: - see also the inverse [https://github.com/bcgit/bc-java/issues/326] > Allow to space efficiently analyse large PDFs > - > > Key: PDFBOX-4297 > URL: https://issues.apache.org/jira/browse/PDFBOX-4297 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Reporter: Ralf Hauser >Priority: Major > > Assume you get a 300+MB large pdf and need to know > 1) the file names of embedded files if any > 2) whether it is encrypted (symmetric or asymmetric) > 3) certification level (and whether it is signed) > This should not use more than 5 MB (extra) memory > > P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle > large PDF files" > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
Ralf Hauser created PDFBOX-4297: --- Summary: Allow to space efficiently analyse large PDFs Key: PDFBOX-4297 URL: https://issues.apache.org/jira/browse/PDFBOX-4297 Project: PDFBox Issue Type: Improvement Reporter: Ralf Hauser Assume you get a 300+MB large pdf and need to know 1) the file names of embedded files if any 2) whether it is encrypted (symmetric or asymmetric) 3) certification level (and whether it is signed) This should not use more than 5 MB (extra) memory P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle large PDF files" -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4020) Into signature embedded Signed Timestamp for validation
[
https://issues.apache.org/jira/browse/PDFBOX-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261267#comment-16261267
]
Ralf Hauser commented on PDFBOX-4020:
-
The use case is that you want to sign offline to avoid zero-day attacks against
your signing machine.
Once the signature is there und the pdf is transferred to a network connect
machine, one is likely to want to add a timestamp.
> Into signature embedded Signed Timestamp for validation
> ---
>
> Key: PDFBOX-4020
> URL: https://issues.apache.org/jira/browse/PDFBOX-4020
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.8
>Reporter: Alexis Suter
> Attachments: SignatureValidation_Embedded_Timestamping.java.patch
>
>
> I would like to contribute a new example for embedded Timestamping.
> The Timestamp is beeing embedded into the existing Signature (which has so be
> prepared big enough for it). So that the document does not get changed.
> This Step is a preparation for the LTV and includes some reorganisation for
> Validation-Purposes.
> I am still working on embedding the OCSP-Data, wich will take a bit longer.
> For that I have excluded and commented out the Code for it, to avoid
> confusion.
> Possible Usage:
> {code:java}
> exec:java -X
> -Dexec.mainClass="org.apache.pdfbox.examples.signature.validation.CreateEmbeddedValidation"
> -Dexec.args="${infile} -tsa ${tsa}"
> {code}
> CreateSignature has been changed to add SignatureOptions, where we can choose
> the size of the signature.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4020) Into signature embedded Signed Timestamp for validation
[
https://issues.apache.org/jira/browse/PDFBOX-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16260633#comment-16260633
]
Ralf Hauser commented on PDFBOX-4020:
-
see also PDFBOX-1848
> Into signature embedded Signed Timestamp for validation
> ---
>
> Key: PDFBOX-4020
> URL: https://issues.apache.org/jira/browse/PDFBOX-4020
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
>Affects Versions: 2.0.8
>Reporter: Alexis Suter
> Attachments: SignatureValidation_Embedded_Timestamping.java.patch
>
>
> I would like to contribute a new example for embedded Timestamping.
> The Timestamp is beeing embedded into the existing Signature (which has so be
> prepared big enough for it). So that the document does not get changed.
> This Step is a preparation for the LTV and includes some reorganisation for
> Validation-Purposes.
> I am still working on embedding the OCSP-Data, wich will take a bit longer.
> For that I have excluded and commented out the Code for it, to avoid
> confusion.
> Possible Usage:
> {code:java}
> exec:java -X
> -Dexec.mainClass="org.apache.pdfbox.examples.signature.validation.CreateEmbeddedValidation"
> -Dexec.args="${infile} -tsa ${tsa}"
> {code}
> CreateSignature has been changed to add SignatureOptions, where we can choose
> the size of the signature.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-1848) Time Stamp Document Level Sigature
[ https://issues.apache.org/jira/browse/PDFBOX-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16260632#comment-16260632 ] Ralf Hauser commented on PDFBOX-1848: - see also PDFBOX-4020 > Time Stamp Document Level Sigature > -- > > Key: PDFBOX-1848 > URL: https://issues.apache.org/jira/browse/PDFBOX-1848 > Project: PDFBox > Issue Type: Improvement > Components: Signing >Affects Versions: 2.0.0 >Reporter: vakhtang koroghlishvili >Assignee: Tilman Hausherr > Fix For: 2.0.9, 3.0.0 PDFBox > > Attachments: CreateSignedTimestamp.java.patch, > CreateTSASignature.java.patch, TSA-SIG-LOOKS-LIKE-THIS.png, file.pdf, > file_signed.pdf, file_signed_timestamped.pdf, file_timestamped.pdf > > > We need TSA Document Level signature modulo too! > At the moment we sign document with our certificate. But... sometimes we need > to sign document with TSA too. This is important part of signing. Sometimes > this is very very very important- for instance when we will implement PAdES 4 > profile this module will be essential. without that Document Secure Store > will not work :) > I'm working on this improvement. I'will finish this soon. It's almost done. I > only must add some java docs, and might be I change architect design and etc.. > So, please assign this it to me :) I will upload patch as soon as possible :) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15737862#comment-15737862 ] Ralf Hauser edited comment on PDFBOX-3618 at 12/10/16 1:24 PM: --- If you "have enough fonts on your own PC anyway" - you won't care about font embedding PDF/A in the first place. Recent experience in a government context unfortunately shows that your 2nd statement is frighteningly wrong... was (Author: hau...@acm.org): If you "have enough fonts on your own PC anyway" - you won't care about PDF/A in the first place. Recent experience in a government context unfortunately shows that your 2nd statement is frighteningly wrong... > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Improvement >Affects Versions: 2.0.3 >Reporter: Ralf Hauser >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 2.0.4, 2.1.0 > > Attachments: CreatePDFA3618.patch > > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15737862#comment-15737862 ] Ralf Hauser commented on PDFBOX-3618: - If you "have enough fonts on your own PC anyway" - you won't care about PDF/A in the first place. Recent experience in a government context unfortunately shows that your 2nd statement is frighteningly wrong... > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Improvement >Affects Versions: 2.0.3 >Reporter: Ralf Hauser >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 2.0.4, 2.1.0 > > Attachments: CreatePDFA3618.patch > > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15737758#comment-15737758 ] Ralf Hauser commented on PDFBOX-3618: - Fine, but then please provide a link that describes how to get a good free font with a couple of reliable sources. There are so many shady sites out there that pretend that you can just download frutiger and alike for free. :( > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Improvement >Affects Versions: 2.0.3 >Reporter: Ralf Hauser >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 2.0.4, 2.1.0 > > Attachments: CreatePDFA3618.patch > > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-3624) add a constructor with byte[] to MemoryTTFDataStream
Ralf Hauser created PDFBOX-3624: --- Summary: add a constructor with byte[] to MemoryTTFDataStream Key: PDFBOX-3624 URL: https://issues.apache.org/jira/browse/PDFBOX-3624 Project: PDFBox Issue Type: Improvement Affects Versions: 2.0.3 Environment: java8 deb stable Reporter: Ralf Hauser the current approach duplicates byte[] that may already be statically in memory. ==> additonal method TTFParser.parse(byte[] input) should be added -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-3618: Attachment: CreatePDFA3618.patch One further comment line to make it even more actionable for the beginners > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Improvement >Affects Versions: 2.0.3 >Reporter: Ralf Hauser >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 2.0.4, 2.1.0 > > Attachments: CreatePDFA3618.patch > > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15737412#comment-15737412 ] Ralf Hauser commented on PDFBOX-3618: - Great work thanks! > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Improvement >Affects Versions: 2.0.3 >Reporter: Ralf Hauser >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 2.0.4, 2.1.0 > > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15729285#comment-15729285 ] Ralf Hauser edited comment on PDFBOX-3618 at 12/7/16 5:10 PM: -- An exploring programmer will have serveral examples open and as s/he will most likely not have a ttf-fontfile at hand, s/he'll see in another example that PDType1Font standard fonts might the job and not realizing that this breaks the pdf/a quality 65 // load the font as this needs to be embedded 66 PDFont font = PDType0Font.load(doc, new File(fontfile)); was (Author: hau...@acm.org): A exploring programmer will have serveral examples open and as s/he will most likely not have a ttf-fontfile at hand, s/he'll see in another example that PDType1Font standard fonts might the job and not realizing that this breaks the pdf/a quality 65 // load the font as this needs to be embedded 66 PDFont font = PDType0Font.load(doc, new File(fontfile)); > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Improvement >Affects Versions: 2.0.3 >Reporter: Ralf Hauser >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 2.0.4, 2.1.0 > > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15729285#comment-15729285 ] Ralf Hauser commented on PDFBOX-3618: - A exploring programmer will have serveral examples open and as s/he will most likely not have a ttf-fontfile at hand, s/he'll see in another example that PDType1Font standard fonts might the job and not realizing that this breaks the pdf/a quality 65 // load the font as this needs to be embedded 66 PDFont font = PDType0Font.load(doc, new File(fontfile)); > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Improvement >Affects Versions: 2.0.3 >Reporter: Ralf Hauser >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 2.0.4, 2.1.0 > > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15729221#comment-15729221 ] Ralf Hauser commented on PDFBOX-3618: - to make things clearer, maybe org.apache.pdfbox.examples.pdmodel.CreatePDFA.java should a) have a comment that using a standard font will destroy the compliance with Pdf/A b) include a not-so-obscure concrete free font in the example such that beginners can immediately start ? > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Ralf Hauser > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15727928#comment-15727928 ] Ralf Hauser commented on PDFBOX-3618: - This looks like a misunderstanding. The reader of a pdf/a won't take a font from her os but from the document, the *creator* however most likely will take the font from the OS. (I guess, most pdfs are created for someone else not just for self-use). So, what does the pdf/a standard say? > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Ralf Hauser > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15726136#comment-15726136 ] Ralf Hauser commented on PDFBOX-3618: - http://www.nuance.com/resellers/pdf/pdf-palooza-assets/PDF-A_PDF8.pdf says that standard fonts also need to be included. Does the standard say something different? > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Ralf Hauser > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15725236#comment-15725236 ] Ralf Hauser commented on PDFBOX-3618: - http://www.1001fonts.com/nimbus-sans-l-font.html#license > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Ralf Hauser > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
[ https://issues.apache.org/jira/browse/PDFBOX-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Hauser updated PDFBOX-3618: Description: PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, Courier, Symbol and ZapfDingbats. When creating a pdf/A, the font is embedded and not taken from the reader's operating system. As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead to a licensing issue. Suggestions: 1) Use a free font such as https://de.wikipedia.org/wiki/Nimbus_Sans_L instead 2) at least warn in JavaDoc about the issue Or is it an non-issue? was: PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, Courier, Symbol an dZapfDingbats. When creating a pdf/A, the font is embedded and not taken from the reader's operating system. As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead to a licensing issue. Suggestions: 1) Use a free font such as https://de.wikipedia.org/wiki/Nimbus_Sans_L instead 2) at least warn in JavaDoc about the issue Or is it an non-issue? > Helvetica in PDF/A - warn in PDType1Font.java about licensing issues > > > Key: PDFBOX-3618 > URL: https://issues.apache.org/jira/browse/PDFBOX-3618 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Ralf Hauser > > PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, > Courier, Symbol and ZapfDingbats. > When creating a pdf/A, the font is embedded and not taken from the reader's > operating system. > As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead > to a licensing issue. > Suggestions: > 1) Use a free font such as > https://de.wikipedia.org/wiki/Nimbus_Sans_L instead > 2) at least warn in JavaDoc about the issue > Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-3618) Helvetica in PDF/A - warn in PDType1Font.java about licensing issues
Ralf Hauser created PDFBOX-3618: --- Summary: Helvetica in PDF/A - warn in PDType1Font.java about licensing issues Key: PDFBOX-3618 URL: https://issues.apache.org/jira/browse/PDFBOX-3618 Project: PDFBox Issue Type: Bug Affects Versions: 2.0.3 Reporter: Ralf Hauser PDType1Font.java has a predefined list of fonts like Times-Roman, Helvetica, Courier, Symbol an dZapfDingbats. When creating a pdf/A, the font is embedded and not taken from the reader's operating system. As per https://de.wikipedia.org/wiki/Helvetica_(Schriftart) , this may lead to a licensing issue. Suggestions: 1) Use a free font such as https://de.wikipedia.org/wiki/Nimbus_Sans_L instead 2) at least warn in JavaDoc about the issue Or is it an non-issue? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
