[jira] [Updated] (PDFBOX-4985) Render orphan annotation widgets

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun updated PDFBOX-4985:
---
Fix Version/s: 3.0.0 PDFBox
   2.0.22

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-new.pdf, 
> POPPLER-806-p2.jpg, POPPLER-806-page2.jpg, POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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-4985) Render orphan annotation widgets

[Maruan Sahyoun (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221161#comment-17221161
 ] 

Maruan Sahyoun commented on PDFBOX-4985:


[~tilman] lt me know if the last commit addresses the drawback. I'll also move 
forward and port that to 2.0

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-new.pdf, 
> POPPLER-806-p2.jpg, POPPLER-806-page2.jpg, POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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] [Reopened] (PDFBOX-1288) Lines will not be printed (correctly) in case they are part of a clipping mask

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun reopened PDFBOX-1288:


Thanks [~tilman] - didn't check with that file but only with the original one. 
Will drop it from 3.0.0 as I don't think this is actively being worked on.

> Lines will not be printed (correctly) in case they are part of a clipping mask
> --
>
> Key: PDFBOX-1288
> URL: https://issues.apache.org/jira/browse/PDFBOX-1288
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 1.6.0
> Environment: Mac OS X 10.7.2, Java 1.6.0_31, FOP 1.0
>Reporter: Christoph Langheld
>Assignee: John Hewson
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: 20140226_after_printing_with_pdf_box.pdf, 
> 20140226_after_printing_with_pdf_box.pdf-1.png, 
> 20140226_after_printing_with_pdf_box.pdf-2.png, 
> 20140226_original-pdfbox-trunk.pdf, 20140226_original.pdf, 
> 20140226_original.pdf-1.png, 20140226_original.pdf-2.png, 
> PDFBOX-1288.pdf-1-after.png, PDFBOX-1288.pdf-1-before.png, 
> PDFBOX-677.pdf-1-after.png, PDFBOX-677.pdf-1-before.png, 
> after_printing_with_pdfbox.pdf, better-clipping-2.patch, 
> better-clipping-3.patch, better-clipping-4.patch, better-clipping.patch, 
> bitcoin.pdf, original-pdfbox-trunk.pdf, original.pdf, pdfbox-1288.pdf-1.png, 
> screenshot_borders_with_wrong_size.png, test2.pdf
>
>
> In case of a PDF file that was created with FOP 1.0 and was printed with 
> PDFBox, lines disappeared or lines appeared smaller. PDF files that were 
> created with Adobe InDesign (e.g.) will be printed correctly.
> It has something to do with lines which are part of a clipping mask. FOP 
> seems to generate a clipping mask around all kind of borders. Lines of type 
>  appear correctly and are not part of an clipping mask.
> When printing a FOP-PDF with PDFBox, PDFBox moves the clipping mask, so the 
> line is not visible anymore. Please see attached Screenshot.
> The PDF file I created with FOP is named: original.pdf
> The resulting PDF file after printing with PDFBox is named: 
> after_printing_with_pdfbox.pdf
> Regards
> Christoph



--
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] [Assigned] (PDFBOX-1288) Lines will not be printed (correctly) in case they are part of a clipping mask

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun reassigned PDFBOX-1288:
--

Assignee: (was: John Hewson)

> Lines will not be printed (correctly) in case they are part of a clipping mask
> --
>
> Key: PDFBOX-1288
> URL: https://issues.apache.org/jira/browse/PDFBOX-1288
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 1.6.0
> Environment: Mac OS X 10.7.2, Java 1.6.0_31, FOP 1.0
>Reporter: Christoph Langheld
>Priority: Major
> Attachments: 20140226_after_printing_with_pdf_box.pdf, 
> 20140226_after_printing_with_pdf_box.pdf-1.png, 
> 20140226_after_printing_with_pdf_box.pdf-2.png, 
> 20140226_original-pdfbox-trunk.pdf, 20140226_original.pdf, 
> 20140226_original.pdf-1.png, 20140226_original.pdf-2.png, 
> PDFBOX-1288.pdf-1-after.png, PDFBOX-1288.pdf-1-before.png, 
> PDFBOX-677.pdf-1-after.png, PDFBOX-677.pdf-1-before.png, 
> after_printing_with_pdfbox.pdf, better-clipping-2.patch, 
> better-clipping-3.patch, better-clipping-4.patch, better-clipping.patch, 
> bitcoin.pdf, original-pdfbox-trunk.pdf, original.pdf, pdfbox-1288.pdf-1.png, 
> screenshot_borders_with_wrong_size.png, test2.pdf
>
>
> In case of a PDF file that was created with FOP 1.0 and was printed with 
> PDFBox, lines disappeared or lines appeared smaller. PDF files that were 
> created with Adobe InDesign (e.g.) will be printed correctly.
> It has something to do with lines which are part of a clipping mask. FOP 
> seems to generate a clipping mask around all kind of borders. Lines of type 
>  appear correctly and are not part of an clipping mask.
> When printing a FOP-PDF with PDFBox, PDFBox moves the clipping mask, so the 
> line is not visible anymore. Please see attached Screenshot.
> The PDF file I created with FOP is named: original.pdf
> The resulting PDF file after printing with PDFBox is named: 
> after_printing_with_pdfbox.pdf
> Regards
> Christoph



--
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-1288) Lines will not be printed (correctly) in case they are part of a clipping mask

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun updated PDFBOX-1288:
---
Fix Version/s: (was: 3.0.0 PDFBox)

> Lines will not be printed (correctly) in case they are part of a clipping mask
> --
>
> Key: PDFBOX-1288
> URL: https://issues.apache.org/jira/browse/PDFBOX-1288
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 1.6.0
> Environment: Mac OS X 10.7.2, Java 1.6.0_31, FOP 1.0
>Reporter: Christoph Langheld
>Assignee: John Hewson
>Priority: Major
> Attachments: 20140226_after_printing_with_pdf_box.pdf, 
> 20140226_after_printing_with_pdf_box.pdf-1.png, 
> 20140226_after_printing_with_pdf_box.pdf-2.png, 
> 20140226_original-pdfbox-trunk.pdf, 20140226_original.pdf, 
> 20140226_original.pdf-1.png, 20140226_original.pdf-2.png, 
> PDFBOX-1288.pdf-1-after.png, PDFBOX-1288.pdf-1-before.png, 
> PDFBOX-677.pdf-1-after.png, PDFBOX-677.pdf-1-before.png, 
> after_printing_with_pdfbox.pdf, better-clipping-2.patch, 
> better-clipping-3.patch, better-clipping-4.patch, better-clipping.patch, 
> bitcoin.pdf, original-pdfbox-trunk.pdf, original.pdf, pdfbox-1288.pdf-1.png, 
> screenshot_borders_with_wrong_size.png, test2.pdf
>
>
> In case of a PDF file that was created with FOP 1.0 and was printed with 
> PDFBox, lines disappeared or lines appeared smaller. PDF files that were 
> created with Adobe InDesign (e.g.) will be printed correctly.
> It has something to do with lines which are part of a clipping mask. FOP 
> seems to generate a clipping mask around all kind of borders. Lines of type 
>  appear correctly and are not part of an clipping mask.
> When printing a FOP-PDF with PDFBox, PDFBox moves the clipping mask, so the 
> line is not visible anymore. Please see attached Screenshot.
> The PDF file I created with FOP is named: original.pdf
> The resulting PDF file after printing with PDFBox is named: 
> after_printing_with_pdfbox.pdf
> Regards
> Christoph



