[jira] [Comment Edited] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table
[
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407073#comment-17407073
]
Kishore Kumar edited comment on PDFBOX-4189 at 8/31/21, 5:45 AM:
-
Team,
I am not getting PDFBox to render malayalam (one of the Indic script) text
properly. If Ligature substitution works then this should work. I am using
3.0.0-RC1 version.
String text = "വകുപ്പ് 1 മനുഷ്യരെല്ലാവരും തുല്യാവകാശങ്ങളോടും";
PDDocument doc = *new* PDDocument();
PDFont font = PDType0Font.load(doc, new
File("/Users/kishore/Downloads/ML-NILA01_NewLipi.ttf"));
PDPage page = *new* PDPage();
doc.addPage(page);
PDPageContentStream contentStream = *new* PDPageContentStream(doc, page);
contentStream.beginText();
contentStream.newLineAtOffset(25, 700);
contentStream.setFont(font,12 );
contentStream.showText(text);
contentStream.endText();
contentStream.close();
Do we have the support for GSUB tables now? Am I doing anything wrong here?
Please suggest.
The output I get is -
!pdf-output.png!
versus the input text text
വകുപ്പ് 1 മനുഷ്യരെല്ലാവരും തുല്യാവകാശങ്ങളോടും
Here GSUB substitution is not happening.
was (Author: kishorekollam):
Team,
I am not getting PDFBox to render malayalam (one of the Indic script) text
properly. If Ligature substitution works then this should work. I am using
3.0.0-RC1 version.
String text = "വകുപ്പ് 1 മനുഷ്യരെല്ലാവരും തുല്യാവകാശങ്ങളോടും";
PDDocument doc = *new* PDDocument();
PDFont font = PDType0Font.load(doc, new
File("/Users/kishore/Downloads/ML-NILA01_NewLipi.ttf"));
PDPage page = *new* PDPage();
doc.addPage(page);
PDPageContentStream contentStream = *new* PDPageContentStream(doc, page);
contentStream.beginText();
contentStream.newLineAtOffset(25, 700);
contentStream.setFont(font,12 );
contentStream.showText(text);
contentStream.endText();
contentStream.close();
Do we have the support for GSUB tables now? Am I doing anything wrong here?
Please suggest.
> Enable PDF creation with Indian languages, by reading and utilizing the GSUB
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf,
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf,
> bengali-example2.pdf, bengali-example3.pdf, bengali-word-lohit-bad.pdf,
> bengali-word-lohit-good.pdf, committed.patch, pdf-output.png, screenshot.png
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph
> substitution. The GSUB table has been read and used effectively to replace
> some compound words with their respective Glyphs. All tests are passing. I
> have tested this for the Bengali font. Please review these changes and let me
> know if it makes sense to incorporate these.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table
[ https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishore Kumar updated PDFBOX-4189: -- Attachment: pdf-output.png > Enable PDF creation with Indian languages, by reading and utilizing the GSUB > table > -- > > Key: PDFBOX-4189 > URL: https://issues.apache.org/jira/browse/PDFBOX-4189 > Project: PDFBox > Issue Type: New Feature > Components: FontBox, PDModel >Reporter: Palash Ray >Priority: Major > Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf, > BengaliPdfGenerationHelloWorld.java, bengali-example.pdf, > bengali-example2.pdf, bengali-example3.pdf, bengali-word-lohit-bad.pdf, > bengali-word-lohit-good.pdf, committed.patch, pdf-output.png, screenshot.png > > Original Estimate: 336h > Remaining Estimate: 336h > > Implemented proper rendering of Indian languages, which need extensive Glyph > substitution. The GSUB table has been read and used effectively to replace > some compound words with their respective Glyphs. All tests are passing. I > have tested this for the Bengali font. Please review these changes and let me > know if it makes sense to incorporate these. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table
[
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407073#comment-17407073
]
Kishore Kumar edited comment on PDFBOX-4189 at 8/31/21, 5:36 AM:
-
Team,
I am not getting PDFBox to render malayalam (one of the Indic script) text
properly. If Ligature substitution works then this should work. I am using
3.0.0-RC1 version.
String text = "വകുപ്പ് 1 മനുഷ്യരെല്ലാവരും തുല്യാവകാശങ്ങളോടും";
PDDocument doc = *new* PDDocument();
PDFont font = PDType0Font.load(doc, new
File("/Users/kishore/Downloads/ML-NILA01_NewLipi.ttf"));
PDPage page = *new* PDPage();
doc.addPage(page);
PDPageContentStream contentStream = *new* PDPageContentStream(doc, page);
contentStream.beginText();
contentStream.newLineAtOffset(25, 700);
contentStream.setFont(font,12 );
contentStream.showText(text);
contentStream.endText();
contentStream.close();
Do we have the support for GSUB tables now? Am I doing anything wrong here?
Please suggest.
was (Author: kishorekollam):
Team,
I am not getting PDFBox to render malayalam (one of the Indic script) text
properly. If Ligature substitution works then this should work. I am using
3.0.0-RC1 version.
String text = "വകുപ്പ് 1 മനുഷ്യരെല്ലാവരും തുല്യാവകാശങ്ങളോടും";
PDDocument doc = *new* PDDocument();
PDFont font = PDType0Font.load(doc, new
File("/Users/kishore/Downloads/ML-NILA01_NewLipi.ttf"));
PDPage page = *new* PDPage();
doc.addPage(page);
PDPageContentStream contentStream = *new* PDPageContentStream(doc, page);
contentStream.beginText();
contentStream.newLineAtOffset(25, 700);
contentStream.setFont(font,12 );
contentStream.showText(text);
contentStream.endText();
contentStream.close();
Am I doing anything wrong here? Please help.
> Enable PDF creation with Indian languages, by reading and utilizing the GSUB
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf,
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf,
> bengali-example2.pdf, bengali-example3.pdf, bengali-word-lohit-bad.pdf,
> bengali-word-lohit-good.pdf, committed.patch, screenshot.png
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph
> substitution. The GSUB table has been read and used effectively to replace
> some compound words with their respective Glyphs. All tests are passing. I
> have tested this for the Bengali font. Please review these changes and let me
> know if it makes sense to incorporate these.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table
[
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407073#comment-17407073
]
Kishore Kumar edited comment on PDFBOX-4189 at 8/31/21, 5:35 AM:
-
Team,
I am not getting PDFBox to render malayalam (one of the Indic script) text
properly. If Ligature substitution works then this should work. I am using
3.0.0-RC1 version.
String text = "വകുപ്പ് 1 മനുഷ്യരെല്ലാവരും തുല്യാവകാശങ്ങളോടും";
PDDocument doc = *new* PDDocument();
PDFont font = PDType0Font.load(doc, new
File("/Users/kishore/Downloads/ML-NILA01_NewLipi.ttf"));
PDPage page = *new* PDPage();
doc.addPage(page);
PDPageContentStream contentStream = *new* PDPageContentStream(doc, page);
contentStream.beginText();
contentStream.newLineAtOffset(25, 700);
contentStream.setFont(font,12 );
contentStream.showText(text);
contentStream.endText();
contentStream.close();
Am I doing anything wrong here? Please help.
was (Author: kishorekollam):
Team,
I am not getting PDFBox to render malayalam (one of the Indic script) text
properly. If Ligature substitution works then this should work. I am using
3.0.0-RC1 version.
PDDocument doc = *new* PDDocument();
PDFont font = PDType0Font.load(doc, new
File("/Users/kishore/Downloads/ML-NILA01_NewLipi.ttf"));
PDPage page = *new* PDPage();
doc.addPage(page);
PDPageContentStream contentStream = *new* PDPageContentStream(doc, page);
contentStream.beginText();
contentStream.newLineAtOffset(25, 700);
contentStream.setFont(font,12 );
contentStream.showText(text);
contentStream.endText();
contentStream.close();
Am I doing anything wrong here? Please help.
> Enable PDF creation with Indian languages, by reading and utilizing the GSUB
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf,
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf,
> bengali-example2.pdf, bengali-example3.pdf, bengali-word-lohit-bad.pdf,
> bengali-word-lohit-good.pdf, committed.patch, screenshot.png
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph
> substitution. The GSUB table has been read and used effectively to replace
> some compound words with their respective Glyphs. All tests are passing. I
> have tested this for the Bengali font. Please review these changes and let me
> know if it makes sense to incorporate these.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table
[
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407073#comment-17407073
]
Kishore Kumar commented on PDFBOX-4189:
---
Team,
I am not getting PDFBox to render malayalam (one of the Indic script) text
properly. If Ligature substitution works then this should work. I am using
3.0.0-RC1 version.
PDDocument doc = *new* PDDocument();
PDFont font = PDType0Font.load(doc, new
File("/Users/kishore/Downloads/ML-NILA01_NewLipi.ttf"));
PDPage page = *new* PDPage();
doc.addPage(page);
PDPageContentStream contentStream = *new* PDPageContentStream(doc, page);
contentStream.beginText();
contentStream.newLineAtOffset(25, 700);
contentStream.setFont(font,12 );
contentStream.showText(text);
contentStream.endText();
contentStream.close();
Am I doing anything wrong here? Please help.
> Enable PDF creation with Indian languages, by reading and utilizing the GSUB
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf,
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf,
> bengali-example2.pdf, bengali-example3.pdf, bengali-word-lohit-bad.pdf,
> bengali-word-lohit-good.pdf, committed.patch, screenshot.png
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph
> substitution. The GSUB table has been read and used effectively to replace
> some compound words with their respective Glyphs. All tests are passing. I
> have tested this for the Bengali font. Please review these changes and let me
> know if it makes sense to incorporate these.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407064#comment-17407064 ] Tilman Hausherr edited comment on PDFBOX-5268 at 8/31/21, 4:36 AM: --- So it's like I wrote. You don't have these fonts installed. And you had logs disabled previously because the WARNings you are getting now are pretty obvious. So get the Dingbats / Gothic font I mentioned and install it, also get the other fonts mentioned ( sudo apt install ttf-mscorefonts-installer ). was (Author: tilman): So it's like I wrote. You don't have these fonts installed. And you had logs disabled because the WARNings are pretty obvious. So get the Dingbats / Gothic font I mentioned and install it, also get the other fonts mentioned ( sudo apt install ttf-mscorefonts-installer ). > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows, Linux >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, log.txt, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407066#comment-17407066 ] Tilman Hausherr commented on PDFBOX-5268: - The list of the current fonts can also be found in .pdfbox.cache in your home directory. > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows, Linux >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, log.txt, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407064#comment-17407064 ] Tilman Hausherr commented on PDFBOX-5268: - So it's like I wrote. You don't have these fonts installed. And you had logs disabled because the WARNings are pretty obvious. So get the Dingbats / Gothic font I mentioned and install it, also get the other fonts mentioned ( sudo apt install ttf-mscorefonts-installer ). > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows, Linux >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, log.txt, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406954#comment-17406954 ] Joharat commented on PDFBOX-5268: - [~tilman], added a log file for your reference, I see liberation font being substituted. > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows, Linux >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, log.txt, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joharat updated PDFBOX-5268: Attachment: log.txt > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows, Linux >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, log.txt, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406953#comment-17406953 ] Joharat commented on PDFBOX-5268: - [~tilman], environment is both windows and linux. Windows it works in my test harness , Linux I do not see the symbol. > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows, Linux >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joharat updated PDFBOX-5268: Environment: Windows, Linux (was: Windows) > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows, Linux >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[
https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406909#comment-17406909
]
Tilman Hausherr commented on PDFBOX-5268:
-
But you mentioned that your environment is Windows???
Turn up the ordinary logging, INFO level.
Some linux systems have a "Dingbats" font which is also OK. The names of fonts
that have the glyphs are
"ZapfDingbatsITCbyBT-Regular", "ZapfDingbatsITC", "Dingbats", "MS-Gothic".
Here's where Linux searches for fonts:
{code}
return new String[] { System.getProperty("user.home") + "/.fonts", //
user
"/usr/local/fonts", // local
"/usr/local/share/fonts", // local shared
"/usr/share/fonts", // system
"/usr/X11R6/lib/X11/fonts", // X
"/usr/share/X11/fonts" // CentOS
};
{code}
> Checkbox does not render in the png created for the attached pdf's
> --
>
> Key: PDFBOX-5268
> URL: https://issues.apache.org/jira/browse/PDFBOX-5268
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 3.0.0 PDFBox
> Environment: Windows
>Reporter: Joharat
>Priority: Major
> Attachments: OpenPDFBox_2.pdf,
> OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf,
> rendering1.png, rendering1_checked.png
>
>
> For the 2 attached pdf's when a png is created for the first page of the pdf
> the check box does not translate over. The checkbox is empty.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406905#comment-17406905 ] Joharat commented on PDFBOX-5268: - [~tilman], this is most likely a font issue. I see a empty square in Linux. What logging do I need to turn on to see what the likely problem is? > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4892) Improve code quality (4)
[ https://issues.apache.org/jira/browse/PDFBOX-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406880#comment-17406880 ] ASF subversion and git services commented on PDFBOX-4892: - Commit 1892739 from Tilman Hausherr in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1892739 ] PDFBOX-4892: always grow to maximum, as suggested by valerybokov; remove super() > Improve code quality (4) > > > Key: PDFBOX-4892 > URL: https://issues.apache.org/jira/browse/PDFBOX-4892 > Project: PDFBox > Issue Type: Improvement >Affects Versions: 2.0.20 >Reporter: Tilman Hausherr >Priority: Minor > > This is a longterm issue for the task to improve code quality, by using the > [SonarQube report|https://sonarcloud.io/project/issues?id=pdfbox-reactor], > hints in different IDEs, the FindBugs tool and other code quality tools. > This is a follow-up of PDFBOX-4071, which was getting too long. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4892) Improve code quality (4)
[ https://issues.apache.org/jira/browse/PDFBOX-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406879#comment-17406879 ] ASF subversion and git services commented on PDFBOX-4892: - Commit 1892738 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1892738 ] PDFBOX-4892: always grow to maximum, as suggested by valerybokov; remove super() > Improve code quality (4) > > > Key: PDFBOX-4892 > URL: https://issues.apache.org/jira/browse/PDFBOX-4892 > Project: PDFBox > Issue Type: Improvement >Affects Versions: 2.0.20 >Reporter: Tilman Hausherr >Priority: Minor > > This is a longterm issue for the task to improve code quality, by using the > [SonarQube report|https://sonarcloud.io/project/issues?id=pdfbox-reactor], > hints in different IDEs, the FindBugs tool and other code quality tools. > This is a follow-up of PDFBOX-4071, which was getting too long. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5214) File generated differently depending on test call
[
https://issues.apache.org/jira/browse/PDFBOX-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406794#comment-17406794
]
ASF subversion and git services commented on PDFBOX-5214:
-
Commit 4ee4b5b55865dbd3f43d25f2d14fe6ebb2ccc4a6 in pdfbox-docs's branch
refs/heads/master from Andreas Lehmkühler
[ https://gitbox.apache.org/repos/asf?p=pdfbox-docs.git;h=4ee4b5b ]
PDFBOX-5214, PDFBOX-5030: add section about the removal of the static instances
of the standard 14 fonts
> File generated differently depending on test call
> -
>
> Key: PDFBOX-5214
> URL: https://issues.apache.org/jira/browse/PDFBOX-5214
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
>Affects Versions: 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: EmptySignatureForm_FullPackageTest.pdf,
> EmptySignatureForm_SingleClassTest.pdf
>
>
> Something weird is happening in {{TestCreateSignature.testPDFBox3978}}. The
> file {{EmptySignatureForm.pdf}} that is generated has different object
> streams depending on whether it is generated within a full test of the
> examples package, or if the {{TestCreateSignature}} class is tested. The two
> files should be identical except for the ID.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5030) Create Migration guide for 3.0.0
[ https://issues.apache.org/jira/browse/PDFBOX-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406795#comment-17406795 ] ASF subversion and git services commented on PDFBOX-5030: - Commit 4ee4b5b55865dbd3f43d25f2d14fe6ebb2ccc4a6 in pdfbox-docs's branch refs/heads/master from Andreas Lehmkühler [ https://gitbox.apache.org/repos/asf?p=pdfbox-docs.git;h=4ee4b5b ] PDFBOX-5214, PDFBOX-5030: add section about the removal of the static instances of the standard 14 fonts > Create Migration guide for 3.0.0 > > > Key: PDFBOX-5030 > URL: https://issues.apache.org/jira/browse/PDFBOX-5030 > Project: PDFBox > Issue Type: Task > Components: Documentation >Reporter: Maruan Sahyoun >Assignee: Maruan Sahyoun >Priority: Major > Fix For: 3.0.0 PDFBox > > > As to start educating about the migration efforts needed to get to 3.0.0 the > should be a migration guide (evolving over time) to prepare for the release -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406785#comment-17406785 ] Tilman Hausherr commented on PDFBOX-5268: - It searches on c:/Windows/fonts . You need the file msgothic.ttc . > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5268) Checkbox does not render in the png created for the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406742#comment-17406742 ] Joharat commented on PDFBOX-5268: - [~tilman], I do not have Zapf Dingbats, I do have MS Gothic Regular should that work. Do I need to tell PDF BOX where the fonts are located? If yes how do I do that? > Checkbox does not render in the png created for the attached pdf's > -- > > Key: PDFBOX-5268 > URL: https://issues.apache.org/jira/browse/PDFBOX-5268 > Project: PDFBox > Issue Type: Bug >Affects Versions: 3.0.0 PDFBox > Environment: Windows >Reporter: Joharat >Priority: Major > Attachments: OpenPDFBox_2.pdf, > OpenPDFBox_Test-by-Tilman-with-3.0-trunk.jpg, OpenPDFBox_Test.pdf, > rendering1.png, rendering1_checked.png > > > For the 2 attached pdf's when a png is created for the first page of the pdf > the check box does not translate over. The checkbox is empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5214) File generated differently depending on test call
[
https://issues.apache.org/jira/browse/PDFBOX-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406654#comment-17406654
]
ASF subversion and git services commented on PDFBOX-5214:
-
Commit 1892727 from le...@apache.org in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1892727 ]
PDFBOX-5214: replace static standard14font with a newly created one
> File generated differently depending on test call
> -
>
> Key: PDFBOX-5214
> URL: https://issues.apache.org/jira/browse/PDFBOX-5214
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
>Affects Versions: 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: EmptySignatureForm_FullPackageTest.pdf,
> EmptySignatureForm_SingleClassTest.pdf
>
>
> Something weird is happening in {{TestCreateSignature.testPDFBox3978}}. The
> file {{EmptySignatureForm.pdf}} that is generated has different object
> streams depending on whether it is generated within a full test of the
> examples package, or if the {{TestCreateSignature}} class is tested. The two
> files should be identical except for the ID.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5214) File generated differently depending on test call
[
https://issues.apache.org/jira/browse/PDFBOX-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406653#comment-17406653
]
ASF subversion and git services commented on PDFBOX-5214:
-
Commit 1892726 from le...@apache.org in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1892726 ]
PDFBOX-5214: remove static standard14font instances
> File generated differently depending on test call
> -
>
> Key: PDFBOX-5214
> URL: https://issues.apache.org/jira/browse/PDFBOX-5214
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
>Affects Versions: 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: EmptySignatureForm_FullPackageTest.pdf,
> EmptySignatureForm_SingleClassTest.pdf
>
>
> Something weird is happening in {{TestCreateSignature.testPDFBox3978}}. The
> file {{EmptySignatureForm.pdf}} that is generated has different object
> streams depending on whether it is generated within a full test of the
> examples package, or if the {{TestCreateSignature}} class is tested. The two
> files should be identical except for the ID.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5214) File generated differently depending on test call
[
https://issues.apache.org/jira/browse/PDFBOX-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406652#comment-17406652
]
ASF subversion and git services commented on PDFBOX-5214:
-
Commit 1892725 from le...@apache.org in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1892725 ]
PDFBOX-5214: replace static standard14font within test
> File generated differently depending on test call
> -
>
> Key: PDFBOX-5214
> URL: https://issues.apache.org/jira/browse/PDFBOX-5214
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
>Affects Versions: 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: EmptySignatureForm_FullPackageTest.pdf,
> EmptySignatureForm_SingleClassTest.pdf
>
>
> Something weird is happening in {{TestCreateSignature.testPDFBox3978}}. The
> file {{EmptySignatureForm.pdf}} that is generated has different object
> streams depending on whether it is generated within a full test of the
> examples package, or if the {{TestCreateSignature}} class is tested. The two
> files should be identical except for the ID.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5214) File generated differently depending on test call
[
https://issues.apache.org/jira/browse/PDFBOX-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406641#comment-17406641
]
ASF subversion and git services commented on PDFBOX-5214:
-
Commit 1892723 from le...@apache.org in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1892723 ]
PDFBOX-5214: replace static standard14font with a newly created one, use
Standard14Fonts.getAFM to load FontMetrics
> File generated differently depending on test call
> -
>
> Key: PDFBOX-5214
> URL: https://issues.apache.org/jira/browse/PDFBOX-5214
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
>Affects Versions: 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: EmptySignatureForm_FullPackageTest.pdf,
> EmptySignatureForm_SingleClassTest.pdf
>
>
> Something weird is happening in {{TestCreateSignature.testPDFBox3978}}. The
> file {{EmptySignatureForm.pdf}} that is generated has different object
> streams depending on whether it is generated within a full test of the
> examples package, or if the {{TestCreateSignature}} class is tested. The two
> files should be identical except for the ID.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5214) File generated differently depending on test call
[
https://issues.apache.org/jira/browse/PDFBOX-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406639#comment-17406639
]
ASF subversion and git services commented on PDFBOX-5214:
-
Commit 1892722 from le...@apache.org in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1892722 ]
PDFBOX-5214: replace static standard14font with a newly created one
> File generated differently depending on test call
> -
>
> Key: PDFBOX-5214
> URL: https://issues.apache.org/jira/browse/PDFBOX-5214
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
>Affects Versions: 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: EmptySignatureForm_FullPackageTest.pdf,
> EmptySignatureForm_SingleClassTest.pdf
>
>
> Something weird is happening in {{TestCreateSignature.testPDFBox3978}}. The
> file {{EmptySignatureForm.pdf}} that is generated has different object
> streams depending on whether it is generated within a full test of the
> examples package, or if the {{TestCreateSignature}} class is tested. The two
> files should be identical except for the ID.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5214) File generated differently depending on test call
[
https://issues.apache.org/jira/browse/PDFBOX-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406631#comment-17406631
]
ASF subversion and git services commented on PDFBOX-5214:
-
Commit 1892721 from le...@apache.org in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1892721 ]
PDFBOX-5214: provide a getter to get a FontBoxFont for all Standard 14 fonts
> File generated differently depending on test call
> -
>
> Key: PDFBOX-5214
> URL: https://issues.apache.org/jira/browse/PDFBOX-5214
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
>Affects Versions: 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: EmptySignatureForm_FullPackageTest.pdf,
> EmptySignatureForm_SingleClassTest.pdf
>
>
> Something weird is happening in {{TestCreateSignature.testPDFBox3978}}. The
> file {{EmptySignatureForm.pdf}} that is generated has different object
> streams depending on whether it is generated within a full test of the
> examples package, or if the {{TestCreateSignature}} class is tested. The two
> files should be identical except for the ID.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5214) File generated differently depending on test call
[
https://issues.apache.org/jira/browse/PDFBOX-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406627#comment-17406627
]
ASF subversion and git services commented on PDFBOX-5214:
-
Commit 1892720 from le...@apache.org in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1892720 ]
PDFBOX-5214: replace static standard14font with a newly created one
> File generated differently depending on test call
> -
>
> Key: PDFBOX-5214
> URL: https://issues.apache.org/jira/browse/PDFBOX-5214
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
>Affects Versions: 3.0.0 PDFBox
>Reporter: Tilman Hausherr
>Assignee: Andreas Lehmkühler
>Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: EmptySignatureForm_FullPackageTest.pdf,
> EmptySignatureForm_SingleClassTest.pdf
>
>
> Something weird is happening in {{TestCreateSignature.testPDFBox3978}}. The
> file {{EmptySignatureForm.pdf}} that is generated has different object
> streams depending on whether it is generated within a full test of the
> examples package, or if the {{TestCreateSignature}} class is tested. The two
> files should be identical except for the ID.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-5263) Suggestion: Signing actual document changes - Enhancing incremental saving
[ https://issues.apache.org/jira/browse/PDFBOX-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406598#comment-17406598 ] Christian Appl edited comment on PDFBOX-5263 at 8/30/21, 7:29 AM: -- *Update:* I had to redesign and rethink much of what I presented above, but I made some progress concerning this. I don't know whether I will make any progress this week concerning this issue, therefore I will upload the current suggestion. *This update:* [^Enhanced_incremental_saving_.patch] - Does not dereference objects, that have not been loaded by interactions with the user. (assuming such objects could not possibly have changed.) - It also does not change constructors of COS or PD objects - but still is keeping track of the parent document and update state. - It automatically includes changed and new objects in increments of that document. - It does not require the whole path to be updated, only including objects, that require inclusion. - The preexisting "hasToBeUpdated" logic remains functional and can be used to add objects to increments "manually". *Caveat:* There still is one remaining test failure, that I could not resolve yet and most likely won't find the time to fix this week. "pdfbox-examples:" TestCreateSignature.testPDFBox4784:763->signEncrypted:1051 » ArrayIndexOutOfBounds fails. *Current state:* Test failures are not acceptable, therefore the patch is not ready yet. But it adresses a lot of the initial issues and once the remaining issue is resolved (and the JavaDoc has been extended), this could be suggested for inclusion. was (Author: capsvd): *Update:* I had to redesign and rethink much of what I presented above, but I made some progress concerning this. I don't know whether I will make any progress this week concerning this issue, therefore I will upload the current suggestion. *This sugesstion:* [^Enhanced_incremental_saving_.patch] - Does not dereference objects, that have not been loaded by interactions with the user. (assuming such objects could not possibly have changed. - It also does not change constructors of COS or PD objects - but still keeping track of the document and update state. - It automatically includes changed and new objects in increments of that document. - It does not require the whole path to be updated, only including objects, that require inclusion. - The preexisting "hasToBeUpdated" logic remains functional and can be used to add objects to increments "manually". *Caveat:* There still is one remaining test failure, that I could not resolve yet and most likely won't find the time to fix this week. "pdfbox-examples:" TestCreateSignature.testPDFBox4784:763->signEncrypted:1051 » ArrayIndexOutOfBounds fails. *Current state:* Test failures are not acceptable, therefore the patch is not ready yet. But it adresses a lot of the initial issues and once the remaining issue is resolved (and the JavaDoc has been extended), this could be suggested for inclusion. > Suggestion: Signing actual document changes - Enhancing incremental saving > -- > > Key: PDFBOX-5263 > URL: https://issues.apache.org/jira/browse/PDFBOX-5263 > Project: PDFBox > Issue Type: Improvement > Components: Parsing, PDModel, Writing >Affects Versions: 3.0.0 PDFBox >Reporter: Christian Appl >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: Enhanced_incremental_saving_.patch, > Enhanced_incremental_saving_PDFBox3.patch, image-2021-08-23-14-55-24-077.png, > image-2021-08-26-09-52-33-567.png, image-2021-08-26-09-54-24-897.png, > image-2021-08-26-10-00-07-383.png, image-2021-08-26-10-02-08-003.png, > image-2021-08-26-10-03-47-940.png, image-2021-08-26-10-06-42-925.png, > image-2021-08-26-10-09-12-698.png, image-2021-08-26-10-12-19-265.png > > > *TL;DR:* > Currently it is rather tedious to create incremental changes in between > signatures via PDFBox. I attempted to simplify that and wrote a patch. > This is rather a POC, than an actual suggestion for direct inclusion. (For > reasons explained later.) > *Signatures and incremental PDF documents:* > A typical reason for wanting to sign a document multiple times (creating an > incremental PDF) is , that in between signatures the document changed and the > additional signature shall sign the new state of the document. > If one wanted to implement such incremental changes using PDFBox, he would > find, that most of the time made changes are completly ignored, when calling > "saveIncremental". > As documented for the "saveIncremental" methods and especially the matching > constructors in "COSWriter", this would require, to identify the "path" of > all made changes and one would need to set the "needToBeUpdated" flag of all > elements
[jira] [Commented] (PDFBOX-5263) Suggestion: Signing actual document changes - Enhancing incremental saving
[ https://issues.apache.org/jira/browse/PDFBOX-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406598#comment-17406598 ] Christian Appl commented on PDFBOX-5263: *Update:* I had to redesign and rethink much of what I presented above, but I made some progress concerning this. I don't know whether I will make any progress this week concerning this issue, therefore I will upload the current suggestion. *This sugesstion:* [^Enhanced_incremental_saving_.patch] - Does not dereference objects, that have not been loaded by interactions with the user. (assuming such objects could not possibly have changed. - It also does not change constructors of COS or PD objects - but still keeping track of the document and update state. - It automatically includes changed and new objects in increments of that document. - It does not require the whole path to be updated, only including objects, that require inclusion. - The preexisting "hasToBeUpdated" logic remains functional and can be used to add objects to increments "manually". *Caveat:* There still is one remaining test failure, that I could not resolve yet and most likely won't find the time to fix this week. "pdfbox-examples:" TestCreateSignature.testPDFBox4784:763->signEncrypted:1051 » ArrayIndexOutOfBounds fails. *Current state:* Test failures are not acceptable, therefore the patch is not ready yet. But it adresses a lot of the initial issues and once the remaining issue is resolved (and the JavaDoc has been extended), this could be suggested for inclusion. > Suggestion: Signing actual document changes - Enhancing incremental saving > -- > > Key: PDFBOX-5263 > URL: https://issues.apache.org/jira/browse/PDFBOX-5263 > Project: PDFBox > Issue Type: Improvement > Components: Parsing, PDModel, Writing >Affects Versions: 3.0.0 PDFBox >Reporter: Christian Appl >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: Enhanced_incremental_saving_.patch, > Enhanced_incremental_saving_PDFBox3.patch, image-2021-08-23-14-55-24-077.png, > image-2021-08-26-09-52-33-567.png, image-2021-08-26-09-54-24-897.png, > image-2021-08-26-10-00-07-383.png, image-2021-08-26-10-02-08-003.png, > image-2021-08-26-10-03-47-940.png, image-2021-08-26-10-06-42-925.png, > image-2021-08-26-10-09-12-698.png, image-2021-08-26-10-12-19-265.png > > > *TL;DR:* > Currently it is rather tedious to create incremental changes in between > signatures via PDFBox. I attempted to simplify that and wrote a patch. > This is rather a POC, than an actual suggestion for direct inclusion. (For > reasons explained later.) > *Signatures and incremental PDF documents:* > A typical reason for wanting to sign a document multiple times (creating an > incremental PDF) is , that in between signatures the document changed and the > additional signature shall sign the new state of the document. > If one wanted to implement such incremental changes using PDFBox, he would > find, that most of the time made changes are completly ignored, when calling > "saveIncremental". > As documented for the "saveIncremental" methods and especially the matching > constructors in "COSWriter", this would require, to identify the "path" of > all made changes and one would need to set the "needToBeUpdated" flag of all > elements of that path. > *But:* > As documented one would have to have exact understanding of what he did and > how the PDF standard does implement this, he would have to identify said > structures and the more complex the changes were, the more tedious this would > become. > *Also:* > Because of the implementation of incremental saving in COSWriter, the whole > path must be informed that it required an update. > Resulting in unnecessary large increments, as not all ancestors might > actually have changed. > e.g. If one added an image to a preexisting page of the document - the > contentstream, the resources of the page and the page dictionary would have > changed. But the "pages" array and all it's ancestors would not have changed > a bit, but still would have to be informed and included. > *Assumptions that lead to this patch:* > - COSWriter should not stop iterating a COSTree just because a parent element > did not change. It's descendants still could have changed! > - Externally managing an object´s update state is tedious and error-prone. > Objects that implement "COSUpdateInfo" should know and manage by themselves > whether they were freshly created or altered > (e.g.: A COSDictionary should be able to remember, that a setter had been > called). > - If "COSUpdateInfo" objects were self aware and would solve this by > themselves, it would not be necessary anymore to set update states manually. > *Problems:* > The first and obvious
[jira] [Updated] (PDFBOX-5263) Suggestion: Signing actual document changes - Enhancing incremental saving
[ https://issues.apache.org/jira/browse/PDFBOX-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Appl updated PDFBOX-5263: --- Attachment: Enhanced_incremental_saving_.patch > Suggestion: Signing actual document changes - Enhancing incremental saving > -- > > Key: PDFBOX-5263 > URL: https://issues.apache.org/jira/browse/PDFBOX-5263 > Project: PDFBox > Issue Type: Improvement > Components: Parsing, PDModel, Writing >Affects Versions: 3.0.0 PDFBox >Reporter: Christian Appl >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: Enhanced_incremental_saving_.patch, > Enhanced_incremental_saving_PDFBox3.patch, image-2021-08-23-14-55-24-077.png, > image-2021-08-26-09-52-33-567.png, image-2021-08-26-09-54-24-897.png, > image-2021-08-26-10-00-07-383.png, image-2021-08-26-10-02-08-003.png, > image-2021-08-26-10-03-47-940.png, image-2021-08-26-10-06-42-925.png, > image-2021-08-26-10-09-12-698.png, image-2021-08-26-10-12-19-265.png > > > *TL;DR:* > Currently it is rather tedious to create incremental changes in between > signatures via PDFBox. I attempted to simplify that and wrote a patch. > This is rather a POC, than an actual suggestion for direct inclusion. (For > reasons explained later.) > *Signatures and incremental PDF documents:* > A typical reason for wanting to sign a document multiple times (creating an > incremental PDF) is , that in between signatures the document changed and the > additional signature shall sign the new state of the document. > If one wanted to implement such incremental changes using PDFBox, he would > find, that most of the time made changes are completly ignored, when calling > "saveIncremental". > As documented for the "saveIncremental" methods and especially the matching > constructors in "COSWriter", this would require, to identify the "path" of > all made changes and one would need to set the "needToBeUpdated" flag of all > elements of that path. > *But:* > As documented one would have to have exact understanding of what he did and > how the PDF standard does implement this, he would have to identify said > structures and the more complex the changes were, the more tedious this would > become. > *Also:* > Because of the implementation of incremental saving in COSWriter, the whole > path must be informed that it required an update. > Resulting in unnecessary large increments, as not all ancestors might > actually have changed. > e.g. If one added an image to a preexisting page of the document - the > contentstream, the resources of the page and the page dictionary would have > changed. But the "pages" array and all it's ancestors would not have changed > a bit, but still would have to be informed and included. > *Assumptions that lead to this patch:* > - COSWriter should not stop iterating a COSTree just because a parent element > did not change. It's descendants still could have changed! > - Externally managing an object´s update state is tedious and error-prone. > Objects that implement "COSUpdateInfo" should know and manage by themselves > whether they were freshly created or altered > (e.g.: A COSDictionary should be able to remember, that a setter had been > called). > - If "COSUpdateInfo" objects were self aware and would solve this by > themselves, it would not be necessary anymore to set update states manually. > *Problems:* > The first and obvious problem is, that the initial loading of a document is > creating and altering new COS structures and we obviously don't want objects > to observe and remember those changes. An object that is created during > document initialization must be treated as preexisting. > However: COSBase is not context aware - it does know it's descendants, but > neither does it know it's parent, nor does it know it's root. > If it was, that actually would present the optimal solution, as in that case > the Object could ask it's root for the current load state and therefore would > be able to ignore said changes caused by the initial loading of a document. > But it is not. (My opinion is - it should be! But more on that later.) > Therefore a a helper named COSUpdateInfoList was implemented, which was > capable of finding COSUpdateInfo objects in a COS structure, and that allowed > resetting their update state after loading was completed. > *Description of the patch:* > The patch implements selfaware COSUpdateInfo objects, which the COSWriter has > been adapted to process. PDFBox therefore is capable of monitoring changes in > realtime and to automatically include altered structures in an incremental > save of the document, therefore creating increments (or an increment), that a > signature would sign. > *Result:* > Using this patch documents could be
[jira] [Updated] (PDFBOX-5263) Suggestion: Signing actual document changes - Enhancing incremental saving
[ https://issues.apache.org/jira/browse/PDFBOX-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Appl updated PDFBOX-5263: --- Attachment: Enhanced_incremental_saving_.patch > Suggestion: Signing actual document changes - Enhancing incremental saving > -- > > Key: PDFBOX-5263 > URL: https://issues.apache.org/jira/browse/PDFBOX-5263 > Project: PDFBox > Issue Type: Improvement > Components: Parsing, PDModel, Writing >Affects Versions: 3.0.0 PDFBox >Reporter: Christian Appl >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: Enhanced_incremental_saving_PDFBox3.patch, > image-2021-08-23-14-55-24-077.png, image-2021-08-26-09-52-33-567.png, > image-2021-08-26-09-54-24-897.png, image-2021-08-26-10-00-07-383.png, > image-2021-08-26-10-02-08-003.png, image-2021-08-26-10-03-47-940.png, > image-2021-08-26-10-06-42-925.png, image-2021-08-26-10-09-12-698.png, > image-2021-08-26-10-12-19-265.png > > > *TL;DR:* > Currently it is rather tedious to create incremental changes in between > signatures via PDFBox. I attempted to simplify that and wrote a patch. > This is rather a POC, than an actual suggestion for direct inclusion. (For > reasons explained later.) > *Signatures and incremental PDF documents:* > A typical reason for wanting to sign a document multiple times (creating an > incremental PDF) is , that in between signatures the document changed and the > additional signature shall sign the new state of the document. > If one wanted to implement such incremental changes using PDFBox, he would > find, that most of the time made changes are completly ignored, when calling > "saveIncremental". > As documented for the "saveIncremental" methods and especially the matching > constructors in "COSWriter", this would require, to identify the "path" of > all made changes and one would need to set the "needToBeUpdated" flag of all > elements of that path. > *But:* > As documented one would have to have exact understanding of what he did and > how the PDF standard does implement this, he would have to identify said > structures and the more complex the changes were, the more tedious this would > become. > *Also:* > Because of the implementation of incremental saving in COSWriter, the whole > path must be informed that it required an update. > Resulting in unnecessary large increments, as not all ancestors might > actually have changed. > e.g. If one added an image to a preexisting page of the document - the > contentstream, the resources of the page and the page dictionary would have > changed. But the "pages" array and all it's ancestors would not have changed > a bit, but still would have to be informed and included. > *Assumptions that lead to this patch:* > - COSWriter should not stop iterating a COSTree just because a parent element > did not change. It's descendants still could have changed! > - Externally managing an object´s update state is tedious and error-prone. > Objects that implement "COSUpdateInfo" should know and manage by themselves > whether they were freshly created or altered > (e.g.: A COSDictionary should be able to remember, that a setter had been > called). > - If "COSUpdateInfo" objects were self aware and would solve this by > themselves, it would not be necessary anymore to set update states manually. > *Problems:* > The first and obvious problem is, that the initial loading of a document is > creating and altering new COS structures and we obviously don't want objects > to observe and remember those changes. An object that is created during > document initialization must be treated as preexisting. > However: COSBase is not context aware - it does know it's descendants, but > neither does it know it's parent, nor does it know it's root. > If it was, that actually would present the optimal solution, as in that case > the Object could ask it's root for the current load state and therefore would > be able to ignore said changes caused by the initial loading of a document. > But it is not. (My opinion is - it should be! But more on that later.) > Therefore a a helper named COSUpdateInfoList was implemented, which was > capable of finding COSUpdateInfo objects in a COS structure, and that allowed > resetting their update state after loading was completed. > *Description of the patch:* > The patch implements selfaware COSUpdateInfo objects, which the COSWriter has > been adapted to process. PDFBox therefore is capable of monitoring changes in > realtime and to automatically include altered structures in an incremental > save of the document, therefore creating increments (or an increment), that a > signature would sign. > *Result:* > Using this patch documents could be created: > incrementally adding
[jira] [Updated] (PDFBOX-5263) Suggestion: Signing actual document changes - Enhancing incremental saving
[ https://issues.apache.org/jira/browse/PDFBOX-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Appl updated PDFBOX-5263: --- Attachment: (was: Enhanced_incremental_saving_.patch) > Suggestion: Signing actual document changes - Enhancing incremental saving > -- > > Key: PDFBOX-5263 > URL: https://issues.apache.org/jira/browse/PDFBOX-5263 > Project: PDFBox > Issue Type: Improvement > Components: Parsing, PDModel, Writing >Affects Versions: 3.0.0 PDFBox >Reporter: Christian Appl >Priority: Major > Fix For: 3.0.0 PDFBox > > Attachments: Enhanced_incremental_saving_PDFBox3.patch, > image-2021-08-23-14-55-24-077.png, image-2021-08-26-09-52-33-567.png, > image-2021-08-26-09-54-24-897.png, image-2021-08-26-10-00-07-383.png, > image-2021-08-26-10-02-08-003.png, image-2021-08-26-10-03-47-940.png, > image-2021-08-26-10-06-42-925.png, image-2021-08-26-10-09-12-698.png, > image-2021-08-26-10-12-19-265.png > > > *TL;DR:* > Currently it is rather tedious to create incremental changes in between > signatures via PDFBox. I attempted to simplify that and wrote a patch. > This is rather a POC, than an actual suggestion for direct inclusion. (For > reasons explained later.) > *Signatures and incremental PDF documents:* > A typical reason for wanting to sign a document multiple times (creating an > incremental PDF) is , that in between signatures the document changed and the > additional signature shall sign the new state of the document. > If one wanted to implement such incremental changes using PDFBox, he would > find, that most of the time made changes are completly ignored, when calling > "saveIncremental". > As documented for the "saveIncremental" methods and especially the matching > constructors in "COSWriter", this would require, to identify the "path" of > all made changes and one would need to set the "needToBeUpdated" flag of all > elements of that path. > *But:* > As documented one would have to have exact understanding of what he did and > how the PDF standard does implement this, he would have to identify said > structures and the more complex the changes were, the more tedious this would > become. > *Also:* > Because of the implementation of incremental saving in COSWriter, the whole > path must be informed that it required an update. > Resulting in unnecessary large increments, as not all ancestors might > actually have changed. > e.g. If one added an image to a preexisting page of the document - the > contentstream, the resources of the page and the page dictionary would have > changed. But the "pages" array and all it's ancestors would not have changed > a bit, but still would have to be informed and included. > *Assumptions that lead to this patch:* > - COSWriter should not stop iterating a COSTree just because a parent element > did not change. It's descendants still could have changed! > - Externally managing an object´s update state is tedious and error-prone. > Objects that implement "COSUpdateInfo" should know and manage by themselves > whether they were freshly created or altered > (e.g.: A COSDictionary should be able to remember, that a setter had been > called). > - If "COSUpdateInfo" objects were self aware and would solve this by > themselves, it would not be necessary anymore to set update states manually. > *Problems:* > The first and obvious problem is, that the initial loading of a document is > creating and altering new COS structures and we obviously don't want objects > to observe and remember those changes. An object that is created during > document initialization must be treated as preexisting. > However: COSBase is not context aware - it does know it's descendants, but > neither does it know it's parent, nor does it know it's root. > If it was, that actually would present the optimal solution, as in that case > the Object could ask it's root for the current load state and therefore would > be able to ignore said changes caused by the initial loading of a document. > But it is not. (My opinion is - it should be! But more on that later.) > Therefore a a helper named COSUpdateInfoList was implemented, which was > capable of finding COSUpdateInfo objects in a COS structure, and that allowed > resetting their update state after loading was completed. > *Description of the patch:* > The patch implements selfaware COSUpdateInfo objects, which the COSWriter has > been adapted to process. PDFBox therefore is capable of monitoring changes in > realtime and to automatically include altered structures in an incremental > save of the document, therefore creating increments (or an increment), that a > signature would sign. > *Result:* > Using this patch documents could be created: > incrementally
