[jira] [Commented] (PDFBOX-5878) pdf form field text gets blurred after flattening
[
https://issues.apache.org/jira/browse/PDFBOX-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879888#comment-17879888
]
Maruan Sahyoun commented on PDFBOX-5878:
it's not weird per se it's only weird here as there are multiple occurences
within a fields appearance stream for the value and other stuff where there
should be only one. But we can look at changing that maybe for 4.0 to create
from scratch (which is more in line with what Adobe does but normally according
to the Spec onyl with some field settings which do not apply here).
> pdf form field text gets blurred after flattening
> -
>
> Key: PDFBOX-5878
> URL: https://issues.apache.org/jira/browse/PDFBOX-5878
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.28, 3.0.3 PDFBox
> Environment: Mac Ventura, java 18 PDFBox 3.0.3, Tomcat 9
> Linux; version: 5.15.0-105-generic, java 17, Tomcat 9.0.93
>Reporter: Joseph Jezerinac
>Priority: Major
> Labels: Appearance
> Attachments: Bildschirmfoto vom 2024-09-05 10-07-13.png,
> PDFBox5878-flattened.pdf, PDFBox5878-saved.pdf, beforeFlattening.pdf,
> flattened.pdf
>
>
> After flattening a pdf acro form, value of some fields get blurred
> {code:java}
> PDDocument pdDocument = Loader.loadPDF(inFile, "");
> pdDocument.setResourceCache(new DefaultResourceCache());
> try {
> boolean save = false;
> if (pdDocument.isEncrypted()) {
> pdDocument.setAllSecurityToBeRemoved(true);
> save = true;
> }
> final PDDocumentCatalog pdDocumentCatalog =
> pdDocument.getDocumentCatalog();
> if (pdDocumentCatalog != null) {
> final PDAcroForm pdForm = pdDocumentCatalog.getAcroForm();
> if (pdForm != null) {
> pdForm.flatten();
> save = true;
> }
> }
> if (save) {
> pdDocument.save(outFile);
> }
> }
> catch (Exception e) {}
> {code}
--
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] [Updated] (PDFBOX-5878) pdf form field text gets blurred after flattening
[
https://issues.apache.org/jira/browse/PDFBOX-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5878:
---
Labels: Appearance (was: )
> pdf form field text gets blurred after flattening
> -
>
> Key: PDFBOX-5878
> URL: https://issues.apache.org/jira/browse/PDFBOX-5878
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.28, 3.0.3 PDFBox
> Environment: Mac Ventura, java 18 PDFBox 3.0.3, Tomcat 9
> Linux; version: 5.15.0-105-generic, java 17, Tomcat 9.0.93
>Reporter: Joseph Jezerinac
>Priority: Major
> Labels: Appearance
> Attachments: Bildschirmfoto vom 2024-09-05 10-07-13.png,
> beforeFlattening.pdf, flattened.pdf
>
>
> After flattening a pdf acro form, value of some fields get blurred
> PDDocument pdDocument = Loader.loadPDF(inFile, "");
> pdDocument.setResourceCache(new DefaultResourceCache());
> try {
> boolean save = false;
> if (pdDocument.isEncrypted()) {
> pdDocument.setAllSecurityToBeRemoved(true);
> save = true;
> }
> final PDDocumentCatalog pdDocumentCatalog =
> pdDocument.getDocumentCatalog();
> if (pdDocumentCatalog != null) {
> final PDAcroForm pdForm = pdDocumentCatalog.getAcroForm();
> if (pdForm != null) {
> pdForm.flatten();
> save = true;
> }
> }
> if (save) {
> pdDocument.save(outFile);
> }
> }
> catch (Exception e) {}
--
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] [Resolved] (PDFBOX-5831) Radio button can't be set
[
https://issues.apache.org/jira/browse/PDFBOX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun resolved PDFBOX-5831.
Resolution: Fixed
> Radio button can't be set
> -
>
> Key: PDFBOX-5831
> URL: https://issues.apache.org/jira/browse/PDFBOX-5831
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Fix For: 2.0.33, 3.0.3 PDFBox, 4.0.0
>
> Attachments: AU_Erklaerung_final-lower.pdf,
> AU_Erklaerung_final-upper.pdf, AU_Erklaerung_final.pdf
>
>
> It is impossible to set the upper radio button with this code, the lower is
> set. With "2" also.
> {code:java}
> String filename = "/AU_Erklaerung_finalAB.pdf";
> PDDocument pdfDocument = Loader.loadPDF(new File(filename));
> PDAcroForm acroForm = pdfDocument.getDocumentCatalog().getAcroForm();
> acroForm.getField("Formular1[0].Seite1[0].TF_P[0].Optionsfeldliste[0]").setValue("1");
> pdfDocument.save(filename + System.currentTimeMillis() + ".pdf");
> {code}
> Attached: the original file from the user, plus two files where it was set
> with Adobe Reader.
> What really happens:
> The values from the /Opt entry are 1 and 2, the values at the dictionary
> level are 0 and 1. Our software somehow gets confused when 1 is used because
> it appears in both: when the value "1" is set, then PDButton.updateByOption()
> is called twice (!!!), once with value 1 and once with 2.
> The same effect happens with {{setValue(0)}} (integer parameter) if we cast
> the field to a PDRadioButton.
> I changed the PDF so that the /Opt entry has "A" and "B" instead of "1" and
> "2" and then it works. (However that can't be changed with Adobe Reader)
> The Adobe filled files have 0 and 1 as /V value, we set 1 and 2 as /V value.
--
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] [Commented] (PDFBOX-5831) Radio button can't be set
[
https://issues.apache.org/jira/browse/PDFBOX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870856#comment-17870856
]
Maruan Sahyoun commented on PDFBOX-5831:
adds in
[*1919669*|https://svn.apache.org/viewvc/pdfbox/trunk/pdfbox/src/main/?view=log]
and
[*1919668*|https://svn.apache.org/viewvc/pdfbox/branches/3.0/pdfbox/?view=log]
for 3.0 and trunk. Commit message not appearing here because of wrong
formatting of commit message
> Radio button can't be set
> -
>
> Key: PDFBOX-5831
> URL: https://issues.apache.org/jira/browse/PDFBOX-5831
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Fix For: 2.0.33, 3.0.3 PDFBox, 4.0.0
>
> Attachments: AU_Erklaerung_final-lower.pdf,
> AU_Erklaerung_final-upper.pdf, AU_Erklaerung_final.pdf
>
>
> It is impossible to set the upper radio button with this code, the lower is
> set. With "2" also.
> {code:java}
> String filename = "/AU_Erklaerung_finalAB.pdf";
> PDDocument pdfDocument = Loader.loadPDF(new File(filename));
> PDAcroForm acroForm = pdfDocument.getDocumentCatalog().getAcroForm();
> acroForm.getField("Formular1[0].Seite1[0].TF_P[0].Optionsfeldliste[0]").setValue("1");
> pdfDocument.save(filename + System.currentTimeMillis() + ".pdf");
> {code}
> Attached: the original file from the user, plus two files where it was set
> with Adobe Reader.
> What really happens:
> The values from the /Opt entry are 1 and 2, the values at the dictionary
> level are 0 and 1. Our software somehow gets confused when 1 is used because
> it appears in both: when the value "1" is set, then PDButton.updateByOption()
> is called twice (!!!), once with value 1 and once with 2.
> The same effect happens with {{setValue(0)}} (integer parameter) if we cast
> the field to a PDRadioButton.
> I changed the PDF so that the /Opt entry has "A" and "B" instead of "1" and
> "2" and then it works. (However that can't be changed with Adobe Reader)
> The Adobe filled files have 0 and 1 as /V value, we set 1 and 2 as /V value.
--
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] [Comment Edited] (PDFBOX-5831) Radio button can't be set
[
https://issues.apache.org/jira/browse/PDFBOX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870847#comment-17870847
]
Maruan Sahyoun edited comment on PDFBOX-5831 at 8/4/24 3:01 PM:
[~lehmi] forgot a hyphen in the commit message for 3.0 and trunk - shall I fix
that so that the commits appear here? Or not worth messing with the history?
was (Author: msahyoun):
[~lehmi] forgot a hyphen in the commit message for 2.0 and branch - shall I
fix that so that the commits appear here? Or not worth messing with the history?
> Radio button can't be set
> -
>
> Key: PDFBOX-5831
> URL: https://issues.apache.org/jira/browse/PDFBOX-5831
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Fix For: 2.0.33, 3.0.3 PDFBox, 4.0.0
>
> Attachments: AU_Erklaerung_final-lower.pdf,
> AU_Erklaerung_final-upper.pdf, AU_Erklaerung_final.pdf
>
>
> It is impossible to set the upper radio button with this code, the lower is
> set. With "2" also.
> {code:java}
> String filename = "/AU_Erklaerung_finalAB.pdf";
> PDDocument pdfDocument = Loader.loadPDF(new File(filename));
> PDAcroForm acroForm = pdfDocument.getDocumentCatalog().getAcroForm();
> acroForm.getField("Formular1[0].Seite1[0].TF_P[0].Optionsfeldliste[0]").setValue("1");
> pdfDocument.save(filename + System.currentTimeMillis() + ".pdf");
> {code}
> Attached: the original file from the user, plus two files where it was set
> with Adobe Reader.
> What really happens:
> The values from the /Opt entry are 1 and 2, the values at the dictionary
> level are 0 and 1. Our software somehow gets confused when 1 is used because
> it appears in both: when the value "1" is set, then PDButton.updateByOption()
> is called twice (!!!), once with value 1 and once with 2.
> The same effect happens with {{setValue(0)}} (integer parameter) if we cast
> the field to a PDRadioButton.
> I changed the PDF so that the /Opt entry has "A" and "B" instead of "1" and
> "2" and then it works. (However that can't be changed with Adobe Reader)
> The Adobe filled files have 0 and 1 as /V value, we set 1 and 2 as /V value.
--
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] [Commented] (PDFBOX-5831) Radio button can't be set
[
https://issues.apache.org/jira/browse/PDFBOX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870847#comment-17870847
]
Maruan Sahyoun commented on PDFBOX-5831:
[~lehmi] forgot a hyphen in the commit message for 2.0 and branch - shall I
fix that so that the commits appear here? Or not worth messing with the history?
> Radio button can't be set
> -
>
> Key: PDFBOX-5831
> URL: https://issues.apache.org/jira/browse/PDFBOX-5831
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Fix For: 2.0.33, 3.0.3 PDFBox, 4.0.0
>
> Attachments: AU_Erklaerung_final-lower.pdf,
> AU_Erklaerung_final-upper.pdf, AU_Erklaerung_final.pdf
>
>
> It is impossible to set the upper radio button with this code, the lower is
> set. With "2" also.
> {code:java}
> String filename = "/AU_Erklaerung_finalAB.pdf";
> PDDocument pdfDocument = Loader.loadPDF(new File(filename));
> PDAcroForm acroForm = pdfDocument.getDocumentCatalog().getAcroForm();
> acroForm.getField("Formular1[0].Seite1[0].TF_P[0].Optionsfeldliste[0]").setValue("1");
> pdfDocument.save(filename + System.currentTimeMillis() + ".pdf");
> {code}
> Attached: the original file from the user, plus two files where it was set
> with Adobe Reader.
> What really happens:
> The values from the /Opt entry are 1 and 2, the values at the dictionary
> level are 0 and 1. Our software somehow gets confused when 1 is used because
> it appears in both: when the value "1" is set, then PDButton.updateByOption()
> is called twice (!!!), once with value 1 and once with 2.
> The same effect happens with {{setValue(0)}} (integer parameter) if we cast
> the field to a PDRadioButton.
> I changed the PDF so that the /Opt entry has "A" and "B" instead of "1" and
> "2" and then it works. (However that can't be changed with Adobe Reader)
> The Adobe filled files have 0 and 1 as /V value, we set 1 and 2 as /V value.
--
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] [Updated] (PDFBOX-5831) Radio button can't be set
[
https://issues.apache.org/jira/browse/PDFBOX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5831:
---
Fix Version/s: 2.0.33
> Radio button can't be set
> -
>
> Key: PDFBOX-5831
> URL: https://issues.apache.org/jira/browse/PDFBOX-5831
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Fix For: 2.0.33, 3.0.3 PDFBox, 4.0.0
>
> Attachments: AU_Erklaerung_final-lower.pdf,
> AU_Erklaerung_final-upper.pdf, AU_Erklaerung_final.pdf
>
>
> It is impossible to set the upper radio button with this code, the lower is
> set. With "2" also.
> {code:java}
> String filename = "/AU_Erklaerung_finalAB.pdf";
> PDDocument pdfDocument = Loader.loadPDF(new File(filename));
> PDAcroForm acroForm = pdfDocument.getDocumentCatalog().getAcroForm();
> acroForm.getField("Formular1[0].Seite1[0].TF_P[0].Optionsfeldliste[0]").setValue("1");
> pdfDocument.save(filename + System.currentTimeMillis() + ".pdf");
> {code}
> Attached: the original file from the user, plus two files where it was set
> with Adobe Reader.
> What really happens:
> The values from the /Opt entry are 1 and 2, the values at the dictionary
> level are 0 and 1. Our software somehow gets confused when 1 is used because
> it appears in both: when the value "1" is set, then PDButton.updateByOption()
> is called twice (!!!), once with value 1 and once with 2.
> The same effect happens with {{setValue(0)}} (integer parameter) if we cast
> the field to a PDRadioButton.
> I changed the PDF so that the /Opt entry has "A" and "B" instead of "1" and
> "2" and then it works. (However that can't be changed with Adobe Reader)
> The Adobe filled files have 0 and 1 as /V value, we set 1 and 2 as /V value.
--
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] [Updated] (PDFBOX-5831) Radio button can't be set
[
https://issues.apache.org/jira/browse/PDFBOX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5831:
---
Fix Version/s: 3.0.3 PDFBox
4.0.0
> Radio button can't be set
> -
>
> Key: PDFBOX-5831
> URL: https://issues.apache.org/jira/browse/PDFBOX-5831
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Fix For: 3.0.3 PDFBox, 4.0.0
>
> Attachments: AU_Erklaerung_final-lower.pdf,
> AU_Erklaerung_final-upper.pdf, AU_Erklaerung_final.pdf
>
>
> It is impossible to set the upper radio button with this code, the lower is
> set. With "2" also.
> {code:java}
> String filename = "/AU_Erklaerung_finalAB.pdf";
> PDDocument pdfDocument = Loader.loadPDF(new File(filename));
> PDAcroForm acroForm = pdfDocument.getDocumentCatalog().getAcroForm();
> acroForm.getField("Formular1[0].Seite1[0].TF_P[0].Optionsfeldliste[0]").setValue("1");
> pdfDocument.save(filename + System.currentTimeMillis() + ".pdf");
> {code}
> Attached: the original file from the user, plus two files where it was set
> with Adobe Reader.
> What really happens:
> The values from the /Opt entry are 1 and 2, the values at the dictionary
> level are 0 and 1. Our software somehow gets confused when 1 is used because
> it appears in both: when the value "1" is set, then PDButton.updateByOption()
> is called twice (!!!), once with value 1 and once with 2.
> The same effect happens with {{setValue(0)}} (integer parameter) if we cast
> the field to a PDRadioButton.
> I changed the PDF so that the /Opt entry has "A" and "B" instead of "1" and
> "2" and then it works. (However that can't be changed with Adobe Reader)
> The Adobe filled files have 0 and 1 as /V value, we set 1 and 2 as /V value.
--
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] [Updated] (PDFBOX-5831) Radio button can't be set
[
https://issues.apache.org/jira/browse/PDFBOX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5831:
---
Labels: Appearance (was: )
> Radio button can't be set
> -
>
> Key: PDFBOX-5831
> URL: https://issues.apache.org/jira/browse/PDFBOX-5831
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Fix For: 3.0.3 PDFBox, 4.0.0
>
> Attachments: AU_Erklaerung_final-lower.pdf,
> AU_Erklaerung_final-upper.pdf, AU_Erklaerung_final.pdf
>
>
> It is impossible to set the upper radio button with this code, the lower is
> set. With "2" also.
> {code:java}
> String filename = "/AU_Erklaerung_finalAB.pdf";
> PDDocument pdfDocument = Loader.loadPDF(new File(filename));
> PDAcroForm acroForm = pdfDocument.getDocumentCatalog().getAcroForm();
> acroForm.getField("Formular1[0].Seite1[0].TF_P[0].Optionsfeldliste[0]").setValue("1");
> pdfDocument.save(filename + System.currentTimeMillis() + ".pdf");
> {code}
> Attached: the original file from the user, plus two files where it was set
> with Adobe Reader.
> What really happens:
> The values from the /Opt entry are 1 and 2, the values at the dictionary
> level are 0 and 1. Our software somehow gets confused when 1 is used because
> it appears in both: when the value "1" is set, then PDButton.updateByOption()
> is called twice (!!!), once with value 1 and once with 2.
> The same effect happens with {{setValue(0)}} (integer parameter) if we cast
> the field to a PDRadioButton.
> I changed the PDF so that the /Opt entry has "A" and "B" instead of "1" and
> "2" and then it works. (However that can't be changed with Adobe Reader)
> The Adobe filled files have 0 and 1 as /V value, we set 1 and 2 as /V value.
--
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] [Commented] (PDFBOX-5049) PlainText.Paragraph.getLines extremely slow on long lines
[ https://issues.apache.org/jira/browse/PDFBOX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869004#comment-17869004 ] Maruan Sahyoun commented on PDFBOX-5049: [~tilman] does it have to be on page 30? > PlainText.Paragraph.getLines extremely slow on long lines > - > > Key: PDFBOX-5049 > URL: https://issues.apache.org/jira/browse/PDFBOX-5049 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.21 >Reporter: Tilman Hausherr >Priority: Major > Attachments: GHOSTSCRIPT-690526-0.pdf, GHOSTSCRIPT-692591-0.pdf, > GHOSTSCRIPT-692591-2.pdf, PlainText.patch > > > The three attached files are very slow when constructing the appearance on > the field "gendate" (on the last page). That is a multiline field but with an > extremely long text. > It happens at "// single word does not fit into width". -- 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] [Commented] (PDFBOX-5848) Infinite loop processing PDF
[
https://issues.apache.org/jira/browse/PDFBOX-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862878#comment-17862878
]
Maruan Sahyoun commented on PDFBOX-5848:
It was also slow for me (approx 3 min) but was only looking at the infinite
loop question.
> Infinite loop processing PDF
>
>
> Key: PDFBOX-5848
> URL: https://issues.apache.org/jira/browse/PDFBOX-5848
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 3.0.2 PDFBox
>Reporter: Joan Fisbein
>Priority: Major
> Attachments: cbc0018b-5659-4ae3-9887-0e0a2d9a62a7.pdf,
> screenshot-1.png
>
>
> I use PDFBox to split hundreds of PDFs per day, generally, everything works
> flawlessly but I just received a PDF that generates an infinite loop when I
> try to split it.
>
> I used this Java code to reproduce it using PDFBox 3.0.2 (haven't tried other
> versions):
> {code:java}
> private static void splitPdf(File fileToSplit) {
> try (PDDocument document = Loader.loadPDF(fileToSplit)) {
> int documentPages = document.getNumberOfPages();
> Splitter splitter = new Splitter();
> List Pages = splitter.split(document);
> Iterator iterator = Pages.listIterator();
> while (iterator.hasNext()) {
> PDDocument pd = iterator.next();
> pd.save(fileToSplit.getName() + "-" + Pages.indexOf(pd) + ".pdf");
> pd.close();
> }
> } catch (IOException e) {
> throw new RuntimeException(e);
> }
> } {code}
> The PDF file is attached to the issue
--
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] [Commented] (PDFBOX-5848) Infinite loop processing PDF
[
https://issues.apache.org/jira/browse/PDFBOX-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862853#comment-17862853
]
Maruan Sahyoun commented on PDFBOX-5848:
tried with 3.0.3-SNAHSHOT and works for me using the command line split command:
{code}
java -jar pdfbox-app-3.0.3-SNAPSHOT.jar split -i
cbc0018b-5659-4ae3-9887-0e0a2d9a62a7.pdf
{code}
Can you try the same with the 3.0.2 version and of that doesn't work for you
with 3.0.3-SNAPSHOT?
> Infinite loop processing PDF
>
>
> Key: PDFBOX-5848
> URL: https://issues.apache.org/jira/browse/PDFBOX-5848
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 3.0.2 PDFBox
>Reporter: Joan Fisbein
>Priority: Major
> Attachments: cbc0018b-5659-4ae3-9887-0e0a2d9a62a7.pdf
>
>
> I use PDFBox to split hundreds of PDFs per day, generally, everything works
> flawlessly but I just received a PDF that generates an infinite loop when I
> try to split it.
>
> I used this Java code to reproduce it using PDFBox 3.0.2 (haven't tried other
> versions):
> {code:java}
> private static void splitPdf(File fileToSplit) {
> try (PDDocument document = Loader.loadPDF(fileToSplit)) {
> int documentPages = document.getNumberOfPages();
> Splitter splitter = new Splitter();
> List Pages = splitter.split(document);
> Iterator iterator = Pages.listIterator();
> while (iterator.hasNext()) {
> PDDocument pd = iterator.next();
> pd.save(fileToSplit.getName() + "-" + Pages.indexOf(pd) + ".pdf");
> pd.close();
> }
> } catch (IOException e) {
> throw new RuntimeException(e);
> }
> } {code}
> The PDF file is attached to the issue
--
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] [Commented] (PDFBOX-5835) DomXmpParser - IllegalArgumentException: prefix cannot be "null" when creating a QName
[
https://issues.apache.org/jira/browse/PDFBOX-5835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17854315#comment-17854315
]
Maruan Sahyoun commented on PDFBOX-5835:
I think the main problem is that from the naming DomXmpParser one would expect
that it parses all valid XMP but the lib is really targeted to parse PDF/A-1
XMP with a specific definition of what a valid PDF/A-1 XMP should look like.
There have been some revisions/clarifications done to PDF/A-1 XMP for which I
don't know if the lib has been revised to handle these.
> DomXmpParser - IllegalArgumentException: prefix cannot be "null" when
> creating a QName
> --
>
> Key: PDFBOX-5835
> URL: https://issues.apache.org/jira/browse/PDFBOX-5835
> Project: PDFBox
> Issue Type: Bug
> Components: XmpBox
>Affects Versions: 3.0.2 PDFBox
>Reporter: Oliver Schmidtmer
>Priority: Major
>
> I've got a PDF from, where parsing the metadata fails with an
> IllegalArgumentException
> {code:java}
> java.lang.IllegalArgumentException: prefix cannot be "null" when creating a
> QName
> at java.xml/javax.xml.namespace.QName.(QName.java:192)
> at org.apache.xmpbox.xml.DomHelper.getQName(DomHelper.java:99)
> at
> org.apache.xmpbox.xml.DomXmpParser.parseChildrenAsProperties(DomXmpParser.java:306)
> at
> org.apache.xmpbox.xml.DomXmpParser.parseDescriptionRoot(DomXmpParser.java:250)
> at org.apache.xmpbox.xml.DomXmpParser.parse(DomXmpParser.java:201)
> at org.apache.xmpbox.xml.DomXmpParser.parse(DomXmpParser.java:112)
> {code}
> This can be reproduced with a simple test, using the extracted metadata:
> {code:java}
> @Test
> void testDomXmpParser() throws XmpParsingException
> {
> // taken from file test-landscape2.pdf
> String xmpmeta = " standalone=\"no\"?>\n" +
> " id=\"W5M0MpCehiHzreSzNTczkc9d\"?> x:xmptk=\"FIS/xee\">\n" +
> " xmlns:rdf=\"http://www.w3.org/1999/02/22-rdf-syntax-ns#\";>\n" +
> " xmlns:pdfaid=\"http://www.aiim.org/pdfa/ns/id/\";>\n" +
> " 3\n" +
> " A\n" +
> " \n" +
> " xmlns:pdfaExtension=\"http://www.aiim.org/pdfa/ns/extension/\";
> xmlns:pdfaField=\"http://www.aiim.org/pdfa/ns/field#\";
> xmlns:pdfaProperty=\"http://www.aiim.org/pdfa/ns/property#\";
> xmlns:pdfaSchema=\"http://www.aiim.org/pdfa/ns/schema#\";
> xmlns:pdfaType=\"http://www.aiim.org/pdfa/ns/type#\"; rdf:about=\"\"/>\n" +
> " \n" +
> "xmlns=\"http://www.aiim.org/pdfa/ns/extension/\";>\n" +
> "\n" +
> " \n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/schema#\";>ZUGFeRD PDFA Extension
> Schema\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/schema#\";>urn:ferd:pdfa:CrossIndustryDocument:invoice:1p0#\n"
> +
> " xmlns=\"http://www.aiim.org/pdfa/ns/schema#\";>zf\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/schema#\";>\n" +
> " \n" +
> "\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>DocumentFileName\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Text\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>external\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>name of the embedded XML
> invoice file\n" +
> "\n" +
> "\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>DocumentType\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Text\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>external\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>INVOICE\n" +
> "\n" +
> "\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Version\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Text\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>external\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>The actual version of the
> ZUGFeRD data\n" +
> "\n" +
> "\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>ConformanceLevel\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Text\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property
[jira] [Commented] (PDFBOX-5835) DomXmpParser - IllegalArgumentException: prefix cannot be "null" when creating a QName
[
https://issues.apache.org/jira/browse/PDFBOX-5835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17854313#comment-17854313
]
Maruan Sahyoun commented on PDFBOX-5835:
the schemas being used in the document are parsed dependent on which element
type they are part of and handled in the inner class NamespaceFinder. That is
done by doing nsfinder.push of the Element being parsed and kept in an internal
stack. So if the code doesn't expect a schema included in the structure at that
location it's not part of the internal structure and reported as missing later
on when it's being used.
> DomXmpParser - IllegalArgumentException: prefix cannot be "null" when
> creating a QName
> --
>
> Key: PDFBOX-5835
> URL: https://issues.apache.org/jira/browse/PDFBOX-5835
> Project: PDFBox
> Issue Type: Bug
> Components: XmpBox
>Affects Versions: 3.0.2 PDFBox
>Reporter: Oliver Schmidtmer
>Priority: Major
>
> I've got a PDF from, where parsing the metadata fails with an
> IllegalArgumentException
> {code:java}
> java.lang.IllegalArgumentException: prefix cannot be "null" when creating a
> QName
> at java.xml/javax.xml.namespace.QName.(QName.java:192)
> at org.apache.xmpbox.xml.DomHelper.getQName(DomHelper.java:99)
> at
> org.apache.xmpbox.xml.DomXmpParser.parseChildrenAsProperties(DomXmpParser.java:306)
> at
> org.apache.xmpbox.xml.DomXmpParser.parseDescriptionRoot(DomXmpParser.java:250)
> at org.apache.xmpbox.xml.DomXmpParser.parse(DomXmpParser.java:201)
> at org.apache.xmpbox.xml.DomXmpParser.parse(DomXmpParser.java:112)
> {code}
> This can be reproduced with a simple test, using the extracted metadata:
> {code:java}
> @Test
> void testDomXmpParser() throws XmpParsingException
> {
> // taken from file test-landscape2.pdf
> String xmpmeta = " standalone=\"no\"?>\n" +
> " id=\"W5M0MpCehiHzreSzNTczkc9d\"?> x:xmptk=\"FIS/xee\">\n" +
> " xmlns:rdf=\"http://www.w3.org/1999/02/22-rdf-syntax-ns#\";>\n" +
> " xmlns:pdfaid=\"http://www.aiim.org/pdfa/ns/id/\";>\n" +
> " 3\n" +
> " A\n" +
> " \n" +
> " xmlns:pdfaExtension=\"http://www.aiim.org/pdfa/ns/extension/\";
> xmlns:pdfaField=\"http://www.aiim.org/pdfa/ns/field#\";
> xmlns:pdfaProperty=\"http://www.aiim.org/pdfa/ns/property#\";
> xmlns:pdfaSchema=\"http://www.aiim.org/pdfa/ns/schema#\";
> xmlns:pdfaType=\"http://www.aiim.org/pdfa/ns/type#\"; rdf:about=\"\"/>\n" +
> " \n" +
> "xmlns=\"http://www.aiim.org/pdfa/ns/extension/\";>\n" +
> "\n" +
> " \n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/schema#\";>ZUGFeRD PDFA Extension
> Schema\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/schema#\";>urn:ferd:pdfa:CrossIndustryDocument:invoice:1p0#\n"
> +
> " xmlns=\"http://www.aiim.org/pdfa/ns/schema#\";>zf\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/schema#\";>\n" +
> " \n" +
> "\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>DocumentFileName\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Text\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>external\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>name of the embedded XML
> invoice file\n" +
> "\n" +
> "\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>DocumentType\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Text\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>external\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>INVOICE\n" +
> "\n" +
> "\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Version\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Text\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>external\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>The actual version of the
> ZUGFeRD data\n" +
> "\n" +
> "\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>ConformanceLevel\n" +
> " xmlns=\"http://www.aiim.org/pdfa/ns/property#\";>Text\n" +
>
[jira] [Commented] (PDFBOX-5834) [PATCH] PDF split missing names from documentCatalog
[ https://issues.apache.org/jira/browse/PDFBOX-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852514#comment-17852514 ] Maruan Sahyoun commented on PDFBOX-5834: +1 for a callback. Maybe similar approach to the appearance handlers for annotation. We can provide default implementation(s) but the user can provide his own one if needed. Or a filter based approach. > [PATCH] PDF split missing names from documentCatalog > > > Key: PDFBOX-5834 > URL: https://issues.apache.org/jira/browse/PDFBOX-5834 > Project: PDFBox > Issue Type: Bug >Reporter: Simon Steiner >Priority: Major > Attachments: tmp.patch > > > java -jar app/target/pdfbox-app-2.0.32-SNAPSHOT.jar PDFSplit xxx.pdf > I would expect to see the names dict inside the documentCatalog which is used > to store pdf templates -- 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-5831) Radio button can't be set
[
https://issues.apache.org/jira/browse/PDFBOX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun reassigned PDFBOX-5831:
--
Assignee: Maruan Sahyoun
> Radio button can't be set
> -
>
> Key: PDFBOX-5831
> URL: https://issues.apache.org/jira/browse/PDFBOX-5831
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Attachments: AU_Erklaerung_final-lower.pdf,
> AU_Erklaerung_final-upper.pdf, AU_Erklaerung_final.pdf
>
>
> It is impossible to set the upper radio button with this code, the lower is
> set. With "2" also.
> {code:java}
> String filename = "/AU_Erklaerung_finalAB.pdf";
> PDDocument pdfDocument = Loader.loadPDF(new File(filename));
> PDAcroForm acroForm = pdfDocument.getDocumentCatalog().getAcroForm();
> acroForm.getField("Formular1[0].Seite1[0].TF_P[0].Optionsfeldliste[0]").setValue("1");
> pdfDocument.save(filename + System.currentTimeMillis() + ".pdf");
> {code}
> Attached: the original file from the user, plus two files where it was set
> with Adobe Reader.
> What really happens:
> The values from the /Opt entry are 1 and 2, the values at the dictionary
> level are 0 and 1. Our software somehow gets confused when 1 is used because
> it appears in both: when the value "1" is set, then PDButton.updateByOption()
> is called twice (!!!), once with value 1 and once with 2.
> The same effect happens with {{setValue(0)}} (integer parameter) if we cast
> the field to a PDRadioButton.
> I changed the PDF so that the /Opt entry has "A" and "B" instead of "1" and
> "2" and then it works. (However that can't be changed with Adobe Reader)
> The Adobe filled files have 0 and 1 as /V value, we set 1 and 2 as /V value.
--
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] [Commented] (PDFBOX-5831) Radio button can't be set
[
https://issues.apache.org/jira/browse/PDFBOX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850103#comment-17850103
]
Maruan Sahyoun commented on PDFBOX-5831:
assigned to me - can work on it this weekend
> Radio button can't be set
> -
>
> Key: PDFBOX-5831
> URL: https://issues.apache.org/jira/browse/PDFBOX-5831
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Attachments: AU_Erklaerung_final-lower.pdf,
> AU_Erklaerung_final-upper.pdf, AU_Erklaerung_final.pdf
>
>
> It is impossible to set the upper radio button with this code, the lower is
> set. With "2" also.
> {code:java}
> String filename = "/AU_Erklaerung_finalAB.pdf";
> PDDocument pdfDocument = Loader.loadPDF(new File(filename));
> PDAcroForm acroForm = pdfDocument.getDocumentCatalog().getAcroForm();
> acroForm.getField("Formular1[0].Seite1[0].TF_P[0].Optionsfeldliste[0]").setValue("1");
> pdfDocument.save(filename + System.currentTimeMillis() + ".pdf");
> {code}
> Attached: the original file from the user, plus two files where it was set
> with Adobe Reader.
> What really happens:
> The values from the /Opt entry are 1 and 2, the values at the dictionary
> level are 0 and 1. Our software somehow gets confused when 1 is used because
> it appears in both: when the value "1" is set, then PDButton.updateByOption()
> is called twice (!!!), once with value 1 and once with 2.
> The same effect happens with {{setValue(0)}} (integer parameter) if we cast
> the field to a PDRadioButton.
> I changed the PDF so that the /Opt entry has "A" and "B" instead of "1" and
> "2" and then it works. (However that can't be changed with Adobe Reader)
> The Adobe filled files have 0 and 1 as /V value, we set 1 and 2 as /V value.
--
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] [Comment Edited] (PDFBOX-5829) IOException: Error expected floating point numberactual='-12.-1'
[ https://issues.apache.org/jira/browse/PDFBOX-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849524#comment-17849524 ] Maruan Sahyoun edited comment on PDFBOX-5829 at 5/26/24 11:24 AM: -- Adding a listener is something that we discussed earlier before (without a conclusion) but Apache Tika, Tim was also interested in that. Apache FOP has something like that we could use as a starter and when we discussed that it seemed like a good starting point. was (Author: msahyoun): Adding a listener is something that we discussed earlier before (without a conclusion) but Apache Tika, Tim was also interested in that. > IOException: Error expected floating point numberactual='-12.-1' > > > Key: PDFBOX-5829 > URL: https://issues.apache.org/jira/browse/PDFBOX-5829 > Project: PDFBox > Issue Type: Bug > Components: Parsing >Affects Versions: 2.0.31, 3.0.2 PDFBox, 4.0.0 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Fix For: 2.0.32, 3.0.3 PDFBox, 4.0.0 > > Attachments: PDFBOX-5829.pdf > > -- 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] [Commented] (PDFBOX-5829) IOException: Error expected floating point numberactual='-12.-1'
[ https://issues.apache.org/jira/browse/PDFBOX-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849524#comment-17849524 ] Maruan Sahyoun commented on PDFBOX-5829: Adding a listener is something that we discussed earlier before (without a conclusion) but Apache Tika, Tim was also interested in that. > IOException: Error expected floating point numberactual='-12.-1' > > > Key: PDFBOX-5829 > URL: https://issues.apache.org/jira/browse/PDFBOX-5829 > Project: PDFBox > Issue Type: Bug > Components: Parsing >Affects Versions: 2.0.31, 3.0.2 PDFBox, 4.0.0 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Fix For: 2.0.32, 3.0.3 PDFBox, 4.0.0 > > Attachments: PDFBOX-5829.pdf > > -- 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] [Commented] (PDFBOX-5823) StringUtil.PATTERN_SPACE memory optmisation
[ https://issues.apache.org/jira/browse/PDFBOX-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848274#comment-17848274 ] Maruan Sahyoun commented on PDFBOX-5823: What about using Apache Commons Lang StringUtils.isBlank() or copy the code? > StringUtil.PATTERN_SPACE memory optmisation > --- > > Key: PDFBOX-5823 > URL: https://issues.apache.org/jira/browse/PDFBOX-5823 > Project: PDFBox > Issue Type: Improvement > Components: PDModel >Affects Versions: 3.0.3 PDFBox >Reporter: Jonathan Prates >Assignee: Andreas Lehmkühler >Priority: Minor > Fix For: 3.0.3 PDFBox, 4.0.0 > > Attachments: Main.java, Screenshot 2024-05-19 at 22.39.10.png, > Screenshot 2024-05-19 at 22.40.17.png > > > PDAbstractContentStream uses StringUtil.PATTERN_SPACE regexp to evaluate if a > word has a space in it > ([https://github.com/apache/pdfbox/blob/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/PDAbstractContentStream.java#L1624]) > For large documents ~800 pages and small string sequences (like a regular > word), it causes a memory overhead (see attached), due to the several extra > allocations. I've replaced the regexp for space and \t using word.contains, > and since it's a O ( 1 ) operation that does not require extra allocations, > memory used has been reduced. > What would be the implications of replacing this block for contains()? > Since \s is [ \t\n\x0B\f\r], I believe we have a simplified version to > allocate less memory. > -- 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] [Commented] (PDFBOX-5032) Refactor COSParser: separate the parsing of xref data
[ https://issues.apache.org/jira/browse/PDFBOX-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834943#comment-17834943 ] Maruan Sahyoun commented on PDFBOX-5032: What I had in mind is to have a) the number of revisions b) the list of objects per revision the same way we have today as combined information This would lay the ground to provide a list of changes done per revision similar to what Adobe provides. E.g. the "Signature is valid but after signing the folling changes were done ...". Or we could show the original document in PDFDebugger and in another panel the document with changes... Thought while you were working on the parsing it might be a good time to introduce the ground work. > 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 >Priority: Major > 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.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5032) Refactor COSParser: separate the parsing of xref data
[ https://issues.apache.org/jira/browse/PDFBOX-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834793#comment-17834793 ] Maruan Sahyoun commented on PDFBOX-5032: Can we make increments accessible? Would allow to show incremental changes done to a pdf and also help in debugging to check if an increments contains all necessary information > 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 >Priority: Major > 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.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5800) Handle edge cases for appearance of comb fields
[ https://issues.apache.org/jira/browse/PDFBOX-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-5800: --- Labels: Appearance (was: ) > Handle edge cases for appearance of comb fields > --- > > Key: PDFBOX-5800 > URL: https://issues.apache.org/jira/browse/PDFBOX-5800 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Reporter: Maruan Sahyoun >Priority: Minor > Labels: Appearance > > PDFBOX-5784 improved the handling of the appearance generation of comb > fields. Some edge cases remained which still need to be handled. -- 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] [Created] (PDFBOX-5800) Handle edge cases for appearance of comb fields
Maruan Sahyoun created PDFBOX-5800: -- Summary: Handle edge cases for appearance of comb fields Key: PDFBOX-5800 URL: https://issues.apache.org/jira/browse/PDFBOX-5800 Project: PDFBox Issue Type: Improvement Components: AcroForm Reporter: Maruan Sahyoun PDFBOX-5784 improved the handling of the appearance generation of comb fields. Some edge cases remained which still need to be handled. -- 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] [Resolved] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun resolved PDFBOX-5784.
Resolution: Fixed
Setting to resolved - edge cases will be dealt with in a different low pri
ticket
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Fix For: 2.0.32, 4.0.0, 3.0.3 PDFBox
>
> Attachments: PDFBOX5784-template.pdf, screenshot-1.png,
> with_dividing_by_2.pdf, without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834207#comment-17834207
]
Maruan Sahyoun commented on PDFBOX-5784:
It's always a bit tricky to fix these layout things as they are not documented.
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Attachments: PDFBOX5784-template.pdf, screenshot-1.png,
> with_dividing_by_2.pdf, without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Updated] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5784:
---
Fix Version/s: 2.0.32
4.0.0
3.0.3 PDFBox
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Fix For: 2.0.32, 4.0.0, 3.0.3 PDFBox
>
> Attachments: PDFBOX5784-template.pdf, screenshot-1.png,
> with_dividing_by_2.pdf, without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834182#comment-17834182
]
Maruan Sahyoun commented on PDFBOX-5784:
IMHO we are done here and can close the ticket. The edge cases can be dealt
with in another ticket. WDYT?
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Attachments: PDFBOX5784-template.pdf, screenshot-1.png,
> with_dividing_by_2.pdf, without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834181#comment-17834181
]
Maruan Sahyoun commented on PDFBOX-5784:
I've fixed the character positioning and also added some code to draw the
dividers for comb fields if the field has border set which hasn't been done
before. There are edge cases which I need to look into in more detail - field
is not high enough and comb is smaller than character width. for these the
expected result can be seen in the right column of fields of the form template
which has been filled using Acrobat.
What we can also see in comparing the content streams is that the positions of
the characters are slighty different to how Acrobat places these. This is also
true for most of the other form filling results. It looks like Adobe is taking
additional/other font metrics into account than we do.
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Attachments: PDFBOX5784-template.pdf, screenshot-1.png,
> with_dividing_by_2.pdf, without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5797) Kid Widget /DA is ignored in setDefaultAppearance() call
[
https://issues.apache.org/jira/browse/PDFBOX-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833569#comment-17833569
]
Maruan Sahyoun commented on PDFBOX-5797:
I'd need to look into that i.e. if it's correct that we treat that field as a
PDTerminalField where it should be a PDNonTerminalField. But a kid can be a
widget and field
> Kid Widget /DA is ignored in setDefaultAppearance() call
>
>
> Key: PDFBOX-5797
> URL: https://issues.apache.org/jira/browse/PDFBOX-5797
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.31, 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Attachments: seija.pdf
>
>
> See attached SO question, the field has one widget as kid with its own /DA
> entry. PDFBox only sets the field /DA entry but AppearanceGeneratorHelper
> will consider widget /DA entries too, which can result in the problem
> described in the SO question when only the field /DA entry gets changed.
> Test code:
> {code:java}
> PDDocument doc = Loader.loadPDF(new File("seija.pdf"));
> PDAcroForm acroForm = doc.getDocumentCatalog().getAcroForm();
> PDFont font = PDType0Font.load(doc, new
> FileInputStream("c:/windows/fonts/arial.ttf"), false);
> PDResources resources = acroForm.getDefaultResources();
> String fontName = resources.add(font).getName();
> PDVariableText field = (PDVariableText) acroForm.getField("main_text");
> field.setDefaultAppearance(field.getDefaultAppearance()
> .replaceAll("/\\w+", "/"
> + fontName));
> field.setValue("Ahoj světe");
> {code}
> Proposed solution in PDVariableText:
> {code:java}
> public void setDefaultAppearance(String daValue)
> {
> getCOSObject().setString(COSName.DA, daValue);
> if (getCOSObject().containsKey(COSName.KIDS))
> {
> for (PDAnnotationWidget widget : getWidgets())
> {
> COSDictionary widgetDict = widget.getCOSObject();
> if (widgetDict.containsKey(COSName.DA))
> {
> widgetDict.setString(COSName.DA, daValue);
> }
> }
> }
> }
> {code}
--
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] [Commented] (PDFBOX-5797) Kid Widget /DA is ignored in setDefaultAppearance() call
[
https://issues.apache.org/jira/browse/PDFBOX-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833559#comment-17833559
]
Maruan Sahyoun commented on PDFBOX-5797:
If I'm not mistaken a /DA entry is specific to a field dictionary and not a
widget dictionary (with both dictionaries optionally being merged into a single
dictionary). This means that the kid is not only a widget but also a field. The
proposed change would overwrite that maybe as intended in that case but maybe
not in others.
> Kid Widget /DA is ignored in setDefaultAppearance() call
>
>
> Key: PDFBOX-5797
> URL: https://issues.apache.org/jira/browse/PDFBOX-5797
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.31, 3.0.2 PDFBox
>Reporter: Tilman Hausherr
>Priority: Major
> Attachments: seija.pdf
>
>
> See attached SO question, the field has one widget as kid with its own /DA
> entry. PDFBox only sets the field /DA entry but AppearanceGeneratorHelper
> will consider widget /DA entries too, which can result in the problem
> described in the SO question when only the field /DA entry gets changed.
> Test code:
> {code:java}
> PDDocument doc = Loader.loadPDF(new File("seija.pdf"));
> PDAcroForm acroForm = doc.getDocumentCatalog().getAcroForm();
> PDFont font = PDType0Font.load(doc, new
> FileInputStream("c:/windows/fonts/arial.ttf"), false);
> PDResources resources = acroForm.getDefaultResources();
> String fontName = resources.add(font).getName();
> PDVariableText field = (PDVariableText) acroForm.getField("main_text");
> field.setDefaultAppearance(field.getDefaultAppearance()
> .replaceAll("/\\w+", "/"
> + fontName));
> field.setValue("Ahoj světe");
> {code}
> Proposed solution in PDVariableText:
> {code:java}
> public void setDefaultAppearance(String daValue)
> {
> getCOSObject().setString(COSName.DA, daValue);
> if (getCOSObject().containsKey(COSName.KIDS))
> {
> for (PDAnnotationWidget widget : getWidgets())
> {
> COSDictionary widgetDict = widget.getCOSObject();
> if (widgetDict.containsKey(COSName.DA))
> {
> widgetDict.setString(COSName.DA, daValue);
> }
> }
> }
> }
> {code}
--
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] [Commented] (PDFBOX-5796) PDFBox cannot extract vector text from a PDF
[ https://issues.apache.org/jira/browse/PDFBOX-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833461#comment-17833461 ] Maruan Sahyoun commented on PDFBOX-5796: Adobe's "Recognize Text" function indeed is doing OCR. So before that there is no text to extract as everything is graphics. > PDFBox cannot extract vector text from a PDF > > > Key: PDFBOX-5796 > URL: https://issues.apache.org/jira/browse/PDFBOX-5796 > Project: PDFBox > Issue Type: Bug > Components: Text extraction >Affects Versions: 2.0.28 > Environment: MacOS Sonoma 14.4.1 OpenJDK 11 (Can reproduce in other > environments too) >Reporter: Samved Chandrakant Divekar >Priority: Major > Attachments: Pre-flght_example.png, Sample_Working.png, > Sample_not_Working.png > > > PDFBox does not extract any text in the PDF which has all text encoded as > vector objects. > Unfortunately, I cannot attach the original document here(confidentiality) > but. have attached screenshot of pre-flight analysis of the a working file > and a non-working file using Adobe Acrobat pro. I can't copy paste the text > directly, however Adobe's "Recognize Text" function works on the document. I > verified that the whole page is not an image but definitley all text is > encoded as vector objects. I have attached an example of what pre-flight > analysis for a letter shows. -- 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] [Updated] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5784:
---
Attachment: PDFBOX5784-template.pdf
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Attachments: PDFBOX5784-template.pdf, screenshot-1.png,
> with_dividing_by_2.pdf, without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832195#comment-17832195
]
Maruan Sahyoun commented on PDFBOX-5784:
I have a working solution which works better as the initial offset of the first
character was calculated wrongly. All the other offsets, padding etc. match
what Adobe generates. Unfortunately the initial offset still doesn't match the
value to be compared with. I first need to generate more examples to understand
the calculation better and reengineer from that.
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Attachments: screenshot-1.png, with_dividing_by_2.pdf,
> without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5791) PDFBox CLI unable to read JPEG Image
[
https://issues.apache.org/jira/browse/PDFBOX-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17830600#comment-17830600
]
Maruan Sahyoun commented on PDFBOX-5791:
Use the command name directly. E.g.
{code}
java -cp "pdfbox-app-2.0.27.jar;lib/*" org.apache.pdfbox.tools.PDFToImage
og-color-doc.pdf
{code}
> PDFBox CLI unable to read JPEG Image
>
>
> Key: PDFBOX-5791
> URL: https://issues.apache.org/jira/browse/PDFBOX-5791
> Project: PDFBox
> Issue Type: Bug
>Reporter: Kabir Soneja
>Priority: Major
>
> Hi,
> I am trying to use pdfbox-app jar to execute PDFBox commands through CLI. I
> am using the CLI to convert PDF to Images. While doing so, for some documents
> PDFBox app jar is unable to read JPEG2000 Image.
> Commands I executed:
> {code:java}
> java -jar pdfbox-app-2.0.27.jar PDFToImage og-color-doc.pdf {code}
> I realized that PDFBox needs additional jars like jai-imageio-core and
> jai-imageio-jpeg2000 and I tried including these jars in the class path while
> executing the pdfbox command but I am still running into the same issue. Is
> there a specific way to ensure that pdfbox-app jar is able to reference the
> dependencies it needs when I am executing through the CLI?
> I have all jars present in lib directory and upon executing this command I am
> getting an error indicating:
> Error: Could not find or load main class org.apache.pdfbox.tools.PDFBox
> Caused by: java.lang.ClassNotFoundException: org.apache.pdfbox.tools.PDFBox
> Command:
> {code:java}
> java -cp "pdfbox-app-2.0.27.jar;lib/*" org.apache.pdfbox.tools.PDFBox
> PDFToImage og-color-doc.pdf {code}
> Can you please help me understand how to pass the specific jars/libraries
> that pdfbox-app needs while using the CLI?
--
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] [Commented] (PDFBOX-5786) NPE in COSWriter.getObjectKey() when saving broken file
[
https://issues.apache.org/jira/browse/PDFBOX-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827726#comment-17827726
]
Maruan Sahyoun commented on PDFBOX-5786:
I think the call to the renderer applies changes to the doc. Candidates are
appearance generation, AcroForm repairs ...
> NPE in COSWriter.getObjectKey() when saving broken file
> ---
>
> Key: PDFBOX-5786
> URL: https://issues.apache.org/jira/browse/PDFBOX-5786
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
>Affects Versions: 3.0.1 PDFBox, 4.0.0
>Reporter: Tilman Hausherr
>Assignee: Andreas Lehmkühler
>Priority: Major
>
> This happens with the broken file from PDFBOX-5782 when this code is run:
> {code:java}
> PDDocument doc = Loader.loadPDF(new File("PDFBOX-5782.pdf"));
> PDFRenderer r = new PDFRenderer(doc);
> r.renderImage(0);
> doc.save(OutputStream.nullOutputStream());
> {code}
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at java.base/java.util.Hashtable.put(Hashtable.java:475)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.getObjectKey(COSWriter.java:1082)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.writeReference(COSWriter.java:1391)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.visitFromDictionary(COSWriter.java:1231)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.writeDictionary(COSWriter.java:1179)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.visitFromDictionary(COSWriter.java:1226)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.writeDictionary(COSWriter.java:1179)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.visitFromDictionary(COSWriter.java:1226)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.visitFromStream(COSWriter.java:1413)
> at org.apache.pdfbox.cos.COSStream.accept(COSStream.java:381)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.doWriteObject(COSWriter.java:606)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.doWriteBodyCompressed(COSWriter.java:492)
> at
> org.apache.pdfbox.pdfwriter.COSWriter.visitFromDocument(COSWriter.java:1319)
> at org.apache.pdfbox.cos.COSDocument.accept(COSDocument.java:429)
> at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1593)
> at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1469)
> at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:1044)
> at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:968)
> {noformat}
> It does not happen if {{r.renderImage(0);}} is removed.
--
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] [Updated] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5784:
---
Labels: Appearance (was: )
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Labels: Appearance
> Attachments: screenshot-1.png, with_dividing_by_2.pdf,
> without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825947#comment-17825947
]
Maruan Sahyoun commented on PDFBOX-5784:
>From the screen shots one can see that neither with dividing by 2 nor without
>the characters are correctly placed centred within the comb boxes. It's also a
>good test to do the same filling with Adobe tooling to compare the output and
>generated appearance.
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Assignee: Maruan Sahyoun
>Priority: Major
> Attachments: screenshot-1.png, with_dividing_by_2.pdf,
> without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5784) AppearanceGeneratorHelper assumes fontscale 1000
[
https://issues.apache.org/jira/browse/PDFBOX-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825937#comment-17825937
]
Maruan Sahyoun commented on PDFBOX-5784:
Feel free to assign it to me - I have off next week and planned to do some
PDFBox programming.
> AppearanceGeneratorHelper assumes fontscale 1000
>
>
> Key: PDFBOX-5784
> URL: https://issues.apache.org/jira/browse/PDFBOX-5784
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Reporter: Tilman Hausherr
>Priority: Major
> Attachments: screenshot-1.png, with_dividing_by_2.pdf,
> without_dividing.pdf
>
>
> The user in the attached SO question noticed that the comb adjustment needed
> a factor of 2 to work correctly. A look at the font shows UnitsPerEm = 2048.
> Sample code:
> {code:java}
> doc.getDocumentCatalog().getAcroForm().getField("field1").setValue("");
> doc.getDocumentCatalog().getAcroForm().getField("field2").setValue("");
> {code}
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5731) org.apache.pdfbox.cos.COSName#nameMap There is a memory leak problem.
[ https://issues.apache.org/jira/browse/PDFBOX-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17802125#comment-17802125 ] Maruan Sahyoun commented on PDFBOX-5731: Although it's more effort and won't help for 2.x, 3.x wouldn't it be better to bind the COSNames to the PDDocument instance? > org.apache.pdfbox.cos.COSName#nameMap There is a memory leak problem. > - > > Key: PDFBOX-5731 > URL: https://issues.apache.org/jira/browse/PDFBOX-5731 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.30, 3.0.1 PDFBox >Reporter: liu >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 4.0.0 > > Attachments: COSName.java, > PDFBOX-5731_clear_out_unused_COSName_instances_automatically_PDFBOX2.patch, > PDFBox5731_clear_out_unused_COSName_instances_automatically_PDFBOX3.patch, > attempted_fix_for_PDFBOX-5731__clear_out_unused_COSName_instances_automatically.patch, > > attempted_fix_for_PDFBOX-5731__clear_out_unused_COSName_instances_automatically_2.patch, > > attempted_fix_for_PDFBOX-5731__clear_out_unused_COSName_instances_automatically_using_cleaner.patch, > image-2023-12-08-16-02-12-293.png, image-2023-12-13-17-04-22-073.png, > image-2023-12-14-18-10-14-278.png, screenshot-1.png, screenshot-2.png, > screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png, > screenshot-8.png > > > !image-2023-12-08-16-02-12-293.png! > !screenshot-1.png! -- 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] [Commented] (PDFBOX-5736) Vertical cut off in AcroForm text fields
[
https://issues.apache.org/jira/browse/PDFBOX-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17796827#comment-17796827
]
Maruan Sahyoun commented on PDFBOX-5736:
Looking at what Acrobat calculates we should get closer to a value of 8.931 for
the font size
I've quickly looked at some options to compare using the current implementation
as well as some other characteristics available. Some are getting closer but we
are at least still around a little more than 1pt off. Will need some further
investigation. This would then also need to be tested with other fonts.
Current sample values are leaving off the various options how I got them:
{code}
14.603616
6.8942876
9.952606
13.358778
{code}
so there is a wide range. Will look at the font file to compare with the PDF
embedded info.
> Vertical cut off in AcroForm text fields
>
>
> Key: PDFBOX-5736
> URL: https://issues.apache.org/jira/browse/PDFBOX-5736
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm
>Affects Versions: 2.0.30
>Reporter: Maruan Sahyoun
>Priority: Minor
> Labels: appearance
> Attachments: unflattened-acrobat.pdf, unflattened.pdf
>
>
> From a question posted on stack overflow:
> https://stackoverflow.com/questions/77558220/apache-pdfbox-gray-faint-underscores-2-0-26
> I'm wondering if this is a bug or a feature / misunderstanding, that an
> autosize acroform text field may cut off glyphs vertically in some cases?
--
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] [Commented] (PDFBOX-5736) Vertical cut off in AcroForm text fields
[ https://issues.apache.org/jira/browse/PDFBOX-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17796750#comment-17796750 ] Maruan Sahyoun commented on PDFBOX-5736: added form as agreed on https://stackoverflow.com/questions/77558220/apache-pdfbox-gray-faint-underscores-2-0-26?noredirect=1#comment136902566_77558220 > Vertical cut off in AcroForm text fields > > > Key: PDFBOX-5736 > URL: https://issues.apache.org/jira/browse/PDFBOX-5736 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.30 >Reporter: Maruan Sahyoun >Priority: Minor > Labels: appearance > Attachments: unflattened-acrobat.pdf, unflattened.pdf > > > From a question posted on stack overflow: > https://stackoverflow.com/questions/77558220/apache-pdfbox-gray-faint-underscores-2-0-26 > I'm wondering if this is a bug or a feature / misunderstanding, that an > autosize acroform text field may cut off glyphs vertically in some cases? -- 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] [Updated] (PDFBOX-5736) Vertical cut off in AcroForm text fields
[ https://issues.apache.org/jira/browse/PDFBOX-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-5736: --- Attachment: unflattened-acrobat.pdf > Vertical cut off in AcroForm text fields > > > Key: PDFBOX-5736 > URL: https://issues.apache.org/jira/browse/PDFBOX-5736 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.30 >Reporter: Maruan Sahyoun >Priority: Minor > Labels: appearance > Attachments: unflattened-acrobat.pdf, unflattened.pdf > > > From a question posted on stack overflow: > https://stackoverflow.com/questions/77558220/apache-pdfbox-gray-faint-underscores-2-0-26 > I'm wondering if this is a bug or a feature / misunderstanding, that an > autosize acroform text field may cut off glyphs vertically in some cases? -- 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] [Updated] (PDFBOX-5736) Vertical cut off in AcroForm text fields
[ https://issues.apache.org/jira/browse/PDFBOX-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-5736: --- Attachment: unflattened.pdf > Vertical cut off in AcroForm text fields > > > Key: PDFBOX-5736 > URL: https://issues.apache.org/jira/browse/PDFBOX-5736 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.30 >Reporter: Maruan Sahyoun >Priority: Minor > Labels: appearance > Attachments: unflattened.pdf > > > From a question posted on stack overflow: > https://stackoverflow.com/questions/77558220/apache-pdfbox-gray-faint-underscores-2-0-26 > I'm wondering if this is a bug or a feature / misunderstanding, that an > autosize acroform text field may cut off glyphs vertically in some cases? -- 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] [Commented] (PDFBOX-5731) org.apache.pdfbox.cos.COSName#nameMap There is a memory leak problem.
[
https://issues.apache.org/jira/browse/PDFBOX-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17796219#comment-17796219
]
Maruan Sahyoun commented on PDFBOX-5731:
{quote}
Last but not least, the radical solution would be to put away COSName
completely and just use String instead - it would solve all caching problems at
once, but I doubt this would get support from the maintainers.
{quote}
Indeed - COSName represents a PDF type and as such should exist.
> org.apache.pdfbox.cos.COSName#nameMap There is a memory leak problem.
> -
>
> Key: PDFBOX-5731
> URL: https://issues.apache.org/jira/browse/PDFBOX-5731
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 2.0.30, 3.0.1 PDFBox
>Reporter: liu
>Priority: Major
> Attachments:
> attempted_fix_for_PDFBOX-5731__clear_out_unused_COSName_instances_automatically.patch,
> image-2023-12-08-16-02-12-293.png, image-2023-12-13-17-04-22-073.png,
> screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png,
> screenshot-5.png
>
>
> !image-2023-12-08-16-02-12-293.png!
> !screenshot-1.png!
--
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] [Commented] (PDFBOX-5736) Vertical cut off in AcroForm text fields
[
https://issues.apache.org/jira/browse/PDFBOX-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17796118#comment-17796118
]
Maruan Sahyoun commented on PDFBOX-5736:
Appearance generated by PDFBox:
{code}
/Tx BMC
q
1 1 531.8637 12.5 re
W
n
BT
/Cour 14.6036 Tf
/DeviceRGB cs
0 0 0 sc
2 3.1464 Td
() Tj
ET
Q
EMC
{code}
Appearance generated by Acrobat
{code}
/Tx BMC
q
1 1 531.8637 12.5 re
W
n
BT
/Cour 8.931 Tf
0 g
2 4.2849 Td
() Tj
ET
Q
EMC
{code}
BBox also differ. This is likely related to getting the information from the
font (we know that Adobe uses more criteria from the font when doing the layout
i.e. our "layout engine" is much simpler)
> Vertical cut off in AcroForm text fields
>
>
> Key: PDFBOX-5736
> URL: https://issues.apache.org/jira/browse/PDFBOX-5736
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.30
>Reporter: Maruan Sahyoun
>Priority: Minor
> Labels: appearance
>
> From a question posted on stack overflow:
> https://stackoverflow.com/questions/77558220/apache-pdfbox-gray-faint-underscores-2-0-26
> I'm wondering if this is a bug or a feature / misunderstanding, that an
> autosize acroform text field may cut off glyphs vertically in some cases?
--
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] [Updated] (PDFBOX-5736) Vertical cut off in AcroForm text fields
[ https://issues.apache.org/jira/browse/PDFBOX-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-5736: --- Issue Type: Improvement (was: Bug) > Vertical cut off in AcroForm text fields > > > Key: PDFBOX-5736 > URL: https://issues.apache.org/jira/browse/PDFBOX-5736 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.30 >Reporter: Maruan Sahyoun >Priority: Minor > Labels: appearance > > From a question posted on stack overflow: > https://stackoverflow.com/questions/77558220/apache-pdfbox-gray-faint-underscores-2-0-26 > I'm wondering if this is a bug or a feature / misunderstanding, that an > autosize acroform text field may cut off glyphs vertically in some cases? -- 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] [Created] (PDFBOX-5736) Vertical cut off in AcroForm text fields
Maruan Sahyoun created PDFBOX-5736: -- Summary: Vertical cut off in AcroForm text fields Key: PDFBOX-5736 URL: https://issues.apache.org/jira/browse/PDFBOX-5736 Project: PDFBox Issue Type: Bug Components: AcroForm Affects Versions: 2.0.30 Reporter: Maruan Sahyoun >From a question posted on stack overflow: https://stackoverflow.com/questions/77558220/apache-pdfbox-gray-faint-underscores-2-0-26 I'm wondering if this is a bug or a feature / misunderstanding, that an autosize acroform text field may cut off glyphs vertically in some cases? -- 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] [Resolved] (PDFBOX-5735) Set the default value for PDNonTerminalField
[
https://issues.apache.org/jira/browse/PDFBOX-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun resolved PDFBOX-5735.
Resolution: Fixed
fixed - thank you for the report
> Set the default value for PDNonTerminalField
>
>
> Key: PDFBOX-5735
> URL: https://issues.apache.org/jira/browse/PDFBOX-5735
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.30, 3.0.1 PDFBox
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 2.0.31, 3.0.2 PDFBox, 4.0.0
>
>
> From the mailing list:
> {quote}
> Hi there!
> I was glancing through the code to PDFBox 3.0.1 to better grok PDF form
> fields/widgets and the hierarchical way they are organized and I ran
> across something that might be a bug in the code.
> Or... it might just be my lack of understanding of how PDF default
> values work in non-terminal field objects. At the very least I found it
> surprising and different from the code in other types of PDField
> subclasses. So I decided to bring it up here on the dev mailing list.
> In the PDNonTerminalField.java file, the setDefaultValue() method logic
> looks like this [1]:
> getCOSObject().setItem(COSName.V, value);
> It appears to set the value of the COSName.V item... while the
> getDefaultValue() method in the class (and the setDefaultValue() methods
> in other PDField subclasses that I checked) use the COSName.DV value as
> expected.
> Is this a bug, or is this intentional?
> Thank you for your time,
> - Dwayne
> {quote}
>
--
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] [Updated] (PDFBOX-5735) Set the default value for PDNonTerminalField
[
https://issues.apache.org/jira/browse/PDFBOX-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5735:
---
Fix Version/s: 2.0.31
3.0.2 PDFBox
4.0.0
> Set the default value for PDNonTerminalField
>
>
> Key: PDFBOX-5735
> URL: https://issues.apache.org/jira/browse/PDFBOX-5735
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.30, 3.0.1 PDFBox
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 2.0.31, 3.0.2 PDFBox, 4.0.0
>
>
> From the mailing list:
> {quote}
> Hi there!
> I was glancing through the code to PDFBox 3.0.1 to better grok PDF form
> fields/widgets and the hierarchical way they are organized and I ran
> across something that might be a bug in the code.
> Or... it might just be my lack of understanding of how PDF default
> values work in non-terminal field objects. At the very least I found it
> surprising and different from the code in other types of PDField
> subclasses. So I decided to bring it up here on the dev mailing list.
> In the PDNonTerminalField.java file, the setDefaultValue() method logic
> looks like this [1]:
> getCOSObject().setItem(COSName.V, value);
> It appears to set the value of the COSName.V item... while the
> getDefaultValue() method in the class (and the setDefaultValue() methods
> in other PDField subclasses that I checked) use the COSName.DV value as
> expected.
> Is this a bug, or is this intentional?
> Thank you for your time,
> - Dwayne
> {quote}
>
--
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-5735) Set the default value for PDNonTerminalField
[
https://issues.apache.org/jira/browse/PDFBOX-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun reassigned PDFBOX-5735:
--
Assignee: Maruan Sahyoun
> Set the default value for PDNonTerminalField
>
>
> Key: PDFBOX-5735
> URL: https://issues.apache.org/jira/browse/PDFBOX-5735
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.30, 3.0.1 PDFBox
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
>
> From the mailing list:
> {quote}
> Hi there!
> I was glancing through the code to PDFBox 3.0.1 to better grok PDF form
> fields/widgets and the hierarchical way they are organized and I ran
> across something that might be a bug in the code.
> Or... it might just be my lack of understanding of how PDF default
> values work in non-terminal field objects. At the very least I found it
> surprising and different from the code in other types of PDField
> subclasses. So I decided to bring it up here on the dev mailing list.
> In the PDNonTerminalField.java file, the setDefaultValue() method logic
> looks like this [1]:
> getCOSObject().setItem(COSName.V, value);
> It appears to set the value of the COSName.V item... while the
> getDefaultValue() method in the class (and the setDefaultValue() methods
> in other PDField subclasses that I checked) use the COSName.DV value as
> expected.
> Is this a bug, or is this intentional?
> Thank you for your time,
> - Dwayne
> {quote}
>
--
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] [Updated] (PDFBOX-5735) Set the default value for PDNonTerminalField
[
https://issues.apache.org/jira/browse/PDFBOX-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5735:
---
Component/s: AcroForm
> Set the default value for PDNonTerminalField
>
>
> Key: PDFBOX-5735
> URL: https://issues.apache.org/jira/browse/PDFBOX-5735
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.30, 3.0.1 PDFBox
>Reporter: Maruan Sahyoun
>Priority: Minor
>
> From the mailing list:
> {quote}
> Hi there!
> I was glancing through the code to PDFBox 3.0.1 to better grok PDF form
> fields/widgets and the hierarchical way they are organized and I ran
> across something that might be a bug in the code.
> Or... it might just be my lack of understanding of how PDF default
> values work in non-terminal field objects. At the very least I found it
> surprising and different from the code in other types of PDField
> subclasses. So I decided to bring it up here on the dev mailing list.
> In the PDNonTerminalField.java file, the setDefaultValue() method logic
> looks like this [1]:
> getCOSObject().setItem(COSName.V, value);
> It appears to set the value of the COSName.V item... while the
> getDefaultValue() method in the class (and the setDefaultValue() methods
> in other PDField subclasses that I checked) use the COSName.DV value as
> expected.
> Is this a bug, or is this intentional?
> Thank you for your time,
> - Dwayne
> {quote}
>
--
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] [Updated] (PDFBOX-5735) Set the default value for PDNonTerminalField
[
https://issues.apache.org/jira/browse/PDFBOX-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5735:
---
Affects Version/s: 3.0.1 PDFBox
2.0.30
> Set the default value for PDNonTerminalField
>
>
> Key: PDFBOX-5735
> URL: https://issues.apache.org/jira/browse/PDFBOX-5735
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 2.0.30, 3.0.1 PDFBox
>Reporter: Maruan Sahyoun
>Priority: Minor
>
> From the mailing list:
> {quote}
> Hi there!
> I was glancing through the code to PDFBox 3.0.1 to better grok PDF form
> fields/widgets and the hierarchical way they are organized and I ran
> across something that might be a bug in the code.
> Or... it might just be my lack of understanding of how PDF default
> values work in non-terminal field objects. At the very least I found it
> surprising and different from the code in other types of PDField
> subclasses. So I decided to bring it up here on the dev mailing list.
> In the PDNonTerminalField.java file, the setDefaultValue() method logic
> looks like this [1]:
> getCOSObject().setItem(COSName.V, value);
> It appears to set the value of the COSName.V item... while the
> getDefaultValue() method in the class (and the setDefaultValue() methods
> in other PDField subclasses that I checked) use the COSName.DV value as
> expected.
> Is this a bug, or is this intentional?
> Thank you for your time,
> - Dwayne
> {quote}
>
--
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] [Created] (PDFBOX-5735) Set the default value for PDNonTerminalField
Maruan Sahyoun created PDFBOX-5735:
--
Summary: Set the default value for PDNonTerminalField
Key: PDFBOX-5735
URL: https://issues.apache.org/jira/browse/PDFBOX-5735
Project: PDFBox
Issue Type: Bug
Reporter: Maruan Sahyoun
>From the mailing list:
{quote}
Hi there!
I was glancing through the code to PDFBox 3.0.1 to better grok PDF form
fields/widgets and the hierarchical way they are organized and I ran
across something that might be a bug in the code.
Or... it might just be my lack of understanding of how PDF default
values work in non-terminal field objects. At the very least I found it
surprising and different from the code in other types of PDField
subclasses. So I decided to bring it up here on the dev mailing list.
In the PDNonTerminalField.java file, the setDefaultValue() method logic
looks like this [1]:
getCOSObject().setItem(COSName.V, value);
It appears to set the value of the COSName.V item... while the
getDefaultValue() method in the class (and the setDefaultValue() methods
in other PDField subclasses that I checked) use the COSName.DV value as
expected.
Is this a bug, or is this intentional?
Thank you for your time,
- Dwayne
{quote}
--
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] [Commented] (PDFBOX-5695) Improve PDFBox Logging
[
https://issues.apache.org/jira/browse/PDFBOX-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793161#comment-17793161
]
Maruan Sahyoun commented on PDFBOX-5695:
At the end of the day the question is if the apps are used inside OSGI
containers which we don't know. If we are no longer providing these as OSGI
bundles they can not be readily used inside OSGI runtimes. I'd rather keep them
as OSGI packages just for the reason of being compatible if possible.
> Improve PDFBox Logging
> --
>
> Key: PDFBOX-5695
> URL: https://issues.apache.org/jira/browse/PDFBOX-5695
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 4.0.0
>Reporter: Axel Howind
>Assignee: Andreas Lehmkühler
>Priority: Major
> Labels: logging, patch
> Attachments:
> Fixed_DebugLogAppender_not_being_initialised_and_runtime_exceptions_in_LogDialog.patch,
> Optimize_debug_logging_across_multiple_files.patch,
> add_logging_imports_to_benchmark_classes.patch,
> add_missing_version_for_log4j-core.patch,
> fix_log_statement_with_wrong_parameter_count.patch,
> image-2023-11-25-16-22-45-143.png,
> replace_commons-logging_by_log4j_(benchmark).patch,
> replace_commons-logging_with_log4j.patch,
> replace_commons-logging_with_log4j2_(cleanup_POM_files).patch,
> replace_commons-logging_with_log4j_(examples).patch,
> replace_commons-logging_with_log4j_(pdfbox).patch,
> replace_commons-logging_with_log4j_(pdfbox-debugger).patch,
> replace_commons-logging_with_log4j_(pdfbox-io).patch,
> replace_commons-logging_with_log4j_(pdfbox-tools).patch,
> replace_commons-logging_with_log4j_(xmpbox).patch,
> update_log4j_to_2_21_1.patch, update_log4j_to_2_22_0.patch,
> use_Property_for_log4j_version_replace_commons_logging_by_log4j-api_(fontbox).patch
>
>
> I know this has been an issue before
> (https://issues.apache.org/jira/browse/PDFBOX-693), but since then a lot of
> time has passed. I propose to switch Logging to either SLF4J (my preference)
> or Log4J.
> Why? Currently, PDFBox uses commons logging. That library seems not to be
> actively maintained anymore, the last release was in 2014 with the comment
> „the main purpose of the 1.2 release is to drop support for Java 1.1“. PDFBox
> 4 requires at least Java 11. The Java language has evolved a lot over the
> last few years, and so have to logging frameworks.
> *Maintainabilty and Performance*
> The main point that speaks against commons logging IMHO is that you have to
> make compromises between readability and performance. Let’s look at an
> example (taken from COSParser.java):
>
> {code:java}
> if (offsetOrObjstmObNr != null)
> {
> LOG.debug("Set missing offset " + offsetOrObjstmObNr + " for object " +
> objKey);
> document.getXrefTable().put(objKey, offsetOrObjstmObNr);
> }
> {code}
> Each time the if-statement's body is entered, the logging message is
> constructed. This involves:
> - converting offsetOrObjstmObNr to a String
> - converting objKey to a String which in turn does two more conversions of
> integer and long values to a String, creates a new String by joining results
> of former conversions
> - creating a new String consisting of the results of the both operations
> above and some static text
> A lot of temporary objects are created and all of this happens regardless of
> whether logging is necessary or not.
> Both SLF4J and Log4J (and even JUL logging) support a message format syntax
> where arguments to logging calls are only evaluated when needed:
>
> {code:java}
> if (offsetOrObjstmObNr != null)
> {
> LOG.debug("Set missing offset {} for object {}", offsetOrObjstmObNr,
> objKey);
> document.getXrefTable().put(objKey, offsetOrObjstmObNr);
> }
> {code}
> Using common s logging, you can guard the logging statement:
>
> {code:java}
> if (offsetOrObjstmObNr != null)
> {
> if (LOG.isDebugEnabled())
> {
> LOG.debug("Set missing offset " + offsetOrObjstmObNr + " for object "
> + objKey);
> }
> document.getXrefTable().put(objKey, offsetOrObjstmObNr);
> }
> {code}
> This works, but makes the code less readable and harder to maintain because
> the level has to be changed in two places instead of one.
> *Flexibility*
> Another thing is that both SLF4J and Log4J offer you a facade that you can
> bridge to nearly every logging implementation in widespread use nowadays
> whereas commons logging is a full logging implementation that most of us do
> not need (there are ways to make commons logging work with other backends,
> but they are more of a workaround than a clean solution).
> *JPMS support*
> And of course, both SLF4J and Log4J offer first class support for the module
> system.
> So what are the PDFBox maintainer's thoughts on this? I think PDFBox 4 offers
> an opportunity
[jira] [Commented] (PDFBOX-5720) Checked state of PDCheckbox
[
https://issues.apache.org/jira/browse/PDFBOX-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790144#comment-17790144
]
Maruan Sahyoun commented on PDFBOX-5720:
small unit test
{code:java}
@Test
void testCheckedState() throws IOException, URISyntaxException
{
String sourceUrl =
"https://issues.apache.org/jira/secure/attachment/13064713/ticket.pdf";;
try (PDDocument testPdf = Loader.loadPDF(
RandomAccessReadBuffer.createBufferFromStream(new
URI(sourceUrl).toURL().openStream(
{
PDDocumentCatalog catalog = testPdf.getDocumentCatalog();
PDAcroForm acroForm = catalog.getAcroForm();
PDCheckBox checkBox = (PDCheckBox) acroForm.getField("A");
assertTrue(checkBox.isChecked());
}
}
{code}
> Checked state of PDCheckbox
> ---
>
> Key: PDFBOX-5720
> URL: https://issues.apache.org/jira/browse/PDFBOX-5720
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.0 PDFBox
>Reporter: Michael Bädorf
>Priority: Major
> Attachments: ticket.pdf
>
>
> Before v3.0.0 is was possible to get the selected state simply by using the
> isChecked() function. After updating to v.3.0.0 the function always returns
> false with the same input PDF that works well til v2.0.30.
> There are no migration advices so I think this is a bug.
> This is the code I use for filtering selected checkboxes. but now always
> returns an empty list (in contrast to v2.0.30)
> {{{color:#80}private {color}List
> filterCheckedCheckboxes(List fields) {}}
> {{ {color:#80}return {color}filterByType(fields,
> PDCheckBox.{color:#80}class{color})}}
> {{ .stream()}}
> {{ .filter(PDCheckBox::isChecked)}}
> {{ .map(PDField.{color:#80}class{color}::cast)}}
> {{ .toList();}}
> }
>
> I can also find no test for PDCheckBox.isChecked()
--
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] [Commented] (PDFBOX-5720) Checked state of PDCheckbox
[
https://issues.apache.org/jira/browse/PDFBOX-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790141#comment-17790141
]
Maruan Sahyoun commented on PDFBOX-5720:
Could you try with the current 3.0.1-SNAPSHOT? Works for me.
> Checked state of PDCheckbox
> ---
>
> Key: PDFBOX-5720
> URL: https://issues.apache.org/jira/browse/PDFBOX-5720
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.0 PDFBox
>Reporter: Michael Bädorf
>Priority: Major
> Attachments: ticket.pdf
>
>
> Before v3.0.0 is was possible to get the selected state simply by using the
> isChecked() function. After updating to v.3.0.0 the function always returns
> false with the same input PDF that works well til v2.0.30.
> There are no migration advices so I think this is a bug.
> This is the code I use for filtering selected checkboxes. but now always
> returns an empty list (in contrast to v2.0.30)
> {{{color:#80}private {color}List
> filterCheckedCheckboxes(List fields) {}}
> {{ {color:#80}return {color}filterByType(fields,
> PDCheckBox.{color:#80}class{color})}}
> {{ .stream()}}
> {{ .filter(PDCheckBox::isChecked)}}
> {{ .map(PDField.{color:#80}class{color}::cast)}}
> {{ .toList();}}
> }
>
> I can also find no test for PDCheckBox.isChecked()
--
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] [Updated] (PDFBOX-5720) Checked state of PDCheckbox
[
https://issues.apache.org/jira/browse/PDFBOX-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5720:
---
Component/s: AcroForm
(was: PDModel)
> Checked state of PDCheckbox
> ---
>
> Key: PDFBOX-5720
> URL: https://issues.apache.org/jira/browse/PDFBOX-5720
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.0 PDFBox
>Reporter: Michael Bädorf
>Priority: Major
>
> Before v3.0.0 is was possible to get the selected state simply by using the
> isChecked() function. After updating to v.3.0.0 the function always returns
> false with the same input PDF that works well til v2.0.30.
> There are no migration advices so I think this is a bug.
> This is the code I use for filtering selected checkboxes. but now always
> returns an empty list (in contrast to v2.0.30)
> {{{color:#80}private {color}List
> filterCheckedCheckboxes(List fields) {}}
> {{ {color:#80}return {color}filterByType(fields,
> PDCheckBox.{color:#80}class{color})}}
> {{ .stream()}}
> {{ .filter(PDCheckBox::isChecked)}}
> {{ .map(PDField.{color:#80}class{color}::cast)}}
> {{ .toList();}}
> }
--
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] [Commented] (PDFBOX-5720) Checked state of PDCheckbox
[
https://issues.apache.org/jira/browse/PDFBOX-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790071#comment-17790071
]
Maruan Sahyoun commented on PDFBOX-5720:
Can you attach the PDF in question and the name of the field for which you'd
like to get the state?
BR
Maruan
> Checked state of PDCheckbox
> ---
>
> Key: PDFBOX-5720
> URL: https://issues.apache.org/jira/browse/PDFBOX-5720
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 3.0.0 PDFBox
>Reporter: Michael Bädorf
>Priority: Major
>
> Before v3.0.0 is was possible to get the selected state simply by using the
> isChecked() function. After updating to v.3.0.0 the function always returns
> false with the same input PDF that works well til v2.0.30.
> There are no migration advices so I think this is a bug.
> This is the code I use for filtering selected checkboxes. but now always
> returns an empty list (in contrast to v2.0.30)
> {{{color:#80}private {color}List
> filterCheckedCheckboxes(List fields) {}}
> {{ {color:#80}return {color}filterByType(fields,
> PDCheckBox.{color:#80}class{color})}}
> {{ .stream()}}
> {{ .filter(PDCheckBox::isChecked)}}
> {{ .map(PDField.{color:#80}class{color}::cast)}}
> {{ .toList();}}
> }
--
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] [Resolved] (PDFBOX-5686) Acroform international (czech) characters can't be written to the textfields
[
https://issues.apache.org/jira/browse/PDFBOX-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun resolved PDFBOX-5686.
Resolution: Not A Problem
> Acroform international (czech) characters can't be written to the textfields
>
>
> Key: PDFBOX-5686
> URL: https://issues.apache.org/jira/browse/PDFBOX-5686
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.0 PDFBox
> Environment: Windows 11, JDK 14
>Reporter: Břetislav Černík
>Priority: Major
> Labels: Appearance
> Attachments: ZK.pdf, ZK_BAD.XFDF, ZK_Ok.XFDF
>
>
> I try use the ImportXFDF.java but it does not work for the czech characters
> in the xfdf file.
> The error is
> Exception in thread "main" java.lang.IllegalArgumentException: U+0159 is not
> available in this font's encoding: WinAnsiEncoding
> at
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.encode(PDTrueTypeFont.java:404)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:337)
> at org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:368)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainText$Paragraph.getLines(PlainText.java:178)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainTextFormatter.format(PlainTextFormatter.java:182)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.insertGeneratedAppearance(AppearanceGeneratorHelper.java:609)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:443)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:259)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:209)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:218)
> at formpdf.ImportXFDF.lambda$setFont$0(ImportXFDF.java:194)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at formpdf.ImportXFDF.setFont(ImportXFDF.java:178)
> at formpdf.ImportXFDF.importXFDF(ImportXFDF.java:137)
> at Test.TestFormPDF(Test.java:23)
> at Test.main(Test.java:18)
>
> I try to set the TTF Unicode font for every textfields but the same error is
> generated.
> There are test code from modified ImportXFDF. I use the method importXFDF
> package formpdf;
> //import com.sun.xml.internal.ws.policy.privateutil.PolicyUtils;
> import java.io.BufferedOutputStream;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.io.OutputStreamWriter;
> import java.io.UncheckedIOException;
> import java.io.File;
> import java.util.Iterator;
> import static org.apache.pdfbox.cos.COSName.Off;
> import org.apache.pdfbox.cos.COSName;
> import org.apache.pdfbox.pdmodel.PDDocument;
> import org.apache.pdfbox.pdmodel.PDDocumentCatalog;
> import org.apache.pdfbox.pdmodel.PDResources;
> import org.apache.pdfbox.pdmodel.fdf.FDFDocument;
> import org.apache.pdfbox.pdmodel.interactive.form.PDAcroForm;
> import org.apache.pdfbox.pdmodel.interactive.form.PDCheckBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDComboBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDField;
> import org.apache.pdfbox.pdmodel.interactive.form.PDListBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDRadioButton;
> import org.apache.pdfbox.pdmodel.interactive.form.PDTextField;
> import org.apache.pdfbox.Loader;
> import org.apache.pdfbox.pdmodel.font.PDFont;
> import org.apache.pdfbox.pdmodel.font.PDType0Font;
> import org.apache.pdfbox.pdmodel.font.PDTrueTypeFont;
> import org.apache.pdfbox.pdmodel.font.encoding.Encoding;
> import org.apache.pdfbox.pdmodel.font.encoding.StandardEncoding;
> import org.apache.pdfbox.pdmodel.font.encoding.WinAnsiEncoding;
> import org.apache.pdfbox.pdmodel.font.encoding.GlyphList;
> import org.apache.pdfbox.cos.COSBase;
> import org.apache.pdfbox.cos.COSName;
> import org.apache.fontbox.ttf.TrueTypeFont;
> public class ImportXFDF
> {
> /**
> * @param ac_PDFDocument
> * @param ac_XFDFData
> * @param ac_PDFResult
> * @param ab_clearFields
> * @throws IOException
> */
> public static void importXFDF
> (
> InputStream ac_PDFDocument,
> InputStream ac_XFDFData,
> OutputStream ac_PDFResult,
> boolean ab_clearFields,
> boolean ab_RemoveFields
> ) throws IOException
> {
> PDDocument
> lc_PDDDocument = null;
> String ls_FontName = "ArialMT";
> // MyEncoding
> //
[jira] [Commented] (PDFBOX-5686) Acroform international (czech) characters can't be written to the textfields
[
https://issues.apache.org/jira/browse/PDFBOX-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17768020#comment-17768020
]
Maruan Sahyoun commented on PDFBOX-5686:
Please try the sample code below which works for me
{code:java}
PDDocument document = Loader.loadPDF(new
File("/home/msahyoun/Downloads/ZK.pdf"));
PDAcroForm acroform = document.getDocumentCatalog().getAcroForm(null);
PDResources formResources = acroform.getDefaultResources();
PDTrueTypeFont font = (PDTrueTypeFont)
formResources.getFont(COSName.getPDFName("Arial"));
// here is the 'magic' to reuse the font as a new font resource
TrueTypeFont ttFont = font.getTrueTypeFont();
PDFont font2 = PDType0Font.load(document, ttFont, false);
ttFont.close();
// overwrite the preexisiting Arial entry with the new resource
formResources.put(COSName.getPDFName("Arial"), font2);
PDTextField txtField = (PDTextField) acroform.getField("ZP_POJISTENY_OJ");
txtField.setValue("společnost");
document.save("/home/msahyoun/Downloads/ZK-enhanced.pdf");
{code}
The basic idea is that although Arial is being already available in the PDFs
AcroForm resources the fact that it's encoding is set to WinAnsiEncoding limits
to use characters within that altough the embedded font file is also supporting
Czech characters. So what the code does is to read the embedded font file as a
new font and replaces the existing font resource with the new font which is now
using Identity-H (Unicode).
As a result the Czech character can be set.
I'm closing the ticket as this is not a bug but a limitation of the current PDF
form template and a how to question which is better asked on the users mailing
list.. Setting to WinAnsiEncoding and trying to use characters outside of that
will not work and as a result throwing an exception is intended.
So you have to modify the PDF template upfront or on the fly before loading the
XFDF.
> Acroform international (czech) characters can't be written to the textfields
>
>
> Key: PDFBOX-5686
> URL: https://issues.apache.org/jira/browse/PDFBOX-5686
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.0 PDFBox
> Environment: Windows 11, JDK 14
>Reporter: Břetislav Černík
>Priority: Major
> Labels: Appearance
> Attachments: ZK.pdf, ZK_BAD.XFDF, ZK_Ok.XFDF
>
>
> I try use the ImportXFDF.java but it does not work for the czech characters
> in the xfdf file.
> The error is
> Exception in thread "main" java.lang.IllegalArgumentException: U+0159 is not
> available in this font's encoding: WinAnsiEncoding
> at
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.encode(PDTrueTypeFont.java:404)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:337)
> at org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:368)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainText$Paragraph.getLines(PlainText.java:178)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainTextFormatter.format(PlainTextFormatter.java:182)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.insertGeneratedAppearance(AppearanceGeneratorHelper.java:609)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:443)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:259)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:209)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:218)
> at formpdf.ImportXFDF.lambda$setFont$0(ImportXFDF.java:194)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at formpdf.ImportXFDF.setFont(ImportXFDF.java:178)
> at formpdf.ImportXFDF.importXFDF(ImportXFDF.java:137)
> at Test.TestFormPDF(Test.java:23)
> at Test.main(Test.java:18)
>
> I try to set the TTF Unicode font for every textfields but the same error is
> generated.
> There are test code from modified ImportXFDF. I use the method importXFDF
> package formpdf;
> //import com.sun.xml.internal.ws.policy.privateutil.PolicyUtils;
> import java.io.BufferedOutputStream;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.io.OutputStreamWriter;
> import java.io.UncheckedIOException;
> import java.io.File;
> import java.util.Iterator;
> import static org.apache.pdfbox.cos.COSName.Off;
> import org.apache.pdfbox.cos.COSName;
> import org.apache.pdfbox.pdmodel.PDDocument;
[jira] [Updated] (PDFBOX-5686) Acroform international (czech) characters can't be written to the textfields
[
https://issues.apache.org/jira/browse/PDFBOX-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-5686:
---
Labels: Appearance (was: )
> Acroform international (czech) characters can't be written to the textfields
>
>
> Key: PDFBOX-5686
> URL: https://issues.apache.org/jira/browse/PDFBOX-5686
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.0 PDFBox
> Environment: Windows 11, JDK 14
>Reporter: Břetislav Černík
>Priority: Major
> Labels: Appearance
> Attachments: ZK.pdf, ZK_BAD.XFDF, ZK_Ok.XFDF
>
>
> I try use the ImportXFDF.java but it does not work for the czech characters
> in the xfdf file.
> The error is
> Exception in thread "main" java.lang.IllegalArgumentException: U+0159 is not
> available in this font's encoding: WinAnsiEncoding
> at
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.encode(PDTrueTypeFont.java:404)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:337)
> at org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:368)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainText$Paragraph.getLines(PlainText.java:178)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainTextFormatter.format(PlainTextFormatter.java:182)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.insertGeneratedAppearance(AppearanceGeneratorHelper.java:609)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:443)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:259)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:209)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:218)
> at formpdf.ImportXFDF.lambda$setFont$0(ImportXFDF.java:194)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at formpdf.ImportXFDF.setFont(ImportXFDF.java:178)
> at formpdf.ImportXFDF.importXFDF(ImportXFDF.java:137)
> at Test.TestFormPDF(Test.java:23)
> at Test.main(Test.java:18)
>
> I try to set the TTF Unicode font for every textfields but the same error is
> generated.
> There are test code from modified ImportXFDF. I use the method importXFDF
> package formpdf;
> //import com.sun.xml.internal.ws.policy.privateutil.PolicyUtils;
> import java.io.BufferedOutputStream;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.io.OutputStreamWriter;
> import java.io.UncheckedIOException;
> import java.io.File;
> import java.util.Iterator;
> import static org.apache.pdfbox.cos.COSName.Off;
> import org.apache.pdfbox.cos.COSName;
> import org.apache.pdfbox.pdmodel.PDDocument;
> import org.apache.pdfbox.pdmodel.PDDocumentCatalog;
> import org.apache.pdfbox.pdmodel.PDResources;
> import org.apache.pdfbox.pdmodel.fdf.FDFDocument;
> import org.apache.pdfbox.pdmodel.interactive.form.PDAcroForm;
> import org.apache.pdfbox.pdmodel.interactive.form.PDCheckBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDComboBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDField;
> import org.apache.pdfbox.pdmodel.interactive.form.PDListBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDRadioButton;
> import org.apache.pdfbox.pdmodel.interactive.form.PDTextField;
> import org.apache.pdfbox.Loader;
> import org.apache.pdfbox.pdmodel.font.PDFont;
> import org.apache.pdfbox.pdmodel.font.PDType0Font;
> import org.apache.pdfbox.pdmodel.font.PDTrueTypeFont;
> import org.apache.pdfbox.pdmodel.font.encoding.Encoding;
> import org.apache.pdfbox.pdmodel.font.encoding.StandardEncoding;
> import org.apache.pdfbox.pdmodel.font.encoding.WinAnsiEncoding;
> import org.apache.pdfbox.pdmodel.font.encoding.GlyphList;
> import org.apache.pdfbox.cos.COSBase;
> import org.apache.pdfbox.cos.COSName;
> import org.apache.fontbox.ttf.TrueTypeFont;
> public class ImportXFDF
> {
> /**
> * @param ac_PDFDocument
> * @param ac_XFDFData
> * @param ac_PDFResult
> * @param ab_clearFields
> * @throws IOException
> */
> public static void importXFDF
> (
> InputStream ac_PDFDocument,
> InputStream ac_XFDFData,
> OutputStream ac_PDFResult,
> boolean ab_clearFields,
> boolean ab_RemoveFields
> ) throws IOException
> {
> PDDocument
> lc_PDDDocument = null;
> String ls_FontName = "ArialMT";
> // MyEncoding
> //
[jira] [Commented] (PDFBOX-5686) Acroform international (czech) characters can't be written to the textfields
[
https://issues.apache.org/jira/browse/PDFBOX-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766876#comment-17766876
]
Maruan Sahyoun commented on PDFBOX-5686:
maybe take a look at my answer to the post I did a while ago for 2.0
https://stackoverflow.com/questions/42903217/write-cyrillic-chars-into-pdf-form-fields-with-pdfbox/43002076#43002076
> Acroform international (czech) characters can't be written to the textfields
>
>
> Key: PDFBOX-5686
> URL: https://issues.apache.org/jira/browse/PDFBOX-5686
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.0 PDFBox
> Environment: Windows 11, JDK 14
>Reporter: Břetislav Černík
>Priority: Major
>
> I try use the ImportXFDF.java but it does not work for the czech characters
> in the xfdf file.
> The error is
> Exception in thread "main" java.lang.IllegalArgumentException: U+0159 is not
> available in this font's encoding: WinAnsiEncoding
> at
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.encode(PDTrueTypeFont.java:404)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:337)
> at org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:368)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainText$Paragraph.getLines(PlainText.java:178)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainTextFormatter.format(PlainTextFormatter.java:182)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.insertGeneratedAppearance(AppearanceGeneratorHelper.java:609)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:443)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:259)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:209)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:218)
> at formpdf.ImportXFDF.lambda$setFont$0(ImportXFDF.java:194)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at formpdf.ImportXFDF.setFont(ImportXFDF.java:178)
> at formpdf.ImportXFDF.importXFDF(ImportXFDF.java:137)
> at Test.TestFormPDF(Test.java:23)
> at Test.main(Test.java:18)
>
> I try to set the TTF Unicode font for every textfields but the same error is
> generated.
> There are test code from modified ImportXFDF. I use the method importXFDF
> package formpdf;
> //import com.sun.xml.internal.ws.policy.privateutil.PolicyUtils;
> import java.io.BufferedOutputStream;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.io.OutputStreamWriter;
> import java.io.UncheckedIOException;
> import java.io.File;
> import java.util.Iterator;
> import static org.apache.pdfbox.cos.COSName.Off;
> import org.apache.pdfbox.cos.COSName;
> import org.apache.pdfbox.pdmodel.PDDocument;
> import org.apache.pdfbox.pdmodel.PDDocumentCatalog;
> import org.apache.pdfbox.pdmodel.PDResources;
> import org.apache.pdfbox.pdmodel.fdf.FDFDocument;
> import org.apache.pdfbox.pdmodel.interactive.form.PDAcroForm;
> import org.apache.pdfbox.pdmodel.interactive.form.PDCheckBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDComboBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDField;
> import org.apache.pdfbox.pdmodel.interactive.form.PDListBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDRadioButton;
> import org.apache.pdfbox.pdmodel.interactive.form.PDTextField;
> import org.apache.pdfbox.Loader;
> import org.apache.pdfbox.pdmodel.font.PDFont;
> import org.apache.pdfbox.pdmodel.font.PDType0Font;
> import org.apache.pdfbox.pdmodel.font.PDTrueTypeFont;
> import org.apache.pdfbox.pdmodel.font.encoding.Encoding;
> import org.apache.pdfbox.pdmodel.font.encoding.StandardEncoding;
> import org.apache.pdfbox.pdmodel.font.encoding.WinAnsiEncoding;
> import org.apache.pdfbox.pdmodel.font.encoding.GlyphList;
> import org.apache.pdfbox.cos.COSBase;
> import org.apache.pdfbox.cos.COSName;
> import org.apache.fontbox.ttf.TrueTypeFont;
> public class ImportXFDF
> {
> /**
> * @param ac_PDFDocument
> * @param ac_XFDFData
> * @param ac_PDFResult
> * @param ab_clearFields
> * @throws IOException
> */
> public static void importXFDF
> (
> InputStream ac_PDFDocument,
> InputStream ac_XFDFData,
> OutputStream ac_PDFResult,
> boolean ab_clearFields,
> boolean ab_RemoveFields
> ) throws IOException
> {
> PDD
[jira] [Commented] (PDFBOX-5686) Acroform international (czech) characters can't be written to the textfields
[
https://issues.apache.org/jira/browse/PDFBOX-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766875#comment-17766875
]
Maruan Sahyoun commented on PDFBOX-5686:
Can you add the original PDF and the one with your changes applied?
> Acroform international (czech) characters can't be written to the textfields
>
>
> Key: PDFBOX-5686
> URL: https://issues.apache.org/jira/browse/PDFBOX-5686
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 3.0.0 PDFBox
> Environment: Windows 11, JDK 14
>Reporter: Břetislav Černík
>Priority: Major
>
> I try use the ImportXFDF.java but it does not work for the czech characters
> in the xfdf file.
> The error is
> Exception in thread "main" java.lang.IllegalArgumentException: U+0159 is not
> available in this font's encoding: WinAnsiEncoding
> at
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.encode(PDTrueTypeFont.java:404)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:337)
> at org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:368)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainText$Paragraph.getLines(PlainText.java:178)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainTextFormatter.format(PlainTextFormatter.java:182)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.insertGeneratedAppearance(AppearanceGeneratorHelper.java:609)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:443)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:259)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:209)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:218)
> at formpdf.ImportXFDF.lambda$setFont$0(ImportXFDF.java:194)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at formpdf.ImportXFDF.setFont(ImportXFDF.java:178)
> at formpdf.ImportXFDF.importXFDF(ImportXFDF.java:137)
> at Test.TestFormPDF(Test.java:23)
> at Test.main(Test.java:18)
>
> I try to set the TTF Unicode font for every textfields but the same error is
> generated.
> There are test code from modified ImportXFDF. I use the method importXFDF
> package formpdf;
> //import com.sun.xml.internal.ws.policy.privateutil.PolicyUtils;
> import java.io.BufferedOutputStream;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.io.OutputStreamWriter;
> import java.io.UncheckedIOException;
> import java.io.File;
> import java.util.Iterator;
> import static org.apache.pdfbox.cos.COSName.Off;
> import org.apache.pdfbox.cos.COSName;
> import org.apache.pdfbox.pdmodel.PDDocument;
> import org.apache.pdfbox.pdmodel.PDDocumentCatalog;
> import org.apache.pdfbox.pdmodel.PDResources;
> import org.apache.pdfbox.pdmodel.fdf.FDFDocument;
> import org.apache.pdfbox.pdmodel.interactive.form.PDAcroForm;
> import org.apache.pdfbox.pdmodel.interactive.form.PDCheckBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDComboBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDField;
> import org.apache.pdfbox.pdmodel.interactive.form.PDListBox;
> import org.apache.pdfbox.pdmodel.interactive.form.PDRadioButton;
> import org.apache.pdfbox.pdmodel.interactive.form.PDTextField;
> import org.apache.pdfbox.Loader;
> import org.apache.pdfbox.pdmodel.font.PDFont;
> import org.apache.pdfbox.pdmodel.font.PDType0Font;
> import org.apache.pdfbox.pdmodel.font.PDTrueTypeFont;
> import org.apache.pdfbox.pdmodel.font.encoding.Encoding;
> import org.apache.pdfbox.pdmodel.font.encoding.StandardEncoding;
> import org.apache.pdfbox.pdmodel.font.encoding.WinAnsiEncoding;
> import org.apache.pdfbox.pdmodel.font.encoding.GlyphList;
> import org.apache.pdfbox.cos.COSBase;
> import org.apache.pdfbox.cos.COSName;
> import org.apache.fontbox.ttf.TrueTypeFont;
> public class ImportXFDF
> {
> /**
> * @param ac_PDFDocument
> * @param ac_XFDFData
> * @param ac_PDFResult
> * @param ab_clearFields
> * @throws IOException
> */
> public static void importXFDF
> (
> InputStream ac_PDFDocument,
> InputStream ac_XFDFData,
> OutputStream ac_PDFResult,
> boolean ab_clearFields,
> boolean ab_RemoveFields
> ) throws IOException
> {
> PDDocument
> lc_PDDDocument = null;
> String ls_FontName = "ArialMT";
> // MyEncoding
> //
[jira] [Commented] (PDFBOX-5682) Long/permanent hang in PDFBox 3.x
[
https://issues.apache.org/jira/browse/PDFBOX-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764358#comment-17764358
]
Maruan Sahyoun commented on PDFBOX-5682:
we could add a benchmark to the benchmark package with the sample so track
optimizations and also help find regressions later on. WDYT?
> Long/permanent hang in PDFBox 3.x
> -
>
> Key: PDFBOX-5682
> URL: https://issues.apache.org/jira/browse/PDFBOX-5682
> Project: PDFBox
> Issue Type: Bug
>Reporter: Tim Allison
>Priority: Minor
>
> I found two files in the regression tests where we're now getting timeouts at
> 3 minutes where we weren't before. Unfortunately, PDFBox's export:text works
> on both, so it is probably another structural feature, perhaps a problem in
> Tika?
> This file halts after printing out the header for Table 19 on page 46:
> https://corpora.tika.apache.org/base/docs/govdocs1/078/078656.pdf
> Pure PDFBox's export:text complains multiple times: "Page skipped due to an
> invalid or missing type null, but it does finish quickly."
> This file halts after extracting {{"854,793,592"}}:
> https://corpora.tika.apache.org/base/docs/commoncrawl3_refetched/G7/G7BO7PNCCREVF2BCY5YSYOPYDLMBYASY
> Pure PDFBox's export:text processes this without problem.
--
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] [Comment Edited] (PDFBOX-2378) XMPBox removes namespaces on serialization
[
https://issues.apache.org/jira/browse/PDFBOX-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761481#comment-17761481
]
Maruan Sahyoun edited comment on PDFBOX-2378 at 9/2/23 2:15 PM:
if we retire XmpBox there will be a replacement to handle XMP. The restriction
with XmpBox is that is was mainly to handle PDF/A XMP for parsing not as a an
all purpose XMP lib.
was (Author: msahyoun):
if we retire XmpBox there will be a replacement to handle XMP.
> XMPBox removes namespaces on serialization
> --
>
> Key: PDFBOX-2378
> URL: https://issues.apache.org/jira/browse/PDFBOX-2378
> Project: PDFBox
> Issue Type: Bug
> Components: XmpBox
>Affects Versions: 1.8.7, 2.0.29, 3.0.0 PDFBox, 4.0.0
>Reporter: Vadimo
>Priority: Minor
> Attachments: zf_extension.pdfbox.xmp
>
>
> {code:title=Bar.java|borderStyle=none}
> InputStream zfExtensionIs =
> getClass().getResourceAsStream("/zf_extension.pdfbox.xmp");
> DomXmpParser builder = new DomXmpParser();
> zfDefaultXmp = builder.parse(zfExtensionIs);
> PdfaExtensionHelper.populateSchemaMapping(zfDefaultXmp);
> new XmpSerializer().serialize(zfDefaultXmp, new
> FileOutputStream("target/out.xmp.xml"), true);
> {code}
> the incoming file
> {code:xml|title=incoming.xml|borderStyle=none}
>xmlns:pdfaExtension="http://www.aiim.org/pdfa/ns/extension/";
> xmlns:pdfaSchema="http://www.aiim.org/pdfa/ns/schema#";
> xmlns:pdfaProperty="http://www.aiim.org/pdfa/ns/property#"; rdf:about="">
> {code}
> outgoing file
> {code:xml|title=resulting.xml|borderStyle=none}
> http://www.aiim.org/pdfa/ns/extension/";
> rdf:about="">
> {code}
> why are the two namespaces gone?
--
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] [Commented] (PDFBOX-2378) XMPBox removes namespaces on serialization
[
https://issues.apache.org/jira/browse/PDFBOX-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761481#comment-17761481
]
Maruan Sahyoun commented on PDFBOX-2378:
if we retire XmpBox there will be a replacement to handle XMP.
> XMPBox removes namespaces on serialization
> --
>
> Key: PDFBOX-2378
> URL: https://issues.apache.org/jira/browse/PDFBOX-2378
> Project: PDFBox
> Issue Type: Bug
> Components: XmpBox
>Affects Versions: 1.8.7, 2.0.29, 3.0.0 PDFBox, 4.0.0
>Reporter: Vadimo
>Priority: Minor
> Attachments: zf_extension.pdfbox.xmp
>
>
> {code:title=Bar.java|borderStyle=none}
> InputStream zfExtensionIs =
> getClass().getResourceAsStream("/zf_extension.pdfbox.xmp");
> DomXmpParser builder = new DomXmpParser();
> zfDefaultXmp = builder.parse(zfExtensionIs);
> PdfaExtensionHelper.populateSchemaMapping(zfDefaultXmp);
> new XmpSerializer().serialize(zfDefaultXmp, new
> FileOutputStream("target/out.xmp.xml"), true);
> {code}
> the incoming file
> {code:xml|title=incoming.xml|borderStyle=none}
>xmlns:pdfaExtension="http://www.aiim.org/pdfa/ns/extension/";
> xmlns:pdfaSchema="http://www.aiim.org/pdfa/ns/schema#";
> xmlns:pdfaProperty="http://www.aiim.org/pdfa/ns/property#"; rdf:about="">
> {code}
> outgoing file
> {code:xml|title=resulting.xml|borderStyle=none}
> http://www.aiim.org/pdfa/ns/extension/";
> rdf:about="">
> {code}
> why are the two namespaces gone?
--
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] [Commented] (PDFBOX-2378) XMPBox removes namespaces on serialization
[
https://issues.apache.org/jira/browse/PDFBOX-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761474#comment-17761474
]
Maruan Sahyoun commented on PDFBOX-2378:
[~tilman] there has been a discussion to also retire XmpBox and not use it in
4.0 - not that there has been a decision yet
> XMPBox removes namespaces on serialization
> --
>
> Key: PDFBOX-2378
> URL: https://issues.apache.org/jira/browse/PDFBOX-2378
> Project: PDFBox
> Issue Type: Bug
> Components: XmpBox
>Affects Versions: 1.8.7, 2.0.29, 3.0.0 PDFBox, 4.0.0
>Reporter: Vadimo
>Priority: Minor
> Attachments: zf_extension.pdfbox.xmp
>
>
> {code:title=Bar.java|borderStyle=none}
> InputStream zfExtensionIs =
> getClass().getResourceAsStream("/zf_extension.pdfbox.xmp");
> DomXmpParser builder = new DomXmpParser();
> zfDefaultXmp = builder.parse(zfExtensionIs);
> PdfaExtensionHelper.populateSchemaMapping(zfDefaultXmp);
> new XmpSerializer().serialize(zfDefaultXmp, new
> FileOutputStream("target/out.xmp.xml"), true);
> {code}
> the incoming file
> {code:xml|title=incoming.xml|borderStyle=none}
>xmlns:pdfaExtension="http://www.aiim.org/pdfa/ns/extension/";
> xmlns:pdfaSchema="http://www.aiim.org/pdfa/ns/schema#";
> xmlns:pdfaProperty="http://www.aiim.org/pdfa/ns/property#"; rdf:about="">
> {code}
> outgoing file
> {code:xml|title=resulting.xml|borderStyle=none}
> http://www.aiim.org/pdfa/ns/extension/";
> rdf:about="">
> {code}
> why are the two namespaces gone?
--
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] [Commented] (PDFBOX-5576) Switch trunk (4.0.0) to at least java11 as minimum requirement
[ https://issues.apache.org/jira/browse/PDFBOX-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755422#comment-17755422 ] Maruan Sahyoun commented on PDFBOX-5576: [~lehmi] that fixed the NPE. Thank you. I'm getting a failure when building the examples but that's a different issue. > Switch trunk (4.0.0) to at least java11 as minimum requirement > -- > > Key: PDFBOX-5576 > URL: https://issues.apache.org/jira/browse/PDFBOX-5576 > Project: PDFBox > Issue Type: New Feature >Affects Versions: 3.0.0 PDFBox >Reporter: Andreas Lehmkühler >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 4.0.0 > > > Following a discussion on dev@ we decided to increase the minimum required > java version at least to java 11 starting with 4.0.0 > We have to check our dependencies if there are any limitations. Most likely > we have to release a new version of the JBIG2-Plugin using a newer java > version first. -- 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] [Commented] (PDFBOX-5576) Switch trunk (4.0.0) to at least java11 as minimum requirement
[ https://issues.apache.org/jira/browse/PDFBOX-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755205#comment-17755205 ] Maruan Sahyoun commented on PDFBOX-5576: removing trunk locally and a fresh svn checkout didn't resolve that. I won't have time for investigating further before start of next week. But it's good that the build works for others. > Switch trunk (4.0.0) to at least java11 as minimum requirement > -- > > Key: PDFBOX-5576 > URL: https://issues.apache.org/jira/browse/PDFBOX-5576 > Project: PDFBox > Issue Type: New Feature >Affects Versions: 3.0.0 PDFBox >Reporter: Andreas Lehmkühler >Assignee: Andreas Lehmkühler >Priority: Major > Fix For: 4.0.0 > > > Following a discussion on dev@ we decided to increase the minimum required > java version at least to java 11 starting with 4.0.0 > We have to check our dependencies if there are any limitations. Most likely > we have to release a new version of the JBIG2-Plugin using a newer java > version first. -- 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] [Comment Edited] (PDFBOX-5576) Switch trunk (4.0.0) to at least java11 as minimum requirement
[
https://issues.apache.org/jira/browse/PDFBOX-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755182#comment-17755182
]
Maruan Sahyoun edited comment on PDFBOX-5576 at 8/16/23 4:57 PM:
-
That's the full stack trace I'm getting. Didn't have time to investigate further
{code:java}
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:158)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:416)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:379)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:353)
at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:127)
at
org.apache.pdfbox.pdmodel.fixup.processor.AcroFormDefaultsProcessor.verifyOrCreateDefaults(AcroFormDefaultsProcessor.java:104)
at
org.apache.pdfbox.pdmodel.fixup.processor.AcroFormDefaultsProcessor.process(AcroFormDefaultsProcessor.java:58)
at
org.apache.pdfbox.pdmodel.fixup.AcroFormDefaultFixup.apply(AcroFormDefaultFixup.java:34)
at
org.apache.pdfbox.pdmodel.PDDocumentCatalog.getAcroForm(PDDocumentCatalog.java:132)
at
org.apache.pdfbox.pdmodel.PDDocumentCatalog.getAcroForm(PDDocumentCatalog.java:113)
at
org.apache.pdfbox.pdmodel.interactive.form.PDAcroFormFlattenTest.flattenAndCompare(PDAcroFormFlattenTest.java:223)
at
org.apache.pdfbox.pdmodel.interactive.form.PDAcroFormFlattenTest.testFlatten(PDAcroFormFlattenTest.java:145)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)
Caused by: java.lang.ExceptionInInitializerError: Exception
java.lang.NullPointerException [in thread "ForkJoinPool-1-worker-5"]
at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addTrueTypeFontImpl(FileSystemFontProvider.java:693)
at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addTrueTypeFont(FileSystemFontProvider.java:635)
at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:379)
at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.(FileSystemFontProvider.java:354)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.(FontMapperImpl.java:139)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:158)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:416)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getTrueTypeFont(FontMapperImpl.java:324)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.(PDTrueTypeFont.java:142)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:88)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:170)
at
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:72)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:892)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:530)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:505)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:152)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:282)
at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:344)
at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:261)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:233)
at
org.apache.pdfbox.multipdf.PDFMergerUtilityTest.checkMergeIdentical(PDFMergerUtilityTest.java:943)
at
org.apache.pdfbox.multipdf.PDFMergerUtilityTest.testPDFMergerUtility2(PDFMergerUtilityTest.java:113)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at
java.base/java.util.concurrent.ForkJoinTask.awaitDone(ForkJoinTask.java:436)
at java.base/java.util.concurrent.ForkJoinTask.join(ForkJoinTask.java:670)
... 6 more
{code}
Environment:
JDK 11
Fedora Lin
[jira] [Commented] (PDFBOX-5576) Switch trunk (4.0.0) to at least java11 as minimum requirement
[
https://issues.apache.org/jira/browse/PDFBOX-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755182#comment-17755182
]
Maruan Sahyoun commented on PDFBOX-5576:
That's the full stack trace I'm getting. Didn't have time to investigate further
{code}
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:158)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:416)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:379)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:353)
at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:127)
at
org.apache.pdfbox.pdmodel.fixup.processor.AcroFormDefaultsProcessor.verifyOrCreateDefaults(AcroFormDefaultsProcessor.java:104)
at
org.apache.pdfbox.pdmodel.fixup.processor.AcroFormDefaultsProcessor.process(AcroFormDefaultsProcessor.java:58)
at
org.apache.pdfbox.pdmodel.fixup.AcroFormDefaultFixup.apply(AcroFormDefaultFixup.java:34)
at
org.apache.pdfbox.pdmodel.PDDocumentCatalog.getAcroForm(PDDocumentCatalog.java:132)
at
org.apache.pdfbox.pdmodel.PDDocumentCatalog.getAcroForm(PDDocumentCatalog.java:113)
at
org.apache.pdfbox.pdmodel.interactive.form.PDAcroFormFlattenTest.flattenAndCompare(PDAcroFormFlattenTest.java:223)
at
org.apache.pdfbox.pdmodel.interactive.form.PDAcroFormFlattenTest.testFlatten(PDAcroFormFlattenTest.java:145)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)
Caused by: java.lang.ExceptionInInitializerError: Exception
java.lang.NullPointerException [in thread "ForkJoinPool-1-worker-5"]
at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addTrueTypeFontImpl(FileSystemFontProvider.java:693)
at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addTrueTypeFont(FileSystemFontProvider.java:635)
at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:379)
at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.(FileSystemFontProvider.java:354)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.(FontMapperImpl.java:139)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:158)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:416)
at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getTrueTypeFont(FontMapperImpl.java:324)
at
org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.(PDTrueTypeFont.java:142)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:88)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:170)
at
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:72)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:892)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:530)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:505)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:152)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:282)
at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:344)
at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:261)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:233)
at
org.apache.pdfbox.multipdf.PDFMergerUtilityTest.checkMergeIdentical(PDFMergerUtilityTest.java:943)
at
org.apache.pdfbox.multipdf.PDFMergerUtilityTest.testPDFMergerUtility2(PDFMergerUtilityTest.java:113)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at
java.base/java.util.concurrent.ForkJoinTask.awaitDone(ForkJoinTask.java:436)
at java.base/java.util.concurrent.ForkJoinTask.join(ForkJoinTask.java:670)
... 6 more
{code}
Environment:
JDK 11
Fedora Linux Workstation 38
> Switch trunk (4.0.0) to at lea
[jira] [Commented] (PDFBOX-5576) Switch trunk (4.0.0) to at least java11 as minimum requirement
[
https://issues.apache.org/jira/browse/PDFBOX-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754909#comment-17754909
]
Maruan Sahyoun commented on PDFBOX-5576:
Do you get
{{Could not initialize class
org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider}}
or is it only me?
> Switch trunk (4.0.0) to at least java11 as minimum requirement
> --
>
> Key: PDFBOX-5576
> URL: https://issues.apache.org/jira/browse/PDFBOX-5576
> Project: PDFBox
> Issue Type: New Feature
>Affects Versions: 3.0.0 PDFBox
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 4.0.0
>
>
> Following a discussion on dev@ we decided to increase the minimum required
> java version at least to java 11 starting with 4.0.0
> We have to check our dependencies if there are any limitations. Most likely
> we have to release a new version of the JBIG2-Plugin using a newer java
> version first.
--
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] [Commented] (PDFBOX-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753800#comment-17753800 ] Maruan Sahyoun commented on PDFBOX-2602: so we keep as is and are done here > 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 > Additional input: > https://clig.dev/ -- 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] [Comment Edited] (PDFBOX-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753793#comment-17753793 ] Maruan Sahyoun edited comment on PDFBOX-2602 at 8/13/23 3:40 PM: - I see - so is the conclusion to be compatible or breaking (which IMHO is OK for a major release)? There is also the comment from Simon thinking that CLI should be stable from 2.x to 3.x which would mean to revert the changes to a state where the commands are the same. was (Author: msahyoun): I see - so is the conclusion to be compatible or breaking (which IMHO is OK for a major release)? > 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 > Additional input: > https://clig.dev/ -- 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] [Commented] (PDFBOX-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753793#comment-17753793 ] Maruan Sahyoun commented on PDFBOX-2602: I see - so is the conclusion to be compatible or breaking (which IMHO is OK for a major release)? > 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 > Additional input: > https://clig.dev/ -- 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] [Commented] (PDFBOX-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753297#comment-17753297 ] Maruan Sahyoun commented on PDFBOX-2602: [~tilman] which is? > 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 > Additional input: > https://clig.dev/ -- 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] [Commented] (PDFBOX-2602) Enhance command line tools
[ https://issues.apache.org/jira/browse/PDFBOX-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753083#comment-17753083 ] Maruan Sahyoun commented on PDFBOX-2602: IMHO we're fine > 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 > Additional input: > https://clig.dev/ -- 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] [Resolved] (PDFBOX-5128) Support parsing non standardized XMP
[ https://issues.apache.org/jira/browse/PDFBOX-5128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun resolved PDFBOX-5128. Resolution: Fixed setting to resolved as the XMP in question can no be parsed. After 3.0 has been released there needs to be a decision about XMPBox. > Support parsing non standardized XMP > - > > Key: PDFBOX-5128 > URL: https://issues.apache.org/jira/browse/PDFBOX-5128 > Project: PDFBox > Issue Type: Task > Components: XmpBox >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: PDFBOX.zip, image-2021-03-17-09-00-57-653.png > > > XMP currently only supports parsing known XMP schema as has been discussed. > That shall be extended to support arbitrary but valid XMP. -- 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] [Updated] (PDFBOX-5128) Support parsing non standardized XMP
[ https://issues.apache.org/jira/browse/PDFBOX-5128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-5128: --- Fix Version/s: 3.0.0 PDFBox > Support parsing non standardized XMP > - > > Key: PDFBOX-5128 > URL: https://issues.apache.org/jira/browse/PDFBOX-5128 > Project: PDFBox > Issue Type: Task > Components: XmpBox >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: PDFBOX.zip, image-2021-03-17-09-00-57-653.png > > > XMP currently only supports parsing known XMP schema as has been discussed. > That shall be extended to support arbitrary but valid XMP. -- 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] [Resolved] (PDFBOX-5024) Add capability to add codesnippets from examples to documentation
[ https://issues.apache.org/jira/browse/PDFBOX-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun resolved PDFBOX-5024. Resolution: Fixed setting to resolved as capability has been added a while ago > Add capability to add codesnippets from examples to documentation > - > > Key: PDFBOX-5024 > URL: https://issues.apache.org/jira/browse/PDFBOX-5024 > Project: PDFBox > Issue Type: Improvement > Components: Documentation >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Major > > It would be good to make it easier to include code from our examples into the > documentation. This would allow us to keep the build tests for the examples > and on the other hand reuse the code in our docs. -- 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] [Updated] (PDFBOX-5024) Add capability to add codesnippets from examples to documentation
[ https://issues.apache.org/jira/browse/PDFBOX-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-5024: --- Component/s: Documentation > Add capability to add codesnippets from examples to documentation > - > > Key: PDFBOX-5024 > URL: https://issues.apache.org/jira/browse/PDFBOX-5024 > Project: PDFBox > Issue Type: Improvement > Components: Documentation >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Major > > It would be good to make it easier to include code from our examples into the > documentation. This would allow us to keep the build tests for the examples > and on the other hand reuse the code in our docs. -- 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] [Resolved] (PDFBOX-5565) RFE: Comb flag warning
[ https://issues.apache.org/jira/browse/PDFBOX-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun resolved PDFBOX-5565. Resolution: Fixed [~jurgen] I'm setting the ticket to be resolved. Thank you for the report > RFE: Comb flag warning > -- > > Key: PDFBOX-5565 > URL: https://issues.apache.org/jira/browse/PDFBOX-5565 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.27 >Reporter: Jurgen Doll >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 2.0.28, 3.0.0 PDFBox > > > Currently if a PDF form text field has it's Comb flag set true but the max > length hasn't been set then PDFBox silently ignores the field and doesn't > render it. > It would be helpful for PDFBox to at least issue a warning that the field > cannot be rendered as a Comb due to this. > It may be worth noting that if pdForm.setNeedAppearances is set true, and > after setting fields pdForm.refreshAppearances() is invoked that Comb fields > without max length specified do display in Acrobat and Edge. However without > both of these conditions they also don't display, just like PDFBox currently. > Perhaps worth considering aligning PDFBox to behave in a similar fashion > then, and to still issue the warning. -- 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-5565) RFE: Comb flag warning
[ https://issues.apache.org/jira/browse/PDFBOX-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun reassigned PDFBOX-5565: -- Assignee: Maruan Sahyoun > RFE: Comb flag warning > -- > > Key: PDFBOX-5565 > URL: https://issues.apache.org/jira/browse/PDFBOX-5565 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.27 >Reporter: Jurgen Doll >Assignee: Maruan Sahyoun >Priority: Minor > Fix For: 2.0.28, 3.0.0 PDFBox > > > Currently if a PDF form text field has it's Comb flag set true but the max > length hasn't been set then PDFBox silently ignores the field and doesn't > render it. > It would be helpful for PDFBox to at least issue a warning that the field > cannot be rendered as a Comb due to this. > It may be worth noting that if pdForm.setNeedAppearances is set true, and > after setting fields pdForm.refreshAppearances() is invoked that Comb fields > without max length specified do display in Acrobat and Edge. However without > both of these conditions they also don't display, just like PDFBox currently. > Perhaps worth considering aligning PDFBox to behave in a similar fashion > then, and to still issue the warning. -- 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] [Updated] (PDFBOX-5565) RFE: Comb flag warning
[ https://issues.apache.org/jira/browse/PDFBOX-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-5565: --- Fix Version/s: 2.0.28 3.0.0 PDFBox > RFE: Comb flag warning > -- > > Key: PDFBOX-5565 > URL: https://issues.apache.org/jira/browse/PDFBOX-5565 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.27 >Reporter: Jurgen Doll >Priority: Minor > Fix For: 2.0.28, 3.0.0 PDFBox > > > Currently if a PDF form text field has it's Comb flag set true but the max > length hasn't been set then PDFBox silently ignores the field and doesn't > render it. > It would be helpful for PDFBox to at least issue a warning that the field > cannot be rendered as a Comb due to this. > It may be worth noting that if pdForm.setNeedAppearances is set true, and > after setting fields pdForm.refreshAppearances() is invoked that Comb fields > without max length specified do display in Acrobat and Edge. However without > both of these conditions they also don't display, just like PDFBox currently. > Perhaps worth considering aligning PDFBox to behave in a similar fashion > then, and to still issue the warning. -- 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] [Updated] (PDFBOX-5565) RFE: Comb flag warning
[ https://issues.apache.org/jira/browse/PDFBOX-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-5565: --- Affects Version/s: 2.0.27 > RFE: Comb flag warning > -- > > Key: PDFBOX-5565 > URL: https://issues.apache.org/jira/browse/PDFBOX-5565 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.27 >Reporter: Jurgen Doll >Priority: Minor > > Currently if a PDF form text field has it's Comb flag set true but the max > length hasn't been set then PDFBox silently ignores the field and doesn't > render it. > It would be helpful for PDFBox to at least issue a warning that the field > cannot be rendered as a Comb due to this. > It may be worth noting that if pdForm.setNeedAppearances is set true, and > after setting fields pdForm.refreshAppearances() is invoked that Comb fields > without max length specified do display in Acrobat and Edge. However without > both of these conditions they also don't display, just like PDFBox currently. > Perhaps worth considering aligning PDFBox to behave in a similar fashion > then, and to still issue the warning. -- 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] [Commented] (PDFBOX-5565) RFE: Comb flag warning
[ https://issues.apache.org/jira/browse/PDFBOX-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702881#comment-17702881 ] Maruan Sahyoun commented on PDFBOX-5565: Using Adobe Reader the Comb flag is ignored when there is no MaxLength > RFE: Comb flag warning > -- > > Key: PDFBOX-5565 > URL: https://issues.apache.org/jira/browse/PDFBOX-5565 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Reporter: Jurgen Doll >Priority: Minor > > Currently if a PDF form text field has it's Comb flag set true but the max > length hasn't been set then PDFBox silently ignores the field and doesn't > render it. > It would be helpful for PDFBox to at least issue a warning that the field > cannot be rendered as a Comb due to this. > It may be worth noting that if pdForm.setNeedAppearances is set true, and > after setting fields pdForm.refreshAppearances() is invoked that Comb fields > without max length specified do display in Acrobat and Edge. However without > both of these conditions they also don't display, just like PDFBox currently. > Perhaps worth considering aligning PDFBox to behave in a similar fashion > then, and to still issue the warning. -- 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] [Updated] (PDFBOX-5565) RFE: Comb flag warning
[ https://issues.apache.org/jira/browse/PDFBOX-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maruan Sahyoun updated PDFBOX-5565: --- Component/s: AcroForm > RFE: Comb flag warning > -- > > Key: PDFBOX-5565 > URL: https://issues.apache.org/jira/browse/PDFBOX-5565 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Reporter: Jurgen Doll >Priority: Minor > > Currently if a PDF form text field has it's Comb flag set true but the max > length hasn't been set then PDFBox silently ignores the field and doesn't > render it. > It would be helpful for PDFBox to at least issue a warning that the field > cannot be rendered as a Comb due to this. > It may be worth noting that if pdForm.setNeedAppearances is set true, and > after setting fields pdForm.refreshAppearances() is invoked that Comb fields > without max length specified do display in Acrobat and Edge. However without > both of these conditions they also don't display, just like PDFBox currently. > Perhaps worth considering aligning PDFBox to behave in a similar fashion > then, and to still issue the warning. -- 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] [Commented] (PDFBOX-5300) Enhance and update PDFBox website & documentation - Part 2
[ https://issues.apache.org/jira/browse/PDFBOX-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692612#comment-17692612 ] Maruan Sahyoun commented on PDFBOX-5300: The latest commit introduces Eleventy 2.x - reduced build time for pages - reduced dependencies - security issues for the tooling down to 0 (was 4) > Enhance and update PDFBox website & documentation - Part 2 > -- > > Key: PDFBOX-5300 > URL: https://issues.apache.org/jira/browse/PDFBOX-5300 > Project: PDFBox > Issue Type: Task > Components: Documentation >Reporter: Maruan Sahyoun >Priority: Major > > follow up ticket to PDFBOX-3330 -- 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] [Commented] (PDFBOX-5565) RFE: Comb flag warning
[ https://issues.apache.org/jira/browse/PDFBOX-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17684810#comment-17684810 ] Maruan Sahyoun commented on PDFBOX-5565: note that setNeedAppearances to true signals that there hasn't been an appearence generated and/or it's oudated ... and the rendering application should generate one on the fly. > RFE: Comb flag warning > -- > > Key: PDFBOX-5565 > URL: https://issues.apache.org/jira/browse/PDFBOX-5565 > Project: PDFBox > Issue Type: Improvement >Reporter: Jurgen Doll >Priority: Minor > > Currently if a PDF form text field has it's Comb flag set true but the max > length hasn't been set then PDFBox silently ignores the field and doesn't > render it. > It would be helpful for PDFBox to at least issue a warning that the field > cannot be rendered as a Comb due to this. > It may be worth noting that if pdForm.setNeedAppearances is set true, and > after setting fields pdForm.refreshAppearances() is invoked that Comb fields > without max length specified do display in Acrobat and Edge. However without > both of these conditions they also don't display, just like PDFBox currently. > Perhaps worth considering aligning PDFBox to behave in a similar fashion > then, and to still issue the warning. -- 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] [Comment Edited] (PDFBOX-5549) Invisible signature field is not referenced from /Annots dictionary of a Page
[
https://issues.apache.org/jira/browse/PDFBOX-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640444#comment-17640444
]
Maruan Sahyoun edited comment on PDFBOX-5549 at 11/29/22 7:55 AM:
--
When generating such signature using Acrobat an /Annots entry is generated with
no AP entry and of course a /Rect of [0.0, 0.0, 0.0, 0.0].
Maybe we can enhance the code and do the same.
was (Author: msahyoun):
When generating such signature using Acrobat an /Annots entry is generated with
no AP entry and of course a /Rect of [0.0, 0.0, 0.0, 0.0].
> Invisible signature field is not referenced from /Annots dictionary of a Page
> -
>
> Key: PDFBOX-5549
> URL: https://issues.apache.org/jira/browse/PDFBOX-5549
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.27
>Reporter: Aleksandr Beliakov
>Priority: Minor
>
> Hello,
>
> Recently we received a complain about not adding a reference to the newly
> created signature field to the /Annots array of a page dictionary.
> After analyzing the code, we found that PdfBox dependency used in our
> project, skips binding of an invisible signature field from a page
> dictionary. See
> [PDDocument.java#L455:|https://github.com/apache/pdfbox/blob/2.0.27/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/PDDocument.java#L455]
> {code:java}
> if (visualSignature == null)
> {
> prepareNonVisibleSignature(firstWidget);
> return;
> } {code}
> while adding the signature widget to the given page for visible signature
> after.
>
> After analyzing ISO 32000-1/2 I was not able to conclude what is the expected
> behavior in case of invisible signature. While _/Annots_ array within a page
> dictionary is optional and shall contain references to annotations associated
> with a page, the chapter "12.5.2 Annotation dictionaries" also tells "{+}_A
> given annotation dictionary shall be referenced from the Annots array of only
> one page._{+}", which is also ambiguous.
> After checking [OpenPDF|https://github.com/LibrePDF/OpenPDF] library, it
> seems like they associate an invisible signature field with a first page
> explicitly by providing the reference within /Annots array.
>
> Could you please give us information about the rational for skipping the
> invisible signature field from adding into a page's /Annots dictionary and
> confirm whether the behavior is correct?
>
> Thank you!
>
> Best regards,
> Aleksandr.
--
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] [Commented] (PDFBOX-5549) Invisible signature field is not referenced from /Annots dictionary of a Page
[
https://issues.apache.org/jira/browse/PDFBOX-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640444#comment-17640444
]
Maruan Sahyoun commented on PDFBOX-5549:
When generating such signature using Acrobat an /Annots entry is generated with
no AP entry and of course a /Rect of [0.0, 0.0, 0.0, 0.0].
> Invisible signature field is not referenced from /Annots dictionary of a Page
> -
>
> Key: PDFBOX-5549
> URL: https://issues.apache.org/jira/browse/PDFBOX-5549
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.27
>Reporter: Aleksandr Beliakov
>Priority: Minor
>
> Hello,
>
> Recently we received a complain about not adding a reference to the newly
> created signature field to the /Annots array of a page dictionary.
> After analyzing the code, we found that PdfBox dependency used in our
> project, skips binding of an invisible signature field from a page
> dictionary. See
> [PDDocument.java#L455:|https://github.com/apache/pdfbox/blob/2.0.27/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/PDDocument.java#L455]
> {code:java}
> if (visualSignature == null)
> {
> prepareNonVisibleSignature(firstWidget);
> return;
> } {code}
> while adding the signature widget to the given page for visible signature
> after.
>
> After analyzing ISO 32000-1/2 I was not able to conclude what is the expected
> behavior in case of invisible signature. While _/Annots_ array within a page
> dictionary is optional and shall contain references to annotations associated
> with a page, the chapter "12.5.2 Annotation dictionaries" also tells "{+}_A
> given annotation dictionary shall be referenced from the Annots array of only
> one page._{+}", which is also ambiguous.
> After checking [OpenPDF|https://github.com/LibrePDF/OpenPDF] library, it
> seems like they associate an invisible signature field with a first page
> explicitly by providing the reference within /Annots array.
>
> Could you please give us information about the rational for skipping the
> invisible signature field from adding into a page's /Annots dictionary and
> confirm whether the behavior is correct?
>
> Thank you!
>
> Best regards,
> Aleksandr.
--
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] [Commented] (PDFBOX-5546) Issue with the index based RadioButton value selection.
[
https://issues.apache.org/jira/browse/PDFBOX-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17638628#comment-17638628
]
Maruan Sahyoun commented on PDFBOX-5546:
could you add the sample PDFs as extra attachments please
> Issue with the index based RadioButton value selection.
> ---
>
> Key: PDFBOX-5546
> URL: https://issues.apache.org/jira/browse/PDFBOX-5546
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.27
>Reporter: Christian Appl
>Priority: Major
> Attachments: WEBPDF-1616.patch
>
>
> We encountered an issue with the index based selection of RadioButton values
> - in case an "Opt" Array (Export value) definition is present.
> *The issue: valid index selections are overwritten, when calling
> "constructAppearances()"*
> Location:
> {color:#00}org.apache.pdfbox.pdmodel.interactive.form.PDButton{color}:
> When selecting an option via index - with activated "generateAppearances"
> flag - via "setValue(int)": The value (V) of the RadioButton field and the
> appearance states of it´s contained streams were updated accordingly and
> correctly.
> But when debugging I found that the following internal call to:
> applyChanges->constructAppearances, would override the correct values with
> erroneous ones that rather match the direct onState selection (without Opt
> array).
> Which lead to me implementing the hereby provided patch trying to address the
> issue.
> *Additonal observation: onValue name and index mismatch*
> When setting the Value V of the containing RadioButton field the current
> implementation assumed, that the name of the "onState" Stream would always
> match the index of the child in the kids/Opt array.
> I was able to create a document (using Adobe DC) that did contradict that
> assumption. Adobe DC allows selecting custom names for the Acroform "onState"
> names (and streams) in that case the index of the child may i.e. be 0, while
> the name of the "onState" stream is "Choice1", but using "Choice1" as the "V"
> value for the field will not lead to a valid/working result.
> In this patch you will also find a solution, that attempts to address that
> issue aswell.
> *Tests:*
> You will also find two tests in the patch, that summarize the behaviour I
> would assume to be correct.
--
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-5546) Issue with the index based RadioButton value selection.
[
https://issues.apache.org/jira/browse/PDFBOX-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun reassigned PDFBOX-5546:
--
Assignee: Maruan Sahyoun
> Issue with the index based RadioButton value selection.
> ---
>
> Key: PDFBOX-5546
> URL: https://issues.apache.org/jira/browse/PDFBOX-5546
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.27
>Reporter: Christian Appl
>Assignee: Maruan Sahyoun
>Priority: Major
> Attachments: WEBPDF-1616.patch
>
>
> We encountered an issue with the index based selection of RadioButton values
> - in case an "Opt" Array (Export value) definition is present.
> *The issue: valid index selections are overwritten, when calling
> "constructAppearances()"*
> Location:
> {color:#00}org.apache.pdfbox.pdmodel.interactive.form.PDButton{color}:
> When selecting an option via index - with activated "generateAppearances"
> flag - via "setValue(int)": The value (V) of the RadioButton field and the
> appearance states of it´s contained streams were updated accordingly and
> correctly.
> But when debugging I found that the following internal call to:
> applyChanges->constructAppearances, would override the correct values with
> erroneous ones that rather match the direct onState selection (without Opt
> array).
> Which lead to me implementing the hereby provided patch trying to address the
> issue.
> *Additonal observation: onValue name and index mismatch*
> When setting the Value V of the containing RadioButton field the current
> implementation assumed, that the name of the "onState" Stream would always
> match the index of the child in the kids/Opt array.
> I was able to create a document (using Adobe DC) that did contradict that
> assumption. Adobe DC allows selecting custom names for the Acroform "onState"
> names (and streams) in that case the index of the child may i.e. be 0, while
> the name of the "onState" stream is "Choice1", but using "Choice1" as the "V"
> value for the field will not lead to a valid/working result.
> In this patch you will also find a solution, that attempts to address that
> issue aswell.
> *Tests:*
> You will also find two tests in the patch, that summarize the behaviour I
> would assume to be correct.
--
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] [Commented] (PDFBOX-5522) Add public void save(COSWriter writer) to PDDocument
[
https://issues.apache.org/jira/browse/PDFBOX-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612287#comment-17612287
]
Maruan Sahyoun commented on PDFBOX-5522:
for 1) doing it in COSWriter you no longer have the context of what type of
object it is other than the low level COS objects. i.e. you don't have an
information of what's allowed as properties, object types ...
for 2) would do that on the higher level object as you have more context about
the type of object (acknowledged it's probably less work on the COS writer).
I'm assuming it's mainly images you're looking to do a different compression to.
Maybe take a look at the pdmodel/fixup and it's content. Maybe an approach we
can extend on for your use case?
> Add public void save(COSWriter writer) to PDDocument
>
>
> Key: PDFBOX-5522
> URL: https://issues.apache.org/jira/browse/PDFBOX-5522
> Project: PDFBox
> Issue Type: New Feature
> Components: PDModel
>Affects Versions: 2.0.28, 3.0.0 PDFBox
>Reporter: Stefan Ziegler
>Priority: Minor
> Attachments: PDDocument.java.patch
>
>
> Please add the following method to PDDocument:
>
> {code:java}
> public void save(COSWriter writer){code}
>
> Why?
> This gives us the possibility to use a custom COSWriter when saving the PDF
> file. Inside the custom COSWriter we can add some checks and convert some
> data structures if required.
>
> Patch is attached.
>
--
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] [Commented] (PDFBOX-5513) getPageLayout throws IllegalArgumentException for empty mode
[
https://issues.apache.org/jira/browse/PDFBOX-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606535#comment-17606535
]
Maruan Sahyoun commented on PDFBOX-5513:
[~tilman] thoughts?
> getPageLayout throws IllegalArgumentException for empty mode
>
>
> Key: PDFBOX-5513
> URL: https://issues.apache.org/jira/browse/PDFBOX-5513
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.25, 2.0.26, 3.0.0 PDFBox
>Reporter: Karol Bryd
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.27, 3.0.0 PDFBox
>
> Attachments: page_layout_issue.patch
>
>
> getPageLayout() method in PDDocumentCatalog can throw an exception
> IllegalArgumentException when the PageLayout mode is not one of defined in
> the PageLayout class. In my case the mode is simply an empty string.The PDF
> documents which contain such unexpected Page Layout value are all rendered by
> quite old Adobe PDF library 7.0 from 2014 (I can't share the document, it is
> confidential).
> My suggestion is to modify the method so that, similarly to getPageMode()
> method, the eventual exception is caught and the method returns the default
> PageLayout.{color:#9876aa}SINGLE_PAGE {color}mode.{color:#9876aa}
> {color}
>
> This problem affects the current version in trunk, as well as at least 2.0.25
> and 2.0.26.
>
> I have created very simple patch which fixes the problem, please consider
> applying it to the trunk and 2.0.x branch.
>
>
--
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] [Commented] (PDFBOX-5499) Performance issue since 2.0.18
[
https://issues.apache.org/jira/browse/PDFBOX-5499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606272#comment-17606272
]
Maruan Sahyoun commented on PDFBOX-5499:
Did we ever measure the improvement SmallMap has for memory and performance for
small number of entries vs. other implementations?
> Performance issue since 2.0.18
> --
>
> Key: PDFBOX-5499
> URL: https://issues.apache.org/jira/browse/PDFBOX-5499
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.19
>Reporter: Thomas Debray Luyat
>Priority: Major
> Fix For: 2.0.27, 3.0.0 PDFBox
>
> Attachments: image-2022-09-05-12-48-04-608.png,
> image-2022-09-05-17-37-55-155.png, image-2022-09-05-17-40-22-416.png,
> image-2022-09-05-19-55-40-753.png
>
>
> Our PDF is parsed in less than 200ms in 2.0.18 and more then 8 seconds in
> 2.0.19. The same issue is still there in 2.0.26.
>
> In version 2.0.19, SmallMap has been introduced. We're facing a performance
> issue since this modification.
> !image-2022-09-05-12-48-04-608.png|width=968,height=377!
> We patch our code to just replace the SmallMap implementation like this:
> {code:java}
> package org.apache.pdfbox.util;
> import java.util.LinkedHashMap;
> public class SmallMap extends LinkedHashMap {
> // nothing : use the standard LinkedHashMap
> }{code}
> And the performance issue disappear.
> Our test is really simple:
> {code:java}
> long start = System.currentTimeMillis();
> try (PDDocument document = PDDocument.load(new File(inFile))) {
> // nothing : only parsing is evaluated
> }
> long duration = System.currentTimeMillis() -start;
> assertTrue(duration < 500);{code}
>
> I can understand that the SmallMap can solve issues in some cases, but it is
> possible to implement a factory to create this map and then allow to setup
> which Map implementation we want to use?
--
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] [Comment Edited] (PDFBOX-5513) getPageLayout throws IllegalArgumentException for empty mode
[
https://issues.apache.org/jira/browse/PDFBOX-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605632#comment-17605632
]
Maruan Sahyoun edited comment on PDFBOX-5513 at 9/16/22 6:29 AM:
-
What's your proposal?
- no page mode et all or empty -> SinglePage
- one of the pages modes defined -> return the PageMode
- not empty but none of the defined ones -> exception
?
Added note - one can always check the value using the COS model.
BR
Maruan
was (Author: msahyoun):
What's your proposal in such cases?
- no page mode et all or empty -> SinglePage
- one of the pages modes defined -> return the PageMode
- not empty but none of the defined ones -> exception
?
BR
Maruan
> getPageLayout throws IllegalArgumentException for empty mode
>
>
> Key: PDFBOX-5513
> URL: https://issues.apache.org/jira/browse/PDFBOX-5513
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.25, 2.0.26, 3.0.0 PDFBox
>Reporter: Karol Bryd
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.27, 3.0.0 PDFBox
>
> Attachments: page_layout_issue.patch
>
>
> getPageLayout() method in PDDocumentCatalog can throw an exception
> IllegalArgumentException when the PageLayout mode is not one of defined in
> the PageLayout class. In my case the mode is simply an empty string.The PDF
> documents which contain such unexpected Page Layout value are all rendered by
> quite old Adobe PDF library 7.0 from 2014 (I can't share the document, it is
> confidential).
> My suggestion is to modify the method so that, similarly to getPageMode()
> method, the eventual exception is caught and the method returns the default
> PageLayout.{color:#9876aa}SINGLE_PAGE {color}mode.{color:#9876aa}
> {color}
>
> This problem affects the current version in trunk, as well as at least 2.0.25
> and 2.0.26.
>
> I have created very simple patch which fixes the problem, please consider
> applying it to the trunk and 2.0.x branch.
>
>
--
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] [Commented] (PDFBOX-5513) getPageLayout throws IllegalArgumentException for empty mode
[
https://issues.apache.org/jira/browse/PDFBOX-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605632#comment-17605632
]
Maruan Sahyoun commented on PDFBOX-5513:
What's your proposal in such cases?
- no page mode et all or empty -> SinglePage
- one of the pages modes defined -> return the PageMode
- not empty but none of the defined ones -> exception
?
BR
Maruan
> getPageLayout throws IllegalArgumentException for empty mode
>
>
> Key: PDFBOX-5513
> URL: https://issues.apache.org/jira/browse/PDFBOX-5513
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.25, 2.0.26, 3.0.0 PDFBox
>Reporter: Karol Bryd
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.27, 3.0.0 PDFBox
>
> Attachments: page_layout_issue.patch
>
>
> getPageLayout() method in PDDocumentCatalog can throw an exception
> IllegalArgumentException when the PageLayout mode is not one of defined in
> the PageLayout class. In my case the mode is simply an empty string.The PDF
> documents which contain such unexpected Page Layout value are all rendered by
> quite old Adobe PDF library 7.0 from 2014 (I can't share the document, it is
> confidential).
> My suggestion is to modify the method so that, similarly to getPageMode()
> method, the eventual exception is caught and the method returns the default
> PageLayout.{color:#9876aa}SINGLE_PAGE {color}mode.{color:#9876aa}
> {color}
>
> This problem affects the current version in trunk, as well as at least 2.0.25
> and 2.0.26.
>
> I have created very simple patch which fixes the problem, please consider
> applying it to the trunk and 2.0.x branch.
>
>
--
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] [Commented] (PDFBOX-5513) getPageLayout throws IllegalArgumentException for empty mode
[
https://issues.apache.org/jira/browse/PDFBOX-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605288#comment-17605288
]
Maruan Sahyoun commented on PDFBOX-5513:
@mkl SinglePage is the default value. So in this case I think that returning
SinglePage only reflects that.
> getPageLayout throws IllegalArgumentException for empty mode
>
>
> Key: PDFBOX-5513
> URL: https://issues.apache.org/jira/browse/PDFBOX-5513
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.25, 2.0.26, 3.0.0 PDFBox
>Reporter: Karol Bryd
>Assignee: Tilman Hausherr
>Priority: Major
> Fix For: 2.0.27, 3.0.0 PDFBox
>
> Attachments: page_layout_issue.patch
>
>
> getPageLayout() method in PDDocumentCatalog can throw an exception
> IllegalArgumentException when the PageLayout mode is not one of defined in
> the PageLayout class. In my case the mode is simply an empty string.The PDF
> documents which contain such unexpected Page Layout value are all rendered by
> quite old Adobe PDF library 7.0 from 2014 (I can't share the document, it is
> confidential).
> My suggestion is to modify the method so that, similarly to getPageMode()
> method, the eventual exception is caught and the method returns the default
> PageLayout.{color:#9876aa}SINGLE_PAGE {color}mode.{color:#9876aa}
> {color}
>
> This problem affects the current version in trunk, as well as at least 2.0.25
> and 2.0.26.
>
> I have created very simple patch which fixes the problem, please consider
> applying it to the trunk and 2.0.x branch.
>
>
--
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