--
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-1288) Lines will not be printed (correctly) in case they are part of a clipping mask

[Tilman Hausherr (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221133#comment-17221133
 ] 

Tilman Hausherr commented on PDFBOX-1288:
-

The effect can be seen when rendering pages 2 or 3 with of the bitcoin file 
with PDFDebugger at different resolutions.

> Lines will not be printed (correctly) in case they are part of a clipping mask
> --
>
> Key: PDFBOX-1288
> URL: https://issues.apache.org/jira/browse/PDFBOX-1288
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 1.6.0
> Environment: Mac OS X 10.7.2, Java 1.6.0_31, FOP 1.0
>Reporter: Christoph Langheld
>Assignee: John Hewson
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: 20140226_after_printing_with_pdf_box.pdf, 
> 20140226_after_printing_with_pdf_box.pdf-1.png, 
> 20140226_after_printing_with_pdf_box.pdf-2.png, 
> 20140226_original-pdfbox-trunk.pdf, 20140226_original.pdf, 
> 20140226_original.pdf-1.png, 20140226_original.pdf-2.png, 
> PDFBOX-1288.pdf-1-after.png, PDFBOX-1288.pdf-1-before.png, 
> PDFBOX-677.pdf-1-after.png, PDFBOX-677.pdf-1-before.png, 
> after_printing_with_pdfbox.pdf, better-clipping-2.patch, 
> better-clipping-3.patch, better-clipping-4.patch, better-clipping.patch, 
> bitcoin.pdf, original-pdfbox-trunk.pdf, original.pdf, pdfbox-1288.pdf-1.png, 
> screenshot_borders_with_wrong_size.png, test2.pdf
>
>
> In case of a PDF file that was created with FOP 1.0 and was printed with 
> PDFBox, lines disappeared or lines appeared smaller. PDF files that were 
> created with Adobe InDesign (e.g.) will be printed correctly.
> It has something to do with lines which are part of a clipping mask. FOP 
> seems to generate a clipping mask around all kind of borders. Lines of type 
>  appear correctly and are not part of an clipping mask.
> When printing a FOP-PDF with PDFBox, PDFBox moves the clipping mask, so the 
> line is not visible anymore. Please see attached Screenshot.
> The PDF file I created with FOP is named: original.pdf
> The resulting PDF file after printing with PDFBox is named: 
> after_printing_with_pdfbox.pdf
> Regards
> Christoph



--
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-4985) Render orphan annotation widgets

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221006#comment-17221006
 ] 

ASF subversion and git services commented on PDFBOX-4985:
-

Commit 1882893 from Maruan Sahyoun in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882893 ]

PDFBOX-4985: enhance Javadoc

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-new.pdf, 
> POPPLER-806-p2.jpg, POPPLER-806-page2.jpg, POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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-4985) Render orphan annotation widgets

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221002#comment-17221002
 ] 

ASF subversion and git services commented on PDFBOX-4985:
-

Commit 1882892 from Maruan Sahyoun in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882892 ]

PDFBOX-4985: reset the cached AcroForm when first called with getAcroForm(true)

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-new.pdf, 
> POPPLER-806-p2.jpg, POPPLER-806-page2.jpg, POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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

Jenkins build is back to stable : PDFBox » PDFBox-trunk #193

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-trunk » Apache PDFBox examples #193

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-2.0.x » Apache PDFBox examples #117

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-2.0.x #117

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4985) Render orphan annotation widgets

[Maruan Sahyoun (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220998#comment-17220998
 ] 

Maruan Sahyoun commented on PDFBOX-4985:


What I would go for is to reset the cache with the first call to 
{{getAcroForm(true)}} and issue a warning if it's called with 
{{getAcroForm(false)}} afterwards.

We should mark the method as internal - WDYT?

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-new.pdf, 
> POPPLER-806-p2.jpg, POPPLER-806-page2.jpg, POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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] [Assigned] (PDFBOX-2626) Regenerate field appearances if NeedAppearances is set prior to rendering

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun reassigned PDFBOX-2626:
--

Assignee: Maruan Sahyoun

> Regenerate field appearances if NeedAppearances is set prior to rendering
> -
>
> Key: PDFBOX-2626
> URL: https://issues.apache.org/jira/browse/PDFBOX-2626
> Project: PDFBox
>  Issue Type: New Feature
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Simon Steiner
>Assignee: Maruan Sahyoun
>Priority: Major
>  Labels: Appearance
> Fix For: 3.0.0 PDFBox
>
> Attachments: out.pdf
>
>
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> out.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-3017) Improve document signing

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220964#comment-17220964
 ] 

ASF subversion and git services commented on PDFBOX-3017:
-

Commit 1882889 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1882889 ]

PDFBOX-3017: use log instead of exception because test signature points to 
outdated CRL

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-3017) Improve document signing

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220965#comment-17220965
 ] 

ASF subversion and git services commented on PDFBOX-3017:
-

Commit 1882890 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882890 ]

PDFBOX-3017: use log instead of exception because test signature points to 
outdated CRL

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-4985) Render orphan annotation widgets

[Tilman Hausherr (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220962#comment-17220962
 ] 

Tilman Hausherr commented on PDFBOX-4985:
-

Yeah let's not bother. This is a broken PDF.

However the current implementation has one drawback, once the acroform is 
retrieved one doesn't have a chance to retrieve it again with the changes, 
because of the cache.

I mention this because I'd like to see the effect while keeping PDFDebugger 
open.

Maybe reset the cache when the option is true, or when it is different than 
last time? Or offer a method to apply the fixes?

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-new.pdf, 
> POPPLER-806-p2.jpg, POPPLER-806-page2.jpg, POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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] [Resolved] (PDFBOX-1532) extra space added to rotated text

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun resolved PDFBOX-1532.

Resolution: Fixed

Using the -sort option the text is correctly extracted
{code}
Rotated text is broken into several peices
{code}

Result of extraction attached in  [^rotated-sorted.txt]. Also works in PDFBox 
2.0.22 see  [^rotated-sorted-2.0.22.txt] . Older versions not tested.

