[jira] [Commented] (PDFBOX-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243787#comment-17243787 ] ASF subversion and git services commented on PDFBOX-2602: - Commit 1884088 from Maruan Sahyoun in branch 'pdfbox/trunk' [ https://svn.apache.org/r1884088 ] PDFBOX-2602: use try-with-resources > Enhance command line tools > -- > > Key: PDFBOX-2602 > URL: https://issues.apache.org/jira/browse/PDFBOX-2602 > Project: PDFBox > Issue Type: Bug > Components: Utilities >Affects Versions: 1.8.8, 2.0.0 >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 3.0.0 PDFBox > > > The command line tools shall be enhanced to have the same behavior across all > tools. > From the discussion on the dev mailing list > - add an -h option to print the usage > - print the usage to System.err and use an exit code of 1 if there was an > invalid command line parameter > - print messages on exceptions to System.err > - rethrow the exception so java can handle it if it will terminate afterwards > anyway > - use an exit code of 1if rethrowing doesn't make sense -- 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-4999) Dangerous COSDictionary.addAll(COSDictionary) method
[
https://issues.apache.org/jira/browse/PDFBOX-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243777#comment-17243777
]
ASF subversion and git services commented on PDFBOX-4999:
-
Commit 1884086 from le...@apache.org in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1884086 ]
PDFBOX-4999: don't skip size values when merging COSDictionaries as proposed by
Michael Klink
> Dangerous COSDictionary.addAll(COSDictionary) method
>
>
> Key: PDFBOX-4999
> URL: https://issues.apache.org/jira/browse/PDFBOX-4999
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 2.0.21, 3.0.0 PDFBox
>Reporter: Michael Klink
>Assignee: Andreas Lehmkühler
>Priority: Critical
> Fix For: 2.0.22, 3.0.0 PDFBox
>
>
> The method {{COSDictionary.addAll(COSDictionary)}} creates the impression, by
> name and by JavaDoc comment,
> {code:java}
> /**
> * This will add all of the dictionaries keys/values to this dictionary.
> ...
> {code}
> that it can be used for exactly that, adding all key/value pairs from the
> argument dictionary to the current one, replacing old entries for the same
> keys.
> If one looks at the implementation, though, one is in for a surprise:
> {code:java}
> /**
> * This will add all of the dictionaries keys/values to this dictionary.
> * Only called when adding keys to a trailer that already exists.
> *
> * @param dic The dictionaries to get the keys from.
> */
> public void addAll(COSDictionary dic)
> {
> dic.forEach((key, value) ->
> {
> /*
> * If we're at a second trailer, we have a linearized pdf file,
> meaning that the first Size entry represents
> * all of the objects so we don't need to grab the second.
> */
> if (!COSName.SIZE.equals(key) || !items.containsKey(COSName.SIZE))
> {
> setItem(key, value);
> }
> });
> }
> {code}
> Here existing *Size* entries explicitly are not replaced!
> This appears to be a relic from times when PDFBox parsed PDF documents front
> to back, ignoring cross reference streams, for improved results with
> linearized files when merging trailer dictionaries.
> Nowadays this exceptional treatment of *Size* does not make any sense
> anymore, see [this stack overflow
> answer|https://stackoverflow.com/a/64502740/1729265].
> Furthermore, this method is used in other contexts than creating trailer
> unions, even some PDFBox methods use it to create arbitrary dictionary unions:
> *
> {{org.apache.pdfbox.pdmodel.PDDocument.assignAcroFormDefaultResource(PDAcroForm,
> COSDictionary)}}
> * {{org.apache.pdfbox.filter.JPXFilter.decode(InputStream, OutputStream,
> COSDictionary, int, DecodeOptions)}}
> * {{org.apache.pdfbox.examples.interactive.form.FieldTriggers.main(String[])}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.PDImageXObject(PDStream,
> PDResources)}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDInlineImage.PDInlineImage(COSDictionary,
> byte[], PDResources)}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDInlineImageTest.testInlineImage()}}
> * {{org.apache.pdfbox.pdfparser.XrefTrailerResolver.setStartxref(long)}}
> (This list is offered by eclipse as callers of that method. There may be
> other, hidden calls.)
> Thus, this exception should be removed after all usages of that method in
> PDFBox have been analyzed.
--
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-4999) Dangerous COSDictionary.addAll(COSDictionary) method
[
https://issues.apache.org/jira/browse/PDFBOX-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler resolved PDFBOX-4999.
Resolution: Fixed
> Dangerous COSDictionary.addAll(COSDictionary) method
>
>
> Key: PDFBOX-4999
> URL: https://issues.apache.org/jira/browse/PDFBOX-4999
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 2.0.21, 3.0.0 PDFBox
>Reporter: Michael Klink
>Assignee: Andreas Lehmkühler
>Priority: Critical
> Fix For: 2.0.22, 3.0.0 PDFBox
>
>
> The method {{COSDictionary.addAll(COSDictionary)}} creates the impression, by
> name and by JavaDoc comment,
> {code:java}
> /**
> * This will add all of the dictionaries keys/values to this dictionary.
> ...
> {code}
> that it can be used for exactly that, adding all key/value pairs from the
> argument dictionary to the current one, replacing old entries for the same
> keys.
> If one looks at the implementation, though, one is in for a surprise:
> {code:java}
> /**
> * This will add all of the dictionaries keys/values to this dictionary.
> * Only called when adding keys to a trailer that already exists.
> *
> * @param dic The dictionaries to get the keys from.
> */
> public void addAll(COSDictionary dic)
> {
> dic.forEach((key, value) ->
> {
> /*
> * If we're at a second trailer, we have a linearized pdf file,
> meaning that the first Size entry represents
> * all of the objects so we don't need to grab the second.
> */
> if (!COSName.SIZE.equals(key) || !items.containsKey(COSName.SIZE))
> {
> setItem(key, value);
> }
> });
> }
> {code}
> Here existing *Size* entries explicitly are not replaced!
> This appears to be a relic from times when PDFBox parsed PDF documents front
> to back, ignoring cross reference streams, for improved results with
> linearized files when merging trailer dictionaries.
> Nowadays this exceptional treatment of *Size* does not make any sense
> anymore, see [this stack overflow
> answer|https://stackoverflow.com/a/64502740/1729265].
> Furthermore, this method is used in other contexts than creating trailer
> unions, even some PDFBox methods use it to create arbitrary dictionary unions:
> *
> {{org.apache.pdfbox.pdmodel.PDDocument.assignAcroFormDefaultResource(PDAcroForm,
> COSDictionary)}}
> * {{org.apache.pdfbox.filter.JPXFilter.decode(InputStream, OutputStream,
> COSDictionary, int, DecodeOptions)}}
> * {{org.apache.pdfbox.examples.interactive.form.FieldTriggers.main(String[])}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.PDImageXObject(PDStream,
> PDResources)}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDInlineImage.PDInlineImage(COSDictionary,
> byte[], PDResources)}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDInlineImageTest.testInlineImage()}}
> * {{org.apache.pdfbox.pdfparser.XrefTrailerResolver.setStartxref(long)}}
> (This list is offered by eclipse as callers of that method. There may be
> other, hidden calls.)
> Thus, this exception should be removed after all usages of that method in
> PDFBox have been analyzed.
--
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-4999) Dangerous COSDictionary.addAll(COSDictionary) method
[
https://issues.apache.org/jira/browse/PDFBOX-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243782#comment-17243782
]
Andreas Lehmkühler commented on PDFBOX-4999:
The size value isn't skipped any more when merging COSDictionaries. Now, the
size value is overwritten when merging the trailer dictionaries of a pdf, but
that isn't an issue for two reasons. The size value isn't use after merging and
the merged value is as wrong/right as the other two ones of the non merged
dictionaries.
[~mkl] Thanks for the report
> Dangerous COSDictionary.addAll(COSDictionary) method
>
>
> Key: PDFBOX-4999
> URL: https://issues.apache.org/jira/browse/PDFBOX-4999
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 2.0.21, 3.0.0 PDFBox
>Reporter: Michael Klink
>Assignee: Andreas Lehmkühler
>Priority: Critical
> Fix For: 2.0.22, 3.0.0 PDFBox
>
>
> The method {{COSDictionary.addAll(COSDictionary)}} creates the impression, by
> name and by JavaDoc comment,
> {code:java}
> /**
> * This will add all of the dictionaries keys/values to this dictionary.
> ...
> {code}
> that it can be used for exactly that, adding all key/value pairs from the
> argument dictionary to the current one, replacing old entries for the same
> keys.
> If one looks at the implementation, though, one is in for a surprise:
> {code:java}
> /**
> * This will add all of the dictionaries keys/values to this dictionary.
> * Only called when adding keys to a trailer that already exists.
> *
> * @param dic The dictionaries to get the keys from.
> */
> public void addAll(COSDictionary dic)
> {
> dic.forEach((key, value) ->
> {
> /*
> * If we're at a second trailer, we have a linearized pdf file,
> meaning that the first Size entry represents
> * all of the objects so we don't need to grab the second.
> */
> if (!COSName.SIZE.equals(key) || !items.containsKey(COSName.SIZE))
> {
> setItem(key, value);
> }
> });
> }
> {code}
> Here existing *Size* entries explicitly are not replaced!
> This appears to be a relic from times when PDFBox parsed PDF documents front
> to back, ignoring cross reference streams, for improved results with
> linearized files when merging trailer dictionaries.
> Nowadays this exceptional treatment of *Size* does not make any sense
> anymore, see [this stack overflow
> answer|https://stackoverflow.com/a/64502740/1729265].
> Furthermore, this method is used in other contexts than creating trailer
> unions, even some PDFBox methods use it to create arbitrary dictionary unions:
> *
> {{org.apache.pdfbox.pdmodel.PDDocument.assignAcroFormDefaultResource(PDAcroForm,
> COSDictionary)}}
> * {{org.apache.pdfbox.filter.JPXFilter.decode(InputStream, OutputStream,
> COSDictionary, int, DecodeOptions)}}
> * {{org.apache.pdfbox.examples.interactive.form.FieldTriggers.main(String[])}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.PDImageXObject(PDStream,
> PDResources)}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDInlineImage.PDInlineImage(COSDictionary,
> byte[], PDResources)}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDInlineImageTest.testInlineImage()}}
> * {{org.apache.pdfbox.pdfparser.XrefTrailerResolver.setStartxref(long)}}
> (This list is offered by eclipse as callers of that method. There may be
> other, hidden calls.)
> Thus, this exception should be removed after all usages of that method in
> PDFBox have been analyzed.
--
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-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243779#comment-17243779 ] Maruan Sahyoun commented on PDFBOX-2602: [~tilman] I won't touch Encrypt for now given that there is PDFBOX-5027 > Enhance command line tools > -- > > Key: PDFBOX-2602 > URL: https://issues.apache.org/jira/browse/PDFBOX-2602 > Project: PDFBox > Issue Type: Bug > Components: Utilities >Affects Versions: 1.8.8, 2.0.0 >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 3.0.0 PDFBox > > > The command line tools shall be enhanced to have the same behavior across all > tools. > From the discussion on the dev mailing list > - add an -h option to print the usage > - print the usage to System.err and use an exit code of 1 if there was an > invalid command line parameter > - print messages on exceptions to System.err > - rethrow the exception so java can handle it if it will terminate afterwards > anyway > - use an exit code of 1if rethrowing doesn't make sense -- 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-4999) Dangerous COSDictionary.addAll(COSDictionary) method
[
https://issues.apache.org/jira/browse/PDFBOX-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243778#comment-17243778
]
ASF subversion and git services commented on PDFBOX-4999:
-
Commit 1884087 from le...@apache.org in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1884087 ]
PDFBOX-4999: don't skip size values when merging COSDictionaries as proposed by
Michael Klink
> Dangerous COSDictionary.addAll(COSDictionary) method
>
>
> Key: PDFBOX-4999
> URL: https://issues.apache.org/jira/browse/PDFBOX-4999
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 2.0.21, 3.0.0 PDFBox
>Reporter: Michael Klink
>Assignee: Andreas Lehmkühler
>Priority: Critical
> Fix For: 2.0.22, 3.0.0 PDFBox
>
>
> The method {{COSDictionary.addAll(COSDictionary)}} creates the impression, by
> name and by JavaDoc comment,
> {code:java}
> /**
> * This will add all of the dictionaries keys/values to this dictionary.
> ...
> {code}
> that it can be used for exactly that, adding all key/value pairs from the
> argument dictionary to the current one, replacing old entries for the same
> keys.
> If one looks at the implementation, though, one is in for a surprise:
> {code:java}
> /**
> * This will add all of the dictionaries keys/values to this dictionary.
> * Only called when adding keys to a trailer that already exists.
> *
> * @param dic The dictionaries to get the keys from.
> */
> public void addAll(COSDictionary dic)
> {
> dic.forEach((key, value) ->
> {
> /*
> * If we're at a second trailer, we have a linearized pdf file,
> meaning that the first Size entry represents
> * all of the objects so we don't need to grab the second.
> */
> if (!COSName.SIZE.equals(key) || !items.containsKey(COSName.SIZE))
> {
> setItem(key, value);
> }
> });
> }
> {code}
> Here existing *Size* entries explicitly are not replaced!
> This appears to be a relic from times when PDFBox parsed PDF documents front
> to back, ignoring cross reference streams, for improved results with
> linearized files when merging trailer dictionaries.
> Nowadays this exceptional treatment of *Size* does not make any sense
> anymore, see [this stack overflow
> answer|https://stackoverflow.com/a/64502740/1729265].
> Furthermore, this method is used in other contexts than creating trailer
> unions, even some PDFBox methods use it to create arbitrary dictionary unions:
> *
> {{org.apache.pdfbox.pdmodel.PDDocument.assignAcroFormDefaultResource(PDAcroForm,
> COSDictionary)}}
> * {{org.apache.pdfbox.filter.JPXFilter.decode(InputStream, OutputStream,
> COSDictionary, int, DecodeOptions)}}
> * {{org.apache.pdfbox.examples.interactive.form.FieldTriggers.main(String[])}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.PDImageXObject(PDStream,
> PDResources)}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDInlineImage.PDInlineImage(COSDictionary,
> byte[], PDResources)}}
> *
> {{org.apache.pdfbox.pdmodel.graphics.image.PDInlineImageTest.testInlineImage()}}
> * {{org.apache.pdfbox.pdfparser.XrefTrailerResolver.setStartxref(long)}}
> (This list is offered by eclipse as callers of that method. There may be
> other, hidden calls.)
> Thus, this exception should be removed after all usages of that method in
> PDFBox have been analyzed.
--
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-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243776#comment-17243776 ] Maruan Sahyoun commented on PDFBOX-2602: first tool converted to Picocli. I expect to have multiple refining rounds as I'd like to make sure that the option naming conventions and description are similar across all tools. > Enhance command line tools > -- > > Key: PDFBOX-2602 > URL: https://issues.apache.org/jira/browse/PDFBOX-2602 > Project: PDFBox > Issue Type: Bug > Components: Utilities >Affects Versions: 1.8.8, 2.0.0 >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 3.0.0 PDFBox > > > The command line tools shall be enhanced to have the same behavior across all > tools. > From the discussion on the dev mailing list > - add an -h option to print the usage > - print the usage to System.err and use an exit code of 1 if there was an > invalid command line parameter > - print messages on exceptions to System.err > - rethrow the exception so java can handle it if it will terminate afterwards > anyway > - use an exit code of 1if rethrowing doesn't make sense -- 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-5017) Switch trunk from junit4 to junit5
[ https://issues.apache.org/jira/browse/PDFBOX-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243774#comment-17243774 ] Maruan Sahyoun commented on PDFBOX-5017: IMHO we are done. There are some Sonar messages related to the change but we can do these as part of the general code quality ticket. > Switch trunk from junit4 to junit5 > -- > > Key: PDFBOX-5017 > URL: https://issues.apache.org/jira/browse/PDFBOX-5017 > Project: PDFBox > Issue Type: Test >Affects Versions: 3.0.0 PDFBox >Reporter: Andreas Lehmkühler >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: junit5-parallel.zip > > > The current trunk version has an issue with a vulnerability in the latest > version 4.13.1 of the junit plugin. Switching to junit5 solves this and it > seems to be a good idea at all. -- 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-5017) Switch trunk from junit4 to junit5
[ https://issues.apache.org/jira/browse/PDFBOX-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243773#comment-17243773 ] Andreas Lehmkühler commented on PDFBOX-5017: [~tilman], [~msahyoun] Looks like we are done here, or is still something missing? > Switch trunk from junit4 to junit5 > -- > > Key: PDFBOX-5017 > URL: https://issues.apache.org/jira/browse/PDFBOX-5017 > Project: PDFBox > Issue Type: Test >Affects Versions: 3.0.0 PDFBox >Reporter: Andreas Lehmkühler >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: junit5-parallel.zip > > > The current trunk version has an issue with a vulnerability in the latest > version 4.13.1 of the junit plugin. Switching to junit5 solves this and it > seems to be a good idea at all. -- 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-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243771#comment-17243771 ] ASF subversion and git services commented on PDFBOX-2602: - Commit 1884085 from Maruan Sahyoun in branch 'pdfbox/trunk' [ https://svn.apache.org/r1884085 ] PDFBOX-2602: initial move to Picocli for command line parsing > Enhance command line tools > -- > > Key: PDFBOX-2602 > URL: https://issues.apache.org/jira/browse/PDFBOX-2602 > Project: PDFBox > Issue Type: Bug > Components: Utilities >Affects Versions: 1.8.8, 2.0.0 >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 3.0.0 PDFBox > > > The command line tools shall be enhanced to have the same behavior across all > tools. > From the discussion on the dev mailing list > - add an -h option to print the usage > - print the usage to System.err and use an exit code of 1 if there was an > invalid command line parameter > - print messages on exceptions to System.err > - rethrow the exception so java can handle it if it will terminate afterwards > anyway > - use an exit code of 1if rethrowing doesn't make sense -- 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-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243735#comment-17243735 ] Maruan Sahyoun commented on PDFBOX-2602: [~tilman] [~lehmi] thanks for your feedback - I'll go for that. > Enhance command line tools > -- > > Key: PDFBOX-2602 > URL: https://issues.apache.org/jira/browse/PDFBOX-2602 > Project: PDFBox > Issue Type: Bug > Components: Utilities >Affects Versions: 1.8.8, 2.0.0 >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 3.0.0 PDFBox > > > The command line tools shall be enhanced to have the same behavior across all > tools. > From the discussion on the dev mailing list > - add an -h option to print the usage > - print the usage to System.err and use an exit code of 1 if there was an > invalid command line parameter > - print messages on exceptions to System.err > - rethrow the exception so java can handle it if it will terminate afterwards > anyway > - use an exit code of 1if rethrowing doesn't make sense -- 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-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243727#comment-17243727 ] Andreas Lehmkühler commented on PDFBOX-2602: Looks good to me, the license and the lib as well. Apache Commons CLI seems to be "outdated". > Enhance command line tools > -- > > Key: PDFBOX-2602 > URL: https://issues.apache.org/jira/browse/PDFBOX-2602 > Project: PDFBox > Issue Type: Bug > Components: Utilities >Affects Versions: 1.8.8, 2.0.0 >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 3.0.0 PDFBox > > > The command line tools shall be enhanced to have the same behavior across all > tools. > From the discussion on the dev mailing list > - add an -h option to print the usage > - print the usage to System.err and use an exit code of 1 if there was an > invalid command line parameter > - print messages on exceptions to System.err > - rethrow the exception so java can handle it if it will terminate afterwards > anyway > - use an exit code of 1if rethrowing doesn't make sense -- 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-5027) Protect/Encrypt PDF with multiple certificates on command line
[
https://issues.apache.org/jira/browse/PDFBOX-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr reassigned PDFBOX-5027:
---
Assignee: Tilman Hausherr
> Protect/Encrypt PDF with multiple certificates on command line
> --
>
> Key: PDFBOX-5027
> URL: https://issues.apache.org/jira/browse/PDFBOX-5027
> Project: PDFBox
> Issue Type: Improvement
> Components: Crypto
>Affects Versions: 2.0.21
>Reporter: jakatal
>Assignee: Tilman Hausherr
>Priority: Trivial
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> Hi,
> PDFBox has (obviously) the ability to protect a file with several
> certificates by adding teh recipient's certificates one after another:
>
>
> {code:java}
> //Class PublicKeyProtectionPolicy has
> public void addRecipient(PublicKeyRecipient recipient)
> {recipients.add(recipient);}
> {code}
> For the commandline tool functionality, it just offers "-cert" with the
> option to add a SINGLE certificate. I expect that in most serious use cases
> actually two certificates are used to protect the document (the actual
> recipient and the creator who wants to be able still to open the document as
> well).
>
> I propose to extend the command line functionality (Encrypt.java) by having
> an iteration through several cert files, e.g. separated by special character.
>
> Thanks.
>
--
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-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243684#comment-17243684 ] Tilman Hausherr commented on PDFBOX-2602: - yeah looks nice and the project is actively maintained > Enhance command line tools > -- > > Key: PDFBOX-2602 > URL: https://issues.apache.org/jira/browse/PDFBOX-2602 > Project: PDFBox > Issue Type: Bug > Components: Utilities >Affects Versions: 1.8.8, 2.0.0 >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 3.0.0 PDFBox > > > The command line tools shall be enhanced to have the same behavior across all > tools. > From the discussion on the dev mailing list > - add an -h option to print the usage > - print the usage to System.err and use an exit code of 1 if there was an > invalid command line parameter > - print messages on exceptions to System.err > - rethrow the exception so java can handle it if it will terminate afterwards > anyway > - use an exit code of 1if rethrowing doesn't make sense -- 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
Re: Xmas 2.0.22 Release?
Am 03.12.20 um 18:05 schrieb sahy...@fileaffairs.de: Am Donnerstag, den 03.12.2020, 17:46 +0100 schrieb Andreas Lehmkuehler: Hi, looks like there are again a lot of unreleased fixes/improvements. How about cutting 2.0.22 in about 1-2 week from now? +1 @Tim or Tilman Does anyone of you have the time to run the test arena? Would it make sense to do an initial test of 3.0? Absolutely, but I want to discuss a possible 3.0.0 prerelease in a separate thread WDYT? Andreas - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243360#comment-17243360 ] Maruan Sahyoun commented on PDFBOX-2602: @lehmi - OK to go with Picocli license wise? Is ASF 2.0 so we should be fine https://github.com/remkop/picocli/blob/master/LICENSE > Enhance command line tools > -- > > Key: PDFBOX-2602 > URL: https://issues.apache.org/jira/browse/PDFBOX-2602 > Project: PDFBox > Issue Type: Bug > Components: Utilities >Affects Versions: 1.8.8, 2.0.0 >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 3.0.0 PDFBox > > > The command line tools shall be enhanced to have the same behavior across all > tools. > From the discussion on the dev mailing list > - add an -h option to print the usage > - print the usage to System.err and use an exit code of 1 if there was an > invalid command line parameter > - print messages on exceptions to System.err > - rethrow the exception so java can handle it if it will terminate afterwards > anyway > - use an exit code of 1if rethrowing doesn't make sense -- 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
Re: Xmas 2.0.22 Release?
Am Donnerstag, den 03.12.2020, 17:46 +0100 schrieb Andreas Lehmkuehler: > Hi, > > looks like there are again a lot of unreleased fixes/improvements. > How about > cutting 2.0.22 in about 1-2 week from now? +1 > > @Tim or Tilman > Does anyone of you have the time to run the test arena? Would it make sense to do an initial test of 3.0? > > WDYT? > > Andreas > > - > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: dev-h...@pdfbox.apache.org > -- -- Maruan Sahyoun - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
Xmas 2.0.22 Release?
Hi, looks like there are again a lot of unreleased fixes/improvements. How about cutting 2.0.22 in about 1-2 week from now? @Tim or Tilman Does anyone of you have the time to run the test arena? WDYT? Andreas - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-3888) Refactor COSParser
[ https://issues.apache.org/jira/browse/PDFBOX-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Lehmkühler resolved PDFBOX-3888. Resolution: Fixed Set to resolved. I've created PDFBOX-5031 and PDFBOX-5032 for the remaining TODOs > Refactor COSParser > -- > > Key: PDFBOX-3888 > URL: https://issues.apache.org/jira/browse/PDFBOX-3888 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Affects Versions: 3.0.0 PDFBox >Reporter: Andreas Lehmkühler >Assignee: Andreas Lehmkühler >Priority: Major > Labels: parsing > Fix For: 3.0.0 PDFBox > > Attachments: QV_RCA1_RCA3_CPCPS_V4_11.pdf > > > The COSParser contains a lot of stuff which is more or less hard to > understand/maintain. I'm going to refactor some of the code as follows > - separate the bruteforce stuff maybe in its own class > - separate the parsing of the xref data maybe in its own class > - lay the foundation for the on demand parser -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5032) Refactor COSParser: separate the parsing of xref data
Andreas Lehmkühler created PDFBOX-5032: -- Summary: Refactor COSParser: separate the parsing of xref data Key: PDFBOX-5032 URL: https://issues.apache.org/jira/browse/PDFBOX-5032 Project: PDFBox Issue Type: Improvement Components: Parsing Affects Versions: 3.0.0 PDFBox Reporter: Andreas Lehmkühler Assignee: Andreas Lehmkühler Fix For: 4.0.0 This is a follow up ticket for PDFBOX-3888. We should separate the xref parser stuff to simplify/minimize the COSParser class. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5031) Refactor COSParser: separate brute force parser
Andreas Lehmkühler created PDFBOX-5031: -- Summary: Refactor COSParser: separate brute force parser Key: PDFBOX-5031 URL: https://issues.apache.org/jira/browse/PDFBOX-5031 Project: PDFBox Issue Type: Improvement Components: Parsing Affects Versions: 3.0.0 PDFBox Reporter: Andreas Lehmkühler Assignee: Andreas Lehmkühler Fix For: 4.0.0 This is a follow up ticket for PDFBOX-3888. We should separate the brute force parser stuff to simplify/minimize the COSParser class. -- 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-3359) Drawing to Graphics2D / ScratchFileBuffer not closed
[
https://issues.apache.org/jira/browse/PDFBOX-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler resolved PDFBOX-3359.
Resolution: Fixed
This shouldn't be an issue anymore as the PDFBox doesn't use scratch files
anymore when reading a pdf
> Drawing to Graphics2D / ScratchFileBuffer not closed
>
>
> Key: PDFBOX-3359
> URL: https://issues.apache.org/jira/browse/PDFBOX-3359
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
>Affects Versions: 2.0.1
>Reporter: Ivan Ridao Freitas
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
>
> First, there is a little bug on PDFRenderer.renderPageToGraphics(int
> pageIndex, Graphics2D graphics, float scale) when using scale != 1 the call
> to clearRect() fills the original size with white background, but it should
> fill the scaled size.
> Second, I implemented a JPanel which is painted using that function and on
> every paint this message goes to the console:
> "DEBUG ScratchFileBuffer:516 - ScratchFileBuffer not closed!". Here is the
> code to test it, run it and *resize the JFrame*:
> {code:title=PanelTest.java|borderStyle=solid}
> import java.awt.Dimension;
> import java.awt.Graphics;
> import java.awt.Graphics2D;
> import java.io.File;
> import java.io.IOException;
> import javax.swing.JFrame;
> import javax.swing.JPanel;
> import javax.swing.SwingUtilities;
> import javax.swing.WindowConstants;
> import org.apache.pdfbox.pdmodel.PDDocument;
> import org.apache.pdfbox.rendering.PDFRenderer;
> public class PanelTest {
>
> private static JPanel getTestPanel() {
> PDDocument doc = null;
> try {
> doc = PDDocument.load(new File("anyfile.pdf"));
> } catch (IOException e) {
> e.printStackTrace();
> }
> final PDFRenderer renderer = new PDFRenderer(doc);
> JPanel panel = new JPanel() {
> @Override
> protected void paintComponent(Graphics g) {
> try {
> renderer.renderPageToGraphics(0, (Graphics2D) g, 0.5f);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> };
> return panel;
> }
> public static void main(String[] args) throws Exception {
> SwingUtilities.invokeLater(new Runnable() {
> @Override
> public void run() {
> JFrame frame = new JFrame();
> frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
> frame.add(getTestPanel());
> frame.pack();
> frame.setSize(600, 400);
> Dimension paneSize = frame.getSize();
> Dimension screenSize = frame.getToolkit().getScreenSize();
> frame.setLocation((screenSize.width - paneSize.width) / 2,
> (screenSize.height - paneSize.height) / 2);
> frame.setTitle("Test");
> frame.setVisible(true);
> }
> });
> }
> }
> {code}
> Ivan
--
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-3359) Drawing to Graphics2D / ScratchFileBuffer not closed
[
https://issues.apache.org/jira/browse/PDFBOX-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler reassigned PDFBOX-3359:
--
Assignee: Andreas Lehmkühler
> Drawing to Graphics2D / ScratchFileBuffer not closed
>
>
> Key: PDFBOX-3359
> URL: https://issues.apache.org/jira/browse/PDFBOX-3359
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
>Affects Versions: 2.0.1
>Reporter: Ivan Ridao Freitas
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
>
> First, there is a little bug on PDFRenderer.renderPageToGraphics(int
> pageIndex, Graphics2D graphics, float scale) when using scale != 1 the call
> to clearRect() fills the original size with white background, but it should
> fill the scaled size.
> Second, I implemented a JPanel which is painted using that function and on
> every paint this message goes to the console:
> "DEBUG ScratchFileBuffer:516 - ScratchFileBuffer not closed!". Here is the
> code to test it, run it and *resize the JFrame*:
> {code:title=PanelTest.java|borderStyle=solid}
> import java.awt.Dimension;
> import java.awt.Graphics;
> import java.awt.Graphics2D;
> import java.io.File;
> import java.io.IOException;
> import javax.swing.JFrame;
> import javax.swing.JPanel;
> import javax.swing.SwingUtilities;
> import javax.swing.WindowConstants;
> import org.apache.pdfbox.pdmodel.PDDocument;
> import org.apache.pdfbox.rendering.PDFRenderer;
> public class PanelTest {
>
> private static JPanel getTestPanel() {
> PDDocument doc = null;
> try {
> doc = PDDocument.load(new File("anyfile.pdf"));
> } catch (IOException e) {
> e.printStackTrace();
> }
> final PDFRenderer renderer = new PDFRenderer(doc);
> JPanel panel = new JPanel() {
> @Override
> protected void paintComponent(Graphics g) {
> try {
> renderer.renderPageToGraphics(0, (Graphics2D) g, 0.5f);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> };
> return panel;
> }
> public static void main(String[] args) throws Exception {
> SwingUtilities.invokeLater(new Runnable() {
> @Override
> public void run() {
> JFrame frame = new JFrame();
> frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
> frame.add(getTestPanel());
> frame.pack();
> frame.setSize(600, 400);
> Dimension paneSize = frame.getSize();
> Dimension screenSize = frame.getToolkit().getScreenSize();
> frame.setLocation((screenSize.width - paneSize.width) / 2,
> (screenSize.height - paneSize.height) / 2);
> frame.setTitle("Test");
> frame.setVisible(true);
> }
> });
> }
> }
> {code}
> Ivan
--
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] [Closed] (PDFBOX-2999) Optimize COSStream scratch file usage
[
https://issues.apache.org/jira/browse/PDFBOX-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler closed PDFBOX-2999.
--
Resolution: Fixed
I've closed this ticket, as there wasn't that much progress in the last years.
Most of the discussed points are obsolete as PDFBox doesn't use scratch files
for reading anymore.
> Optimize COSStream scratch file usage
> -
>
> Key: PDFBOX-2999
> URL: https://issues.apache.org/jira/browse/PDFBOX-2999
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Timo Boehme
>Assignee: Andreas Lehmkühler
>Priority: Major
>
> The usage of scratch file buffers in COSStreams is quite sloppy. A never
> filled buffer is created in the beginning and existing buffers are discarded
> without being closed when a variant of {{createOutputStream}} is called.
> Furthermore it should be clarified if requesting an input stream without
> having created an output stream before is ok and if a returned input stream
> keeps valid after a new output stream is created (which is crucial for proper
> buffer-closing).
> This issue should resolve some of the shortcomings and document the expected
> or even required usage of COSStream.
--
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-2999) Optimize COSStream scratch file usage
[
https://issues.apache.org/jira/browse/PDFBOX-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler reassigned PDFBOX-2999:
--
Assignee: Andreas Lehmkühler (was: Timo Boehme)
> Optimize COSStream scratch file usage
> -
>
> Key: PDFBOX-2999
> URL: https://issues.apache.org/jira/browse/PDFBOX-2999
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Timo Boehme
>Assignee: Andreas Lehmkühler
>Priority: Major
>
> The usage of scratch file buffers in COSStreams is quite sloppy. A never
> filled buffer is created in the beginning and existing buffers are discarded
> without being closed when a variant of {{createOutputStream}} is called.
> Furthermore it should be clarified if requesting an input stream without
> having created an output stream before is ok and if a returned input stream
> keeps valid after a new output stream is created (which is crucial for proper
> buffer-closing).
> This issue should resolve some of the shortcomings and document the expected
> or even required usage of COSStream.
--
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
