Jenkins build is back to stable : PDFBox » PDFBox-sonar2 #1081

[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-sonar2 » Apache PDFBox examples #1081

[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-jdk21 #803

[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-jdk21 » Apache PDFBox examples #803

[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-5518) "Threads" array in Document Catalog should be an indirect reference

[Jira]

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

Andreas Lehmkühler commented on PDFBOX-5518:


Please attach a sample pdf containing threads

> "Threads" array in Document Catalog should be an indirect reference
> ---
>
> Key: PDFBOX-5518
> URL: https://issues.apache.org/jira/browse/PDFBOX-5518
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.26
>Reporter: Christian Appl
>Assignee: Andreas Lehmkühler
>Priority: Major
> Attachments: image-2022-09-23-09-50-30-766.png, 
> image-2022-09-23-10-03-15-070.png, image-2022-09-23-10-54-31-618.png
>
>
> *TL;DR:*
> When using either of the methods "getThreads" or "setThreads" in class 
> PDDocumentCatalog and saving the resulting document: Adobe Preflight is 
> reporting an issue with the resulting "Threads" array in the document catalog 
> and claims it should have been an indirect object reference instead of a 
> direct object.
> My claim: The COSWriter should be able to create indirect objects for 
> COSArrays when required.
> *Checking PDF-32000-1:*
> In table 28 "Entries in the catalog dictionary" we can find the following 
> definition:
> !image-2022-09-23-09-50-30-766.png!
> *Determining reasons:*
> 1. The mentioned get and set methods create a COSArray for the entry 
> "Threads" of the catalog dictionary
> 2. The COSWriter is assuming, that COSArrays should always preferably be 
> written as a direct substructure of a dictionary.
> This may be entirely true for other arrays, but in this case is is cause for 
> a syntactical error in resulting documents. (It is plausible and possible - 
> but has not been checked - whether this causes issues for other structures 
> aswell.)
> The COSWriter provides the means to create indirect objects for 
> COSDictionaries, it however does (as far as I can see) not provide the means 
> to flag a COSArray for the same handling.
> *Possible solutions:*
> As far as I can see the COSWriter would be entirely capable of creating 
> COSObjects for any of the COSBase types, the only thing missing is the 
> ability to mark a COSArray to be written indirectly and the matching handling 
> by the COSWriter.
> Adding something like:
> !image-2022-09-23-10-03-15-070.png!
> at the right places in the COSWriter (similar to the handling of indirect 
> COSDictionaries) seems to do the trick and resolves the issue.
> *Important issue?:*
> I fixed this on our end and hence it is not a pressing issue, also "Threads" 
> is not as important and common as other structures and hence most documents 
> and users won´t encounter this issue at all.
> However - It would be nice, should this be fixed.
> *Concerning a possible patch:*
> I could provide a patch making the required changes, but would have to adapt 
> it for the current PDFBox 2.0.27-SNAPSHOT as I developed it rather as a 
> hotfix for our mirror of the library.
> And concerning that patch I should mention:
> As can be assumed - a "isDirectArray" and "setDirectArray" method have been 
> added to the COSArray - which is a quick and dirty solution, as it would be 
> preferable for COSArray to use the already existing "direct" field, that 
> other COSBase types (COSDictionaries) already use.
> As stated - the solution is quick and dirty and for a final solution in the 
> PDFBox library a cleaner approach would be preferable. Hence I did not 
> provide that patch for now.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Assigned] (PDFBOX-5518) "Threads" array in Document Catalog should be an indirect reference

[Jira]

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

Andreas Lehmkühler reassigned PDFBOX-5518:
--

Assignee: Andreas Lehmkühler

> "Threads" array in Document Catalog should be an indirect reference
> ---
>
> Key: PDFBOX-5518
> URL: https://issues.apache.org/jira/browse/PDFBOX-5518
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.26
>Reporter: Christian Appl
>Assignee: Andreas Lehmkühler
>Priority: Major
> Attachments: image-2022-09-23-09-50-30-766.png, 
> image-2022-09-23-10-03-15-070.png, image-2022-09-23-10-54-31-618.png
>
>
> *TL;DR:*
> When using either of the methods "getThreads" or "setThreads" in class 
> PDDocumentCatalog and saving the resulting document: Adobe Preflight is 
> reporting an issue with the resulting "Threads" array in the document catalog 
> and claims it should have been an indirect object reference instead of a 
> direct object.
> My claim: The COSWriter should be able to create indirect objects for 
> COSArrays when required.
> *Checking PDF-32000-1:*
> In table 28 "Entries in the catalog dictionary" we can find the following 
> definition:
> !image-2022-09-23-09-50-30-766.png!
> *Determining reasons:*
> 1. The mentioned get and set methods create a COSArray for the entry 
> "Threads" of the catalog dictionary
> 2. The COSWriter is assuming, that COSArrays should always preferably be 
> written as a direct substructure of a dictionary.
> This may be entirely true for other arrays, but in this case is is cause for 
> a syntactical error in resulting documents. (It is plausible and possible - 
> but has not been checked - whether this causes issues for other structures 
> aswell.)
> The COSWriter provides the means to create indirect objects for 
> COSDictionaries, it however does (as far as I can see) not provide the means 
> to flag a COSArray for the same handling.
> *Possible solutions:*
> As far as I can see the COSWriter would be entirely capable of creating 
> COSObjects for any of the COSBase types, the only thing missing is the 
> ability to mark a COSArray to be written indirectly and the matching handling 
> by the COSWriter.
> Adding something like:
> !image-2022-09-23-10-03-15-070.png!
> at the right places in the COSWriter (similar to the handling of indirect 
> COSDictionaries) seems to do the trick and resolves the issue.
> *Important issue?:*
> I fixed this on our end and hence it is not a pressing issue, also "Threads" 
> is not as important and common as other structures and hence most documents 
> and users won´t encounter this issue at all.
> However - It would be nice, should this be fixed.
> *Concerning a possible patch:*
> I could provide a patch making the required changes, but would have to adapt 
> it for the current PDFBox 2.0.27-SNAPSHOT as I developed it rather as a 
> hotfix for our mirror of the library.
> And concerning that patch I should mention:
> As can be assumed - a "isDirectArray" and "setDirectArray" method have been 
> added to the COSArray - which is a quick and dirty solution, as it would be 
> preferable for COSArray to use the already existing "direct" field, that 
> other COSBase types (COSDictionaries) already use.
> As stated - the solution is quick and dirty and for a final solution in the 
> PDFBox library a cleaner approach would be preferable. Hence I did not 
> provide that patch for now.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
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-jdk21 #802

[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-jdk21 » Apache PDFBox examples #802

[Apache Jenkins Server]

See 



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

[jira] [Created] (PDFBOX-5637) Add getter and setter for the CO array under PDAcroForm

[Gilad Denneboom (Jira)]

Gilad Denneboom created PDFBOX-5637:
---

 Summary: Add getter and setter for the CO array under PDAcroForm
 Key: PDFBOX-5637
 URL: https://issues.apache.org/jira/browse/PDFBOX-5637
 Project: PDFBox
  Issue Type: Improvement
  Components: AcroForm
Affects Versions: 2.0.29
Reporter: Gilad Denneboom


The CO-array is a part of the AcroForm object, which defines the order in which 
fields are calculated (see Table 218 in the PDF ISO specs). It contains 
(indirect) references to the calculated fields.

It would be nice to have a direct getter and setter for it under PDAcroForm. 
Also, if the references could be automatically converted to point to the actual 
PDField objects, that would be great.

In order to do that, the values from this array need to be compared to those 
returned by the getCOSObject method of the PDField objects returned by the 
getFields methods of PDAcroForm.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
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-sonar2 #1080

[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-sonar2 » Apache PDFBox examples #1080

[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-5619) Check NTP time in signature tests

[Tilman Hausherr (Jira)]

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

Tilman Hausherr commented on PDFBOX-5619:
-

There is a correlation:
{noformat}
[ERROR] Tests run: 17, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 26.46 
s <<< FAILURE! - in org.apache.pdfbox.examples.pdmodel.TestCreateSignature
[ERROR] testTimeDifference  Time elapsed: 5.422 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: Local time is off by more than 18 seconds 
==> expected:  but was: 
at 
org.apache.pdfbox.examples.pdmodel.TestCreateSignature.testTimeDifference(TestCreateSignature.java:233)

[ERROR] testCreateSignedTimeStamp  Time elapsed: 3.392 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: OCSP answer is too old, is from 24 seconds 
ago ==> expected:  but was: 
at 
org.apache.pdfbox.examples.pdmodel.TestCreateSignature.checkLTV(TestCreateSignature.java:1071)
at 
org.apache.pdfbox.examples.pdmodel.TestCreateSignature.testCreateSignedTimeStamp(TestCreateSignature.java:386)

[ERROR] testAddValidationInformation  Time elapsed: 2.344 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: OCSP answer is too old, is from 25 seconds 
ago ==> expected:  but was: 
at 
org.apache.pdfbox.examples.pdmodel.TestCreateSignature.checkLTV(TestCreateSignature.java:1071)
at 
org.apache.pdfbox.examples.pdmodel.TestCreateSignature.testAddValidationInformation(TestCreateSignature.java:925)
{noformat}

> Check NTP time in signature tests
> -
>
> Key: PDFBOX-5619
> URL: https://issues.apache.org/jira/browse/PDFBOX-5619
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Signing
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> We keep getting "OCSP answer is too old, is from 25 seconds ago" fails on 
> some builds. I want to find out whether this is because some build machines 
> don't tun on the correct time.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
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-sonar2 #1079

[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-sonar2 » Apache PDFBox examples #1079

[Apache Jenkins Server]

See 



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