> extra space added to rotated text 
> --
>
> Key: PDFBOX-1532
> URL: https://issues.apache.org/jira/browse/PDFBOX-1532
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.7.1, 2.0.0
>Reporter: Jinder Aujla
>Priority: Major
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: 0049-My-squashed-commits.patch, 
> rotated-sorted-2.0.22.txt, rotated-sorted.txt, rotated.pdf
>
>
> Extra line break added after first character is read in a document that has 
> rotated text.



--
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-1532) extra space added to rotated text

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun updated PDFBOX-1532:
---
Attachment: rotated-sorted-2.0.22.txt

> extra space added to rotated text 
> --
>
> Key: PDFBOX-1532
> URL: https://issues.apache.org/jira/browse/PDFBOX-1532
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.7.1, 2.0.0
>Reporter: Jinder Aujla
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: 0049-My-squashed-commits.patch, 
> rotated-sorted-2.0.22.txt, rotated-sorted.txt, rotated.pdf
>
>
> Extra line break added after first character is read in a document that has 
> rotated text.



--
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-1532) extra space added to rotated text

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun updated PDFBOX-1532:
---
Fix Version/s: 2.0.22

> extra space added to rotated text 
> --
>
> Key: PDFBOX-1532
> URL: https://issues.apache.org/jira/browse/PDFBOX-1532
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.7.1, 2.0.0
>Reporter: Jinder Aujla
>Priority: Major
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: 0049-My-squashed-commits.patch, 
> rotated-sorted-2.0.22.txt, rotated-sorted.txt, rotated.pdf
>
>
> Extra line break added after first character is read in a document that has 
> rotated text.



--
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-1532) extra space added to rotated text

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun updated PDFBOX-1532:
---
Attachment: rotated-sorted.txt

> extra space added to rotated text 
> --
>
> Key: PDFBOX-1532
> URL: https://issues.apache.org/jira/browse/PDFBOX-1532
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.7.1, 2.0.0
>Reporter: Jinder Aujla
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: 0049-My-squashed-commits.patch, rotated-sorted.txt, 
> rotated.pdf
>
>
> Extra line break added after first character is read in a document that has 
> rotated text.



--
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] [Resolved] (PDFBOX-1288) Lines will not be printed (correctly) in case they are part of a clipping mask

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun resolved PDFBOX-1288.

Resolution: Fixed

Printing to a PDF from current trunk no longer shows the differences shown in 
the PDFs at time of actively discussing the issue. Might be solved a long time 
ago as there were many changes to rendering since.
The currently created PDFs are: 

- [^20140226_original-pdfbox-trunk.pdf] 
- [^original-pdfbox-trunk.pdf]

Reopen if needed

> Lines will not be printed (correctly) in case they are part of a clipping mask
> --
>
> Key: PDFBOX-1288
> URL: https://issues.apache.org/jira/browse/PDFBOX-1288
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 1.6.0
> Environment: Mac OS X 10.7.2, Java 1.6.0_31, FOP 1.0
>Reporter: Christoph Langheld
>Assignee: John Hewson
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: 20140226_after_printing_with_pdf_box.pdf, 
> 20140226_after_printing_with_pdf_box.pdf-1.png, 
> 20140226_after_printing_with_pdf_box.pdf-2.png, 
> 20140226_original-pdfbox-trunk.pdf, 20140226_original.pdf, 
> 20140226_original.pdf-1.png, 20140226_original.pdf-2.png, 
> PDFBOX-1288.pdf-1-after.png, PDFBOX-1288.pdf-1-before.png, 
> PDFBOX-677.pdf-1-after.png, PDFBOX-677.pdf-1-before.png, 
> after_printing_with_pdfbox.pdf, better-clipping-2.patch, 
> better-clipping-3.patch, better-clipping-4.patch, better-clipping.patch, 
> bitcoin.pdf, original-pdfbox-trunk.pdf, original.pdf, pdfbox-1288.pdf-1.png, 
> screenshot_borders_with_wrong_size.png, test2.pdf
>
>
> In case of a PDF file that was created with FOP 1.0 and was printed with 
> PDFBox, lines disappeared or lines appeared smaller. PDF files that were 
> created with Adobe InDesign (e.g.) will be printed correctly.
> It has something to do with lines which are part of a clipping mask. FOP 
> seems to generate a clipping mask around all kind of borders. Lines of type 
>  appear correctly and are not part of an clipping mask.
> When printing a FOP-PDF with PDFBox, PDFBox moves the clipping mask, so the 
> line is not visible anymore. Please see attached Screenshot.
> The PDF file I created with FOP is named: original.pdf
> The resulting PDF file after printing with PDFBox is named: 
> after_printing_with_pdfbox.pdf
> Regards
> Christoph



--
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-1288) Lines will not be printed (correctly) in case they are part of a clipping mask

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun updated PDFBOX-1288:
---
Attachment: original-pdfbox-trunk.pdf
20140226_original-pdfbox-trunk.pdf

> Lines will not be printed (correctly) in case they are part of a clipping mask
> --
>
> Key: PDFBOX-1288
> URL: https://issues.apache.org/jira/browse/PDFBOX-1288
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 1.6.0
> Environment: Mac OS X 10.7.2, Java 1.6.0_31, FOP 1.0
>Reporter: Christoph Langheld
>Assignee: John Hewson
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: 20140226_after_printing_with_pdf_box.pdf, 
> 20140226_after_printing_with_pdf_box.pdf-1.png, 
> 20140226_after_printing_with_pdf_box.pdf-2.png, 
> 20140226_original-pdfbox-trunk.pdf, 20140226_original.pdf, 
> 20140226_original.pdf-1.png, 20140226_original.pdf-2.png, 
> PDFBOX-1288.pdf-1-after.png, PDFBOX-1288.pdf-1-before.png, 
> PDFBOX-677.pdf-1-after.png, PDFBOX-677.pdf-1-before.png, 
> after_printing_with_pdfbox.pdf, better-clipping-2.patch, 
> better-clipping-3.patch, better-clipping-4.patch, better-clipping.patch, 
> bitcoin.pdf, original-pdfbox-trunk.pdf, original.pdf, pdfbox-1288.pdf-1.png, 
> screenshot_borders_with_wrong_size.png, test2.pdf
>
>
> In case of a PDF file that was created with FOP 1.0 and was printed with 
> PDFBox, lines disappeared or lines appeared smaller. PDF files that were 
> created with Adobe InDesign (e.g.) will be printed correctly.
> It has something to do with lines which are part of a clipping mask. FOP 
> seems to generate a clipping mask around all kind of borders. Lines of type 
>  appear correctly and are not part of an clipping mask.
> When printing a FOP-PDF with PDFBox, PDFBox moves the clipping mask, so the 
> line is not visible anymore. Please see attached Screenshot.
> The PDF file I created with FOP is named: original.pdf
> The resulting PDF file after printing with PDFBox is named: 
> after_printing_with_pdfbox.pdf
> Regards
> Christoph



--
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

Jenkins build is still unstable: PDFBox » PDFBox-2.0.x #116

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox » PDFBox-2.0.x » Apache PDFBox examples #116

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox » PDFBox-trunk » Apache PDFBox examples #192

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox » PDFBox-trunk #192

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3017) Improve document signing

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220937#comment-17220937
 ] 

ASF subversion and git services commented on PDFBOX-3017:
-

Commit 1882887 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1882887 ]

PDFBOX-3017: improve parameter handling of previous commit so that -tsa is 
possible without image

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-3017) Improve document signing

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220938#comment-17220938
 ] 

ASF subversion and git services commented on PDFBOX-3017:
-

Commit 1882888 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882888 ]

PDFBOX-3017: improve parameter handling of previous commit so that -tsa is 
possible without image

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-3017) Improve document signing

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220928#comment-17220928
 ] 

ASF subversion and git services commented on PDFBOX-3017:
-

Commit 1882885 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1882885 ]

PDFBOX-3017: make image optional, see wish / comment by IsmailSahin in SO 
44311502

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-3017) Improve document signing

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220929#comment-17220929
 ] 

ASF subversion and git services commented on PDFBOX-3017:
-

Commit 1882886 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882886 ]

PDFBOX-3017: make image optional, see wish / comment by IsmailSahin in SO 
44311502

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-4984) Widget Quadding ignored

[Maruan Sahyoun (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220927#comment-17220927
 ] 

Maruan Sahyoun commented on PDFBOX-4984:


thank you [~goncalo-ans] for the finding and providing a patch which was very 
useful. This also helped us fixing another pending issue.

> Widget Quadding ignored
> ---
>
> Key: PDFBOX-4984
> URL: https://issues.apache.org/jira/browse/PDFBOX-4984
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Gonçalo Santos
>Assignee: Maruan Sahyoun
>Priority: Major
>  Labels: Appearance, easyfix, pull-request-available
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: Examplecertificate-blanco.pdf, 
> PDFBOX-4984-flattened-after.pdf, PDFBOX-4984-flattened-before.pdf, 
> image-2020-10-08-15-49-22-577.png
>
>
> When setting value of a text field, that has two widgets (duplicated/copied 
> field), the quadding (*Q*) value from the widget is ignored and always uses 
> field instead.
>  * In attachment you have an example of the pdf structured causing the issue.
>  * Already created a pull request with the fix: 
> [https://github.com/apache/pdfbox/pull/87].
>  



--
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] [Resolved] (PDFBOX-4984) Widget Quadding ignored

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun resolved PDFBOX-4984.

Resolution: Fixed

setting to resolved as there were no further comments and the proposed fix has 
been applied

> Widget Quadding ignored
> ---
>
> Key: PDFBOX-4984
> URL: https://issues.apache.org/jira/browse/PDFBOX-4984
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Gonçalo Santos
>Assignee: Maruan Sahyoun
>Priority: Major
>  Labels: Appearance, easyfix, pull-request-available
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: Examplecertificate-blanco.pdf, 
> PDFBOX-4984-flattened-after.pdf, PDFBOX-4984-flattened-before.pdf, 
> image-2020-10-08-15-49-22-577.png
>
>
> When setting value of a text field, that has two widgets (duplicated/copied 
> field), the quadding (*Q*) value from the widget is ignored and always uses 
> field instead.
>  * In attachment you have an example of the pdf structured causing the issue.
>  * Already created a pull request with the fix: 
> [https://github.com/apache/pdfbox/pull/87].
>  



--
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] [Resolved] (PDFBOX-4761) Alignment Issue in textfield

[Maruan Sahyoun (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maruan Sahyoun resolved PDFBOX-4761.

Resolution: Fixed

setting to resolved with the fix being done as part of PDFBOX-4984

> Alignment Issue in textfield
> 
>
> Key: PDFBOX-4761
> URL: https://issues.apache.org/jira/browse/PDFBOX-4761
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 2.0.18, 3.0.0 PDFBox
>Reporter: Baskar Murrugan
>Assignee: Maruan Sahyoun
>Priority: Major
>  Labels: Appearance
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: PDFBOX-4761-flattened-after.pdf, 
> PDFBOX-4761-flattened-before.pdf, formFieldProp.png, new.pdf
>
>
> In [^new.pdf], if you just type a value in the 'Player 1' field, the value 
> aligned left correctly. If we use to fill the value with PDFBOX jar. It 
> aligned the value in the center. But I checked the Q value it showing as 1 in 
> pdfbox. Since we're not specifying any alignment information but it took like 
> Q=1 in pdfbox.
> It create some comptability issue while using over other pdf readers.
> Issue fixed with setQ(0), but other readers were working fine without any 
> alignment information.
> I'm checked [^formFieldProp.png] info using [https://www.pdfescape.com  
> |https://www.pdfescape.com/]It showing alignment value as left.
> https://mail-archives.apache.org/mod_mbox/pdfbox-users/202002.mbox/browser



--
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-4984) Widget Quadding ignored

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220924#comment-17220924
 ] 

ASF subversion and git services commented on PDFBOX-4984:
-

Commit 1882883 from Maruan Sahyoun in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882883 ]

PDFBOX-4984: add some information about the handling into the source; closes #87

> Widget Quadding ignored
> ---
>
> Key: PDFBOX-4984
> URL: https://issues.apache.org/jira/browse/PDFBOX-4984
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Gonçalo Santos
>Assignee: Maruan Sahyoun
>Priority: Major
>  Labels: Appearance, easyfix, pull-request-available
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: Examplecertificate-blanco.pdf, 
> PDFBOX-4984-flattened-after.pdf, PDFBOX-4984-flattened-before.pdf, 
> image-2020-10-08-15-49-22-577.png
>
>
> When setting value of a text field, that has two widgets (duplicated/copied 
> field), the quadding (*Q*) value from the widget is ignored and always uses 
> field instead.
>  * In attachment you have an example of the pdf structured causing the issue.
>  * Already created a pull request with the fix: 
> [https://github.com/apache/pdfbox/pull/87].
>  



--
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

[GitHub] [pdfbox] asfgit closed pull request #87: PDFBOX-4984 Widget quadding ignored

[GitBox]

asfgit closed pull request #87:
URL: https://github.com/apache/pdfbox/pull/87


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
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

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220923#comment-17220923
 ] 

Michael Klink commented on PDFBOX-4297:
---

You cannot guarantee that you need less than 5 MB.

For example, one can simply blow up the *Catalog* object alone to more than 5 
MB by adding a lot of simple entries whose sizes add up to more than 5 MB.

This example is not a common case, but if you have to handle arbitrary inputs 
from the wild, you have to keep this possibility in mind as base of a possible 
DOS attack.

> 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-4984) Widget Quadding ignored

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220922#comment-17220922
 ] 

ASF subversion and git services commented on PDFBOX-4984:
-

Commit 1882882 from Maruan Sahyoun in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1882882 ]

PDFBOX-4984: add some information about the handling into the source

> Widget Quadding ignored
> ---
>
> Key: PDFBOX-4984
> URL: https://issues.apache.org/jira/browse/PDFBOX-4984
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Gonçalo Santos
>Assignee: Maruan Sahyoun
>Priority: Major
>  Labels: Appearance, easyfix, pull-request-available
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: Examplecertificate-blanco.pdf, 
> PDFBOX-4984-flattened-after.pdf, PDFBOX-4984-flattened-before.pdf, 
> image-2020-10-08-15-49-22-577.png
>
>
> When setting value of a text field, that has two widgets (duplicated/copied 
> field), the quadding (*Q*) value from the widget is ignored and always uses 
> field instead.
>  * In attachment you have an example of the pdf structured causing the issue.
>  * Already created a pull request with the fix: 
> [https://github.com/apache/pdfbox/pull/87].
>  



--
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

[Tilman Hausherr (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220916#comment-17220916
 ] 

Tilman Hausherr commented on PDFBOX-4297:
-

1) no test method. The EmbeddedFiles.java example shows how to add. This can be 
used to see what files there are.
2) there are test methods in the main project TestSymmetricKeyEncryption.java 
and TestPublicKeyEncryption.java
3) no test method but ShowSignature.java has most of this

> 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)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220912#comment-17220912
 ] 

ASF subversion and git services commented on PDFBOX-2776:
-

Commit 1882881 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1882881 ]

PDFBOX-2776: replace QV_RCA1_RCA3_CPCPS_V4_11.pdf (that had LTV information in 
signature) with file from Ralf Hauser

> 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)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220911#comment-17220911
 ] 

ASF subversion and git services commented on PDFBOX-2776:
-

Commit 1882880 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882880 ]

PDFBOX-2776: replace QV_RCA1_RCA3_CPCPS_V4_11.pdf (that had LTV information in 
signature) with file from Ralf Hauser

> 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)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220908#comment-17220908
 ] 

ASF subversion and git services commented on PDFBOX-2776:
-

Commit 1882878 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1882878 ]

PDFBOX-2776: replace QV_RCA1_RCA3_CPCPS_V4_11.pdf (that had LTV information in 
signature) with file from Ralf Hauser

> 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)

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220909#comment-17220909
 ] 

ASF subversion and git services commented on PDFBOX-2776:
-

Commit 1882879 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882879 ]

PDFBOX-2776: replace QV_RCA1_RCA3_CPCPS_V4_11.pdf (that had LTV information in 
signature) with file from Ralf Hauser

> 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-3017) Improve document signing

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220905#comment-17220905
 ] 

Michael Klink commented on PDFBOX-3017:
---

{quote}[~lrosenthol]>I am investigating the history of this change in 32K-2 as 
well as the Acrobat implementation.  I will report back here as soon as I know 
more about either...{quote}

That's great!

But it's not merely a question of 32K-2 support, PAdES since TS 102778-4 
required that addition of DSS or DTS must always be possible, whatever the 
DocMDP level may be. Thus, already support for PAdES (at least in documents 
marked by an appropriate ESIC or ADBE extension entry) requires support for 
this.

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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

Jenkins build became unstable: PDFBox » PDFBox-2.0.x #115

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-2.0.x » Apache PDFBox examples #115

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-trunk #191

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-trunk » Apache PDFBox examples #191

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220875#comment-17220875
 ] 

Michael Klink edited comment on PDFBOX-2776 at 10/26/20, 5:56 PM:
--

{quote}And at least in the old iText2.1.7 this is not that hard{quote}
This is both right and wrong.

Yes, iText (v2.1.7, v5.x, v7.x) supports adding revocation information to the 
Adobe's Revocation Information signed attribute. That is no magic, though, you 
can easily do something similar in PDFBox using BouncyCastle classes.

But no, this is impossible in a number of use cases, in particular there are 
many signing services nowadays which just-in-time, while processing a signature 
request, create a short-term certificate only for this signature. As you cannot 
know the signer certificate before signing, you cannot retrieve revocation 
information for it in time to consider them when building the signed attributes.

Also PDFBox surely shall cover not only the proprietary Adobe profile "LTV 
enabled" but in particular also the standard PAdES profiles. And non-legacy 
PAdES signatures (in particular the nowadays commonly required PAdES Baseline 
signatures) *require* that revocation information is added in a revision after 
the signed revision, so incremental updates are needed.


was (Author: mkl):
{quote}And at least in the old iText2.1.7 this is not that hard{quote}
This is both right and wrong.

Yes, iText (v2.1.7, v5.x, v7.x) supports adding revocation information to the 
Adobe's Revocation Information signed attribute. That is no magic, though, you 
can easily do something similar in PDFBox using BouncyCastle classes.

But no, this is impossible is a number of use cases, in particular there are 
many signing services nowadays which just-in-time, while processing a signature 
request, create a short-term certificate only for this signature. As you don't 
know the signer certificate before signing, you cannot retrieve revocation 
information for it in time to consider them when building the signed attributes.

Also PDFBox surely shall cover not only the proprietary Adobe profile "LTV 
enabled" but in particular also the PAdES profiles. And non-legacy PAdES 
signatures (in particular the nowadays commonly required PAdES Baseline 
signatures) *require* that revocation information is added in a revision after 
the signed revision, so incremental updates are needed.

> 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] [Comment Edited] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220875#comment-17220875
 ] 

Michael Klink edited comment on PDFBOX-2776 at 10/26/20, 5:54 PM:
--

{quote}And at least in the old iText2.1.7 this is not that hard{quote}
This is both right and wrong.

Yes, iText (v2.1.7, v5.x, v7.x) supports adding revocation information to the 
Adobe's Revocation Information signed attribute. That is no magic, though, you 
can easily do something similar in PDFBox using BouncyCastle classes.

But no, this is impossible is a number of use cases, in particular there are 
many signing services nowadays which just-in-time, while processing a signature 
request, create a short-term certificate only for this signature. As you don't 
know the signer certificate before signing, you cannot retrieve revocation 
information for it in time to consider them when building the signed attributes.

Also PDFBox surely shall cover not only the proprietary Adobe profile "LTV 
enabled" but in particular also the PAdES profiles. And non-legacy PAdES 
signatures (in particular the nowadays commonly required PAdES Baseline 
signatures) *require* that revocation information is added in a revision after 
the signed revision, so incremental updates are needed.


was (Author: mkl):
{quote}And at least in the old iText2.1.7 this is not that hard{quote}
This is both right and wrong.
Yes, iText (v2.1.7, v5.x, v7.x) supports adding revocation information to the 
Adobe's Revocation Information signed attribute. That is no magic, though, you 
can easily do something similar in PDFBox using BouncyCastle classes.

But no, this is impossible is a number of use cases, in particular there are 
many signing services nowadays which just-in-time, while processing a signature 
request, create a short-term certificate only for this signature. As you don't 
know the signer certificate before signing, you cannot retrieve revocation 
information for it in time to consider them when building the signed attributes.

Also PDFBox surely shall cover not only the proprietary Adobe profile "LTV 
enabled" but in particular also the PAdES profiles. And non-legacy PAdES 
signatures (in particular the nowadays commonly required PAdES Baseline 
signatures) *require* that revocation information is added in a revision after 
the signed revision, so incremental updates are needed.

> 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)

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220875#comment-17220875
 ] 

Michael Klink commented on PDFBOX-2776:
---

{quote}And at least in the old iText2.1.7 this is not that hard{quote}
This is both right and wrong.
Yes, iText (v2.1.7, v5.x, v7.x) supports adding revocation information to the 
Adobe's Revocation Information signed attribute. That is no magic, though, you 
can easily do something similar in PDFBox using BouncyCastle classes.

But no, this is impossible is a number of use cases, in particular there are 
many signing services nowadays which just-in-time, while processing a signature 
request, create a short-term certificate only for this signature. As you don't 
know the signer certificate before signing, you cannot retrieve revocation 
information for it in time to consider them when building the signed attributes.

Also PDFBox surely shall cover not only the proprietary Adobe profile "LTV 
enabled" but in particular also the PAdES profiles. And non-legacy PAdES 
signatures (in particular the nowadays commonly required PAdES Baseline 
signatures) *require* that revocation information is added in a revision after 
the signed revision, so incremental updates are needed.

> 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-3017) Improve document signing

[Leonard Rosenthol (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220874#comment-17220874
 ] 

Leonard Rosenthol commented on PDFBOX-3017:
---

I am investigating the history of this change in 32K-2 as well as the Acrobat 
implementation.  I will report back here as soon as I know more about either...

 

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-3017) Improve document signing

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220851#comment-17220851
 ] 

ASF subversion and git services commented on PDFBOX-3017:
-

Commit 1882877 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882877 ]

PDFBOX-3017: make sure that CRL is valid right now

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-3017) Improve document signing

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220850#comment-17220850
 ] 

ASF subversion and git services commented on PDFBOX-3017:
-

Commit 1882876 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1882876 ]

PDFBOX-3017: make sure that CRL is valid right now

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-4997) Incremental update adds certain objects not marked as needing update

[Marco Monacelli (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220796#comment-17220796
 ] 

Marco Monacelli commented on PDFBOX-4997:
-

Thanks, let's try to do the test in the week.

> Incremental update adds certain objects not marked as needing update
> 
>
> Key: PDFBOX-4997
> URL: https://issues.apache.org/jira/browse/PDFBOX-4997
> Project: PDFBox
>  Issue Type: Bug
>  Components: Writing
>Affects Versions: 2.0.21, 3.0.0 PDFBox
>Reporter: Michael Klink
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: signed-000.pdf
>
>
> _This bug causes the eSignature DSS issue 
> [DSS-2260|https://ec.europa.eu/cefdigital/tracker/browse/DSS-2260]._
> If during an incremental update an indirect object containing only a name 
> object is checked for need of writing, it always is added to the objects to 
> write and, therefore, eventually written to the update section.
> For example in the attached document {{signed-000.pdf}} each page has a color 
> space resource entry *CS1* referring to the indirect object 54 containing 
> only the name object, *DeviceGray*. Whenever a page is marked as needing an 
> update, the bug causes object 54 also to be written even if it is not changed 
> at all.
> While this seems like a minor annoyance only, it has serious repercussions: 
> In multi-signature use cases this makes Adobe Reader claim previous 
> signatures to be broken whenever a new signature with visualization is added 
> using PDFBox, see also 
> [DSS-2260|https://ec.europa.eu/cefdigital/tracker/browse/DSS-2260].
> 
> The cause of the bug is 
> {{org.apache.pdfbox.pdfwriter.COSWriter.addObjectToWrite(COSBase)}} where the 
> following {{if}} clause attempts to determine whether the inspected object 
> does not need to be written:
> {code:java}
> if (actual != null && objectKeys.containsKey(actual) 
> && object instanceof COSUpdateInfo && 
> !((COSUpdateInfo)object).isNeedToBeUpdated() 
> && cosBase instanceof COSUpdateInfo && 
> !((COSUpdateInfo)cosBase).isNeedToBeUpdated() )
> {
> return;
> }
> {code}
> Here {{cosBase}} contains the content of the indirect object, in the case in 
> question the {{COSName}} *DeviceGray*. As {{COSName}} does not implement 
> {{COSUpdateInfo}}, the condition never evaluates to {{true}}, so the flow 
> never returns here but instead always continues with the following lines 
> where the object is added to the collection of objects to write.



--
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)

[Ralf Hauser (Jira)]

 [ 
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)

[Ralf Hauser (Jira)]

[ 
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

[Ralf Hauser (Jira)]

[ 
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

[Ralf Hauser (Jira)]

[ 
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

[Ralf Hauser (Jira)]

[ 
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

[Ralf Hauser (Jira)]

[ 
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-5002) PDFTextStripper sometimes fuses two words on different lines

[Jira]

[ 
https://issues.apache.org/jira/browse/PDFBOX-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220788#comment-17220788
 ] 

Thierry Guérin commented on PDFBOX-5002:


Created [https://github.com/apache/pdfbox/pull/89] that fixes the problem

> PDFTextStripper sometimes fuses two words on different lines
> 
>
> Key: PDFBOX-5002
> URL: https://issues.apache.org/jira/browse/PDFBOX-5002
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.21
>Reporter: Thierry Guérin
>Priority: Minor
> Fix For: 2.0.22
>
> Attachments: small
>
>
> This happens when a text in a big font is followed by at least two lines of 
> text in a smaller font: the last word of the first line is merged with the 
> first word of the second line.
> On the attached PDF, the extracted text is :
> {noformat}
> (...) some text awith smaller font (...){noformat}
> instead of:
>  
> {noformat}
> (...) some text with a smaller font (...)
> {noformat}
> I often encounter this kind of problem on invoices, where the company address 
> (small text at the top right) is next to the company name & logo (big 
> centered text at the top).
>  



--
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

[GitHub] [pdfbox] SchwingSK opened a new pull request #89: PDFBOX-5002: fix word detection in PDFTextStripper

[GitBox]

SchwingSK opened a new pull request #89:
URL: https://github.com/apache/pdfbox/pull/89


   The problem lied with the fact that maxHeightForLine is kept, even when the 
text font changes (which is intentional so as not to trigger a new line when 
there is sub/superscript). This leads in this case to PDFTextStripper merging 
two lines that should be separate.
   The patch assumes that when the current character is separated from the 
previous one, the maxHeightForLine has to be reset.
   This breaks only one test: eu-001.pdf, and it should as the new code 
correctly detects two lines where there was only one detected before.
   
   (the patch has been tested with mvn clean test on the 2.0.21 branch with 
commit bdf2ae77e693cc73d4cdeb9a95c6ac2845d11ead applied, as the current 2.0 
branch does not pass tests)



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-5002) PDFTextStripper sometimes fuses two words on different lines

[Jira]

Thierry Guérin created PDFBOX-5002:
--

 Summary: PDFTextStripper sometimes fuses two words on different 
lines
 Key: PDFBOX-5002
 URL: https://issues.apache.org/jira/browse/PDFBOX-5002
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.21
Reporter: Thierry Guérin
 Fix For: 2.0.22
 Attachments: small

This happens when a text in a big font is followed by at least two lines of 
text in a smaller font: the last word of the first line is merged with the 
first word of the second line.

On the attached PDF, the extracted text is :
{noformat}
(...) some text awith smaller font (...){noformat}
instead of:

 
{noformat}
(...) some text with a smaller font (...)
{noformat}
I often encounter this kind of problem on invoices, where the company address 
(small text at the top right) is next to the company name & logo (big centered 
text at the top).

 



--
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-5002) PDFTextStripper sometimes fuses two words on different lines

[Jira]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thierry Guérin updated PDFBOX-5002:
---
Attachment: small

> PDFTextStripper sometimes fuses two words on different lines
> 
>
> Key: PDFBOX-5002
> URL: https://issues.apache.org/jira/browse/PDFBOX-5002
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.21
>Reporter: Thierry Guérin
>Priority: Minor
> Fix For: 2.0.22
>
> Attachments: small
>
>
> This happens when a text in a big font is followed by at least two lines of 
> text in a smaller font: the last word of the first line is merged with the 
> first word of the second line.
> On the attached PDF, the extracted text is :
> {noformat}
> (...) some text awith smaller font (...){noformat}
> instead of:
>  
> {noformat}
> (...) some text with a smaller font (...)
> {noformat}
> I often encounter this kind of problem on invoices, where the company address 
> (small text at the top right) is next to the company name & logo (big 
> centered text at the top).
>  



--
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-2776) support "Long Term Validation" signature extensions (LTV)

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220723#comment-17220723
 ] 

Michael Klink edited comment on PDFBOX-2776 at 10/26/20, 2:31 PM:
--

{quote}The remaining problem is "have LTV" in a pdf whose signature is 
"certified"
{quote}
More exactly, _in PDFs whose signature is "certified" with *no changes 
allowed*_. Applying LTV to documents with signatures certified with *only form 
fill-ins allowed* or with *form fill-ins and annotation creation, deletion, and 
modification allowed* can be done just like to PDFs with mere approval 
signatures.

ISO 32000-2 explicitly _does_ allow adding DSS information to PDFs whose 
signature is _certified with no changes allowed_ but Adobe Acrobat rejects such 
files nonetheless, see PDFBOX-3017.

This might even not be a simple Acrobat bug (one could hope to be fixed 
sometime soon) but actually a deviation from the standard desired by Adobe 
(never to be fixed); maybe they based their implemented work flows too strongly 
on PDFs not changing anymore once they are certified with no changes allowed.

So as long as Adobe Acrobat validation code is not fixed in this regard, you 
cannot LTV-enable signatures certified with no changes allowed after signing. 
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).


was (Author: mkl):
{quote}The remaining problem is "have LTV" in a pdf whose signature is 
"certified"
{quote}
More exactly, _in PDFs whose signature is "certified" with *no changes 
allowed*_. Applying LTV to documents with signatures certified with *only form 
fill-ins allowed* or with *form fill-ins and annotation creation, deletion, and 
modification allowed* can be LTV-enabled just like PDFs with mere approval 
signatures.

ISO 32000-2 explicitly does allow adding DSS information to PDFs whose 
signature is certified with no changes allowed but Adobe Acrobat rejects such 
attempts nonetheless, see PDFBOX-3017.

This might even not be a simple Acrobat bug (one could hope to be fixed 
sometime soon) but actually a deviation from the standard desired by Adobe 
(never to be fixed); maybe they based their implemented work flows too strictly 
on PDFs not changing anymore once they are certified with no changes allowed.

So as long as Adobe Acrobat validation code is not fixed in this regard, you 
cannot LTV-enable signatures certified with no changes allowed after signing. 
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).

> 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-2776) support "Long Term Validation" signature extensions (LTV)

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220723#comment-17220723
 ] 

Michael Klink edited comment on PDFBOX-2776 at 10/26/20, 2:20 PM:
--

{quote}The remaining problem is "have LTV" in a pdf whose signature is 
"certified"
{quote}
More exactly, _in PDFs whose signature is "certified" with *no changes 
allowed*_. Applying LTV to documents with signatures certified with *only form 
fill-ins allowed* or with *form fill-ins and annotation creation, deletion, and 
modification allowed* can be LTV-enabled just like PDFs with mere approval 
signatures.

ISO 32000-2 explicitly does allow adding DSS information to PDFs whose 
signature is certified with no changes allowed but Adobe Acrobat rejects such 
attempts nonetheless, see PDFBOX-3017.

This might even not be a simple Acrobat bug (one could hope to be fixed 
sometime soon) but actually a deviation from the standard desired by Adobe 
(never to be fixed); maybe they based their implemented work flows too strictly 
on PDFs not changing anymore once they are certified with no changes allowed.

So as long as Adobe Acrobat validation code is not fixed in this regard, you 
cannot LTV-enable signatures certified with no changes allowed after signing. 
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).


was (Author: mkl):
{quote}The remaining problem is "have LTV" in a pdf whose signature is 
"certified"
{quote}
More exactly, _in PDFs whose signature is "certified" with *no changes 
allowed*_. Applying LTV to documents with signatures certified with *only form 
fill-ins allowed* or with *form fill-ins and annotation creation, deletion, and 
modification allowed* can be LTV-enabled just like PDFs with mere approval 
signatures.

ISO 32000-2 explicitly does allow adding DSS information to PDFs whose 
signature is certified with no changes allowed but Adobe Acrobat rejects such 
attempts nonetheless, see PDFBOX-3017.

This might even not be a simple Acrobat bug (one could hope to be fixed 
sometime soon) but actually a deviation from the standard desired by Adobe 
(never to be fixed); maybe they based their implemented work flows too strictly 
on PDFs not changing anymore once they are certified with no changes allowed.

> 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] [Commented] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220723#comment-17220723
 ] 

Michael Klink commented on PDFBOX-2776:
---

{quote}The remaining problem is "have LTV" in a pdf whose signature is 
"certified"
{quote}
More exactly, _in PDFs whose signature is "certified" with *no changes 
allowed*_. Applying LTV to documents with signatures certified with *only form 
fill-ins allowed* or with *form fill-ins and annotation creation, deletion, and 
modification allowed* can be LTV-enabled just like PDFs with mere approval 
signatures.

ISO 32000-2 explicitly does allow adding DSS information to PDFs whose 
signature is certified with no changes allowed but Adobe Acrobat rejects such 
attempts nonetheless, see PDFBOX-3017.

This might even not be a simple Acrobat bug (one could hope to be fixed 
sometime soon) but actually a deviation from the standard desired by Adobe 
(never to be fixed); maybe they based their implemented work flows too strictly 
on PDFs not changing anymore once they are certified with no changes allowed.

> 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] [Commented] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220692#comment-17220692
 ] 

Michael Klink commented on PDFBOX-2776:
---

{quote}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{quote}
The problem with that file: It claims conformance to PDF/A-1a but Adobe Acrobat 
Preflight sees many deviations from ISO 19005-1:
 !notCertified_368835_Sig_en_201026090509_report.png! 
While it may currently be possible to add validation information which in 
_current Acrobat Viewer turns all green_, this may change anytime when Acrobat 
takes additional document validity data into account during verification.

> 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] [Updated] (PDFBOX-2776) support "Long Term Validation" signature extensions (LTV)

[Michael Klink (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Klink updated PDFBOX-2776:
--
Attachment: notCertified_368835_Sig_en_201026090509_report.png

> 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] [Commented] (PDFBOX-3017) Improve document signing

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220669#comment-17220669
 ] 

Michael Klink commented on PDFBOX-3017:
---

{quote}[~tilman]>I've replaced it with a warning. This is example code so in 
theory people should read it and decide on their own.{quote}
Great!
Yes, you're right, this is example code, so such a warning indeed is the most 
appropriate way to put it.

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-3017) Improve document signing

[Michael Klink (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220665#comment-17220665
 ] 

Michael Klink commented on PDFBOX-3017:
---

{quote}[~msahyoun]> just curious - which version of Adobe Reader did you use 
for testing.{quote}
Adobe Acrobat Reader DC version 2019.012.20040 for Windows which happens to be 
installed on my office computer.
I just tested the files on my home computer with DC version 2020.012.20048 
(which appears to be current) with the same result.

> Improve document signing
> 
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm, Signing
>Affects Versions: 2.0.0, 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: Eingangsbestaetigung-376670811-sig.pdf, 
> Eingangsbestaetigung-376670811-sig_ocsp.pdf, 
> PDFBOX-3017_certificate_chain.diff, 
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf, 
> SO52757037-Signed3-OCSP-with-KeyHash.pdf, pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates 
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR 
> {{acroForm.setDefaultResources(null)}} which is not good if there are other 
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}} 
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature, 
> instead having to create a COSDocument with a page and annotations that has 
> the signature field, and that must be searched for in 
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see 
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
>  )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see 
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
>  ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this 
> for invisible signatures); test signed files with PDF-Tools and with 
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old 
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in 
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties 
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call 
> {{visSignatureProperties.getVisibleSignature()}} which returns an 
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample 
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users, 
> code 
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with 
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...



--
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-4985) Render orphan annotation widgets

[Maruan Sahyoun (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220580#comment-17220580
 ] 

Maruan Sahyoun commented on PDFBOX-4985:


The data lines are off compared to the Acrobat version. I'd keep it as is WDYT?

If you're fine with the result shall we also port that to the 2.0 branch? Will 
probably affect existing applications not on the API level but because of 
getting a different result now - although a better one :-). I'd go for it.

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-new.pdf, 
> POPPLER-806-p2.jpg, POPPLER-806-page2.jpg, POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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)

[Ralf Hauser (Jira)]

[ 
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] [Commented] (PDFBOX-4985) Render orphan annotation widgets

[Maruan Sahyoun (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220571#comment-17220571
 ] 

Maruan Sahyoun commented on PDFBOX-4985:


thx - also slightly off. Need to look into that.

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-new.pdf, 
> POPPLER-806-p2.jpg, POPPLER-806-page2.jpg, POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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)

[Ralf Hauser (Jira)]

 [ 
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

Jenkins build is back to normal : PDFBox » PDFBox-trunk #190

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-4985) Render orphan annotation widgets

[Tilman Hausherr (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-4985:

Attachment: POPPLER-806-new.pdf
POPPLER-806-p2.jpg

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-new.pdf, 
> POPPLER-806-p2.jpg, POPPLER-806-page2.jpg, POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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-4985) Render orphan annotation widgets

[Maruan Sahyoun (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220545#comment-17220545
 ] 

Maruan Sahyoun commented on PDFBOX-4985:


Could you upload the corrected PDF and the rendering of the 2nd page? The 
summary of the table is slightly off on my system and I'd like to compare with 
your results.

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-page2.jpg, 
> POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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-4985) Render orphan annotation widgets

[Tilman Hausherr (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220534#comment-17220534
 ] 

Tilman Hausherr commented on PDFBOX-4985:
-

Yes it failed locally. My guess is that the CI and your machine don't have the 
Webdings font and used the fallback font, which has space. It works now, thank 
you.

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-page2.jpg, 
> POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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-4985) Render orphan annotation widgets

[Maruan Sahyoun (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220528#comment-17220528
 ] 

Maruan Sahyoun commented on PDFBOX-4985:


[~tilman] {{PlainText}} no longer adds a space character in case of a 
completely empty string (but still does in case of an empty paragraph in 
between). Could you check if that resolves your issue?  

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-page2.jpg, 
> POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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-4985) Render orphan annotation widgets

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220526#comment-17220526
 ] 

ASF subversion and git services commented on PDFBOX-4985:
-

Commit 1882866 from Maruan Sahyoun in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1882866 ]

PDFBOX-4985: don't add space character if there is no text at all

> Render orphan annotation widgets
> 
>
> Key: PDFBOX-4985
> URL: https://issues.apache.org/jira/browse/PDFBOX-4985
> Project: PDFBox
>  Issue Type: Improvement
>  Components: AcroForm
>Affects Versions: 2.0.21
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Minor
>  Labels: Appearance, Rendering
> Attachments: POPPLER-806-acrobat.pdf, POPPLER-806-page2.jpg, 
> POPPLER-806.pdf
>
>
> The attached file has orphan widget annotations on page 2. These are rendered 
> with Adobe, PDF.js (poorly), Chrome, and ghostscript, but not with PDFBox.



--
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