[jira] [Commented] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-2269:
-

Test file is in PDFBOX-423.

> Support for AES-256 Rev. 5 Decryption (Acrobat 9)
> -
>
> Key: PDFBOX-2269
> URL: https://issues.apache.org/jira/browse/PDFBOX-2269
> Project: PDFBox
>  Issue Type: Improvement
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Michele Balistreri
> Attachments: AES-256_Rev5.diff
>
>
> This patch adds support for decrypting files using the (deprecated) AES-256 
> scheme revision 5. The current version only support revision 6. Since 
> revision 5 files are generated by Acrobat 9, there is a relatively large 
> amount of them in the wild so support is needed.
> This patch includes also the fixes from PDFBOX-2268



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (PDFBOX-2224) Unsupported Encryption Revision 5

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr closed PDFBOX-2224.
---

Resolution: Duplicate

Will be solved by PDFBOX-2269.

> Unsupported Encryption Revision 5
> -
>
> Key: PDFBOX-2224
> URL: https://issues.apache.org/jira/browse/PDFBOX-2224
> Project: PDFBox
>  Issue Type: New Feature
>  Components: Parsing
>Affects Versions: 2.0.0
>Reporter: simon steiner
>
> From the file in from PDFBOX-423:
> java -jar pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> pass17.pdf
> Exception in thread "main" java.io.IOException: Unsupported Encryption 
> Revision 5



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2261) Extremely long hang during getFields() on a few PDF files

[Tim Allison (JIRA)]

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

Tim Allison commented on PDFBOX-2261:
-

When I throw a RuntimeException after 10,000 PDRadioButtons have been 
initialized, this is what I get.  I wonder if there's a circular reference?

{noformat}
at 
org.apache.pdfbox.pdmodel.interactive.form.PDRadioButton.(PDRadioButton.java:51)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:71)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:543)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:123)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:123)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:123)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:123)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:123)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFieldFactory.java:56)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDField.getKids(PDField.java:555)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.isButton(PDFieldFactory.java:115)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDFieldFactory.createField(PDFie

Build failed in Jenkins: PDFBox-ant #1491

[Apache Jenkins Server]

See 

--
[...truncated 226 lines...]
at 
org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createPlainSocket(SVNSocketFactory.java:73)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.connect(HTTPConnection.java:280)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:451)
... 35 more
ERROR: Subversion update failed
java.io.IOException: remote file operation failed: 
 at 
hudson.remoting.Channel@52d6c4b:ubuntu-5
at hudson.FilePath.act(FilePath.java:910)
at hudson.FilePath.act(FilePath.java:887)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:936)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:871)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
at hudson.model.Run.execute(Run.java:1676)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: java.io.IOException
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:211)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2462)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: hudson.scm.subversion.UpdaterException: failed to perform svn update
... 14 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS 
/repos/asf/pdfbox/trunk failed
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339)
at 
org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at 
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at 
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157)
.

[jira] [Commented] (PDFBOX-2249) Listbox controls render incorrectly

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-2249:
-

Here's one:
http://www.pdfill.com/example/pdf_form_maker_new.pdf


> Listbox controls render incorrectly
> ---
>
> Key: PDFBOX-2249
> URL: https://issues.apache.org/jira/browse/PDFBOX-2249
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 1.8.6
> Environment: Windows 7
>Reporter: John McDonald
>Assignee: Maruan Sahyoun
>  Labels: Appearance
> Fix For: 1.8.7
>
> Attachments: JMACTest.pdf, JMAC_PDFBOX_out.pdf, ListboxAcrobat.png, 
> ListboxPDFBox.png, PDFBoxUtil.java, PDFFormFields.pdf
>
>
> I have a form with a listbox.  I update the value in the listbox using the 
> following code:
>   PDChoiceField c = (PDChoiceField)f;
>   ((PDChoiceField)f).setValue("2");
> I have a combo box that uses the same choices, and it works fine.  The issue 
> has to do with the rendering of the field.  The update of the value (i.e. 
> setValue method) works fine, but when I look at the resulting output PDF the 
> choices have become unreadable because the font has gone way large.
> I have searched the mailing list, and posted a question regarding this that 
> no one has answered, so I am now assuming this is an unknown bug.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2249) Listbox controls render incorrectly

[John McDonald (JIRA)]

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

John McDonald commented on PDFBOX-2249:
---

Sorry to say, I have only the original form I reported the problem with.

John

> Listbox controls render incorrectly
> ---
>
> Key: PDFBOX-2249
> URL: https://issues.apache.org/jira/browse/PDFBOX-2249
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 1.8.6
> Environment: Windows 7
>Reporter: John McDonald
>Assignee: Maruan Sahyoun
>  Labels: Appearance
> Fix For: 1.8.7
>
> Attachments: JMACTest.pdf, JMAC_PDFBOX_out.pdf, ListboxAcrobat.png, 
> ListboxPDFBox.png, PDFBoxUtil.java, PDFFormFields.pdf
>
>
> I have a form with a listbox.  I update the value in the listbox using the 
> following code:
>   PDChoiceField c = (PDChoiceField)f;
>   ((PDChoiceField)f).setValue("2");
> I have a combo box that uses the same choices, and it works fine.  The issue 
> has to do with the rendering of the field.  The update of the value (i.e. 
> setValue method) works fine, but when I look at the resulting output PDF the 
> choices have become unreadable because the font has gone way large.
> I have searched the mailing list, and posted a question regarding this that 
> no one has answered, so I am now assuming this is an unknown bug.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2249) Listbox controls render incorrectly

[Maruan Sahyoun (JIRA)]

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

Maruan Sahyoun updated PDFBOX-2249:
---

Attachment: ListboxPDFBox.png
ListboxAcrobat.png

Sample ListboxAcrobat as displayed by Adobe Acrobat
Sample ListboxPDF after changing the listbox selection in PDFBox 

> Listbox controls render incorrectly
> ---
>
> Key: PDFBOX-2249
> URL: https://issues.apache.org/jira/browse/PDFBOX-2249
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 1.8.6
> Environment: Windows 7
>Reporter: John McDonald
>Assignee: Maruan Sahyoun
>  Labels: Appearance
> Fix For: 1.8.7
>
> Attachments: JMACTest.pdf, JMAC_PDFBOX_out.pdf, ListboxAcrobat.png, 
> ListboxPDFBox.png, PDFBoxUtil.java, PDFFormFields.pdf
>
>
> I have a form with a listbox.  I update the value in the listbox using the 
> following code:
>   PDChoiceField c = (PDChoiceField)f;
>   ((PDChoiceField)f).setValue("2");
> I have a combo box that uses the same choices, and it works fine.  The issue 
> has to do with the rendering of the field.  The update of the value (i.e. 
> setValue method) works fine, but when I look at the resulting output PDF the 
> choices have become unreadable because the font has gone way large.
> I have searched the mailing list, and posted a question regarding this that 
> no one has answered, so I am now assuming this is an unknown bug.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2261) Extremely long hang during getFields() on a few PDF files

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-2261:
-

Yes please do. What I did last week was to run in debug mode, then pressed 
pause. I saw about 20 identical recursive calls. I didn't test whether it runs 
forever or not.

> Extremely long hang during getFields() on a few PDF files
> -
>
> Key: PDFBOX-2261
> URL: https://issues.apache.org/jira/browse/PDFBOX-2261
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 1.8.6
>Reporter: Tim Allison
>Priority: Minor
> Attachments: 966679.pdf, screenshot-pdfdebugger.png
>
>
> When I run oap.examples.fdf.PrintFields from trunk, the code seems to hang 
> during acroForm.getFields().  This is a heavy load hang.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2249) Listbox controls render incorrectly

[Maruan Sahyoun (JIRA)]

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

Maruan Sahyoun commented on PDFBOX-2249:


I’ve fixed the list box appearance stream generation for the sample PDF in my 
working copy. The result looks similar to what Adobe Acrobat displays.

I have a very limited number of AcroForms for testing so if someone could point 
me to and/or provide additional sample forms that would be great. The fix is 
for 1.8 only at that point in time as it’s duplicating a lot of code and 
addresses the listbox only.

> Listbox controls render incorrectly
> ---
>
> Key: PDFBOX-2249
> URL: https://issues.apache.org/jira/browse/PDFBOX-2249
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 1.8.6
> Environment: Windows 7
>Reporter: John McDonald
>Assignee: Maruan Sahyoun
>  Labels: Appearance
> Fix For: 1.8.7
>
> Attachments: JMACTest.pdf, JMAC_PDFBOX_out.pdf, PDFBoxUtil.java, 
> PDFFormFields.pdf
>
>
> I have a form with a listbox.  I update the value in the listbox using the 
> following code:
>   PDChoiceField c = (PDChoiceField)f;
>   ((PDChoiceField)f).setValue("2");
> I have a combo box that uses the same choices, and it works fine.  The issue 
> has to do with the rendering of the field.  The update of the value (i.e. 
> setValue method) works fine, but when I look at the resulting output PDF the 
> choices have become unreadable because the font has gone way large.
> I have searched the mailing list, and posted a question regarding this that 
> no one has answered, so I am now assuming this is an unknown bug.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2261) Extremely long hang during getFields() on a few PDF files

[Maruan Sahyoun (JIRA)]

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

Maruan Sahyoun commented on PDFBOX-2261:


This looks quite complex for what should be plain form fields, although it’s 
valid. I can look into it later this week if no one else wants to before.

> Extremely long hang during getFields() on a few PDF files
> -
>
> Key: PDFBOX-2261
> URL: https://issues.apache.org/jira/browse/PDFBOX-2261
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 1.8.6
>Reporter: Tim Allison
>Priority: Minor
> Attachments: 966679.pdf, screenshot-pdfdebugger.png
>
>
> When I run oap.examples.fdf.PrintFields from trunk, the code seems to hang 
> during acroForm.getFields().  This is a heavy load hang.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2261) Extremely long hang during getFields() on a few PDF files

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2261:


Attachment: screenshot-pdfdebugger.png

Here's a screenshot, that shows what I have to do to see the first few fields.

> Extremely long hang during getFields() on a few PDF files
> -
>
> Key: PDFBOX-2261
> URL: https://issues.apache.org/jira/browse/PDFBOX-2261
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 1.8.6
>Reporter: Tim Allison
>Priority: Minor
> Attachments: 966679.pdf, screenshot-pdfdebugger.png
>
>
> When I run oap.examples.fdf.PrintFields from trunk, the code seems to hang 
> during acroForm.getFields().  This is a heavy load hang.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[JIRA]

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

Andreas Lehmkühler commented on PDFBOX-2250:


Thanks for the fast feedback, I'll have a look

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-2250) Improve XRef self healing mechanism

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr edited comment on PDFBOX-2250 at 8/11/14 7:51 PM:
--

These files can no longer be opened with the nonsequential parser:
- PDFBOX-1577 ("Missing root object specification in trailer")
- PDFBOX-1756 ("Catalog cannot be found")
- PDFBOX-2251 ("Missing root object specification in trailer")
- PDFBOX-1512 (immo-kurier_arsenal_93x62.pdf) "Missing root object 
specification in trailer"
- test-landscape2.pdf ("Missing root object specification in trailer")



was (Author: tilman):
These files can no longer be opened with the nonsequential parser:
- PDFBOX-1577 ("Missing root object specification in trailer")
- PDFBOX-1756 ("Catalog cannot be found")
- PDFBOX-2251 ("Missing root object specification in trailer")
- PDFBOX-1512 (immo-kurier_arsenal_93x62.pdf) "Missing root object 
specification in trailer"



> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-2250:
-

These files can no longer be opened with the nonsequential parser:
- PDFBOX-1577 ("Missing root object specification in trailer")
- PDFBOX-1756 ("Catalog cannot be found")
- PDFBOX-2251 ("Missing root object specification in trailer")
- PDFBOX-1512 (immo-kurier_arsenal_93x62.pdf) "Missing root object 
specification in trailer"



> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[JIRA]

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

Andreas Lehmkühler commented on PDFBOX-2250:


[~tchojecki] I'm aware of that "feature". But that was more a brute force 
search. The non sequential parser is following the spec a relies on the 
xref-table itself. This issues targets some of the known problems such as wrong 
offsets. The bugfix/improvement for compress objects was just a sideproduct as 
I stumbeld upon that missing part.

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[JIRA]

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

Andreas Lehmkühler commented on PDFBOX-2250:


[~tilman] I should have be more specific. Use PDFDebugger and have a look at 
the root node. There isn't any StructTreeRoot when using the non sequential 
parser without my changes

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-2250:
-

How/where can I see the difference between before and after for the sample PDF? 
Should the rendering be different, or something else?

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)

[Michele Balistreri (JIRA)]

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

Michele Balistreri updated PDFBOX-2269:
---

Affects Version/s: 2.0.0

> Support for AES-256 Rev. 5 Decryption (Acrobat 9)
> -
>
> Key: PDFBOX-2269
> URL: https://issues.apache.org/jira/browse/PDFBOX-2269
> Project: PDFBox
>  Issue Type: Improvement
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Michele Balistreri
> Attachments: AES-256_Rev5.diff
>
>
> This patch adds support for decrypting files using the (deprecated) AES-256 
> scheme revision 5. The current version only support revision 6. Since 
> revision 5 files are generated by Acrobat 9, there is a relatively large 
> amount of them in the wild so support is needed.
> This patch includes also the fixes from PDFBOX-2268



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)

[Michele Balistreri (JIRA)]

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

Michele Balistreri updated PDFBOX-2269:
---

Component/s: PDModel

> Support for AES-256 Rev. 5 Decryption (Acrobat 9)
> -
>
> Key: PDFBOX-2269
> URL: https://issues.apache.org/jira/browse/PDFBOX-2269
> Project: PDFBox
>  Issue Type: Improvement
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Michele Balistreri
> Attachments: AES-256_Rev5.diff
>
>
> This patch adds support for decrypting files using the (deprecated) AES-256 
> scheme revision 5. The current version only support revision 6. Since 
> revision 5 files are generated by Acrobat 9, there is a relatively large 
> amount of them in the wild so support is needed.
> This patch includes also the fixes from PDFBOX-2268



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)

[Michele Balistreri (JIRA)]

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

Michele Balistreri updated PDFBOX-2269:
---

Attachment: AES-256_Rev5.diff

> Support for AES-256 Rev. 5 Decryption (Acrobat 9)
> -
>
> Key: PDFBOX-2269
> URL: https://issues.apache.org/jira/browse/PDFBOX-2269
> Project: PDFBox
>  Issue Type: Improvement
>Reporter: Michele Balistreri
> Attachments: AES-256_Rev5.diff
>
>
> This patch adds support for decrypting files using the (deprecated) AES-256 
> scheme revision 5. The current version only support revision 6. Since 
> revision 5 files are generated by Acrobat 9, there is a relatively large 
> amount of them in the wild so support is needed.
> This patch includes also the fixes from PDFBOX-2268



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)

[Michele Balistreri (JIRA)]

Michele Balistreri created PDFBOX-2269:
--

 Summary: Support for AES-256 Rev. 5 Decryption (Acrobat 9)
 Key: PDFBOX-2269
 URL: https://issues.apache.org/jira/browse/PDFBOX-2269
 Project: PDFBox
  Issue Type: Improvement
Reporter: Michele Balistreri
 Attachments: AES-256_Rev5.diff

This patch adds support for decrypting files using the (deprecated) AES-256 
scheme revision 5. The current version only support revision 6. Since revision 
5 files are generated by Acrobat 9, there is a relatively large amount of them 
in the wild so support is needed.

This patch includes also the fixes from PDFBOX-2286



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)

[Michele Balistreri (JIRA)]

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

Michele Balistreri updated PDFBOX-2269:
---

Description: 
This patch adds support for decrypting files using the (deprecated) AES-256 
scheme revision 5. The current version only support revision 6. Since revision 
5 files are generated by Acrobat 9, there is a relatively large amount of them 
in the wild so support is needed.

This patch includes also the fixes from PDFBOX-2268

  was:
This patch adds support for decrypting files using the (deprecated) AES-256 
scheme revision 5. The current version only support revision 6. Since revision 
5 files are generated by Acrobat 9, there is a relatively large amount of them 
in the wild so support is needed.

This patch includes also the fixes from PDFBOX-2286


> Support for AES-256 Rev. 5 Decryption (Acrobat 9)
> -
>
> Key: PDFBOX-2269
> URL: https://issues.apache.org/jira/browse/PDFBOX-2269
> Project: PDFBox
>  Issue Type: Improvement
>Reporter: Michele Balistreri
> Attachments: AES-256_Rev5.diff
>
>
> This patch adds support for decrypting files using the (deprecated) AES-256 
> scheme revision 5. The current version only support revision 6. Since 
> revision 5 files are generated by Acrobat 9, there is a relatively large 
> amount of them in the wild so support is needed.
> This patch includes also the fixes from PDFBOX-2268



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[Thomas Chojecki (JIRA)]

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

Thomas Chojecki commented on PDFBOX-2250:
-

[~lehmi]
"All fixes and improvements are targeting the non-sequential parser and I won't 
port those changes to the old parser."

The old parser already has this feature or similar one as I remember. This was 
needed as fix for a third party lib that creates documents that have a miss 
matched offset by 2 or 3 bytes. You can find it in the PDFParser class line 923 
(resolveConflicts). 
https://github.com/apache/pdfbox/blob/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdfparser/PDFParser.java#L923

I don't have read the whole coversation, but you wrote something of 200 bytes 
self healing range. This can cause problems with pdfs that are broken and 
include pdf documents as file attachment. The flatdecode algorithm sometimes 
does not compress each block, so it will leave some plaintext pdf blocks whick 
can contain parts like "endstream" or "endobj". In this case it can happen that 
the self healing algorithm runs into such an uncompressed block and fail 
reading the object.

I hope you understand what I mean :-) 

PS: some offtopic things. I think the signature implementation only work with 
the old parser. So maybe someone can post this info on the website if the 
default parser implementation change.

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[JIRA]

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

Andreas Lehmkühler commented on PDFBOX-2250:


In contrast to the old parser the non-sequential one didn't parse 
cross-reference streams. I've added that feature so that especially object 
references for compressed objects could be found now.

This should improve the parser once more if it comes to pdfs using object 
streams. I've used this [sample 
pdf|http://bewerbung.fh-kaernten.at/fileadmin/Anleitung-PDF-erstellen.pdf]  
provided by Martin Tappler on dev@pdfboxf

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2250) Improve XRef self healing mechanism

[JIRA]

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

Andreas Lehmkühler updated PDFBOX-2250:
---

Description: 
PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
offsets. But that one was just a starter and there remain a lot of issues to be 
solved. I'm planing to solve at least some of them.

All fixes and improvements are targeting the non-sequential parser and I won't 
port those changes to the old parser.

  was:
PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
offsets. But that one was just a starter and there remain a lot of issues to be 
solved.
I'm planing to solve at least some of them.


> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved. I'm planing to solve at least some of them.
> All fixes and improvements are targeting the non-sequential parser and I 
> won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[ASF subversion and git services (JIRA)]

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

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

Commit 1617340 from [~lehmi] in branch 'pdfbox/branches/1.8'
[ https://svn.apache.org/r1617340 ]

PDFBOX-2250: parse an optional cross-reference stream to get object numbers for 
compressed objects as well

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved.
> I'm planing to solve at least some of them.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

[ASF subversion and git services (JIRA)]

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

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

Commit 1617339 from [~lehmi] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1617339 ]

PDFBOX-2250: parse an optional cross-reference stream to get object numbers for 
compressed objects as well

> Improve XRef self healing mechanism
> ---
>
> Key: PDFBOX-2250
> URL: https://issues.apache.org/jira/browse/PDFBOX-2250
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Parsing
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
>
> PDFBOX-1769 introduced a "self healing" mechanism to repair corrupt XRef 
> offsets. But that one was just a starter and there remain a lot of issues to 
> be solved.
> I'm planing to solve at least some of them.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2201) getKeywords returns null although keywords are present

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-2201:
-

No problem this time, your issue showed that the sample code had to be improved 
:-)

> getKeywords returns null although keywords are present
> --
>
> Key: PDFBOX-2201
> URL: https://issues.apache.org/jira/browse/PDFBOX-2201
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 1.8.5, 1.8.6, 1.8.7, 2.0.0
> Environment: Win64
>Reporter: Walter Kehl
>Priority: Minor
> Fix For: 1.8.7, 2.0.0
>
> Attachments: Roland_Berger_TAB_Industry_4_0.pdf
>
>
> When accessing a PDF document which clearly has keywords in its meta data , 
> the function call 
> PDDocumentInformation documentInfo = document.getDocumentInformation();
> String info = documentInfo.getKeywords();
> returns null. 
> Sample PDF is attached. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2201) getKeywords returns null although keywords are present

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on PDFBOX-2201:
-

I see that there's a comment by PDF Architect [~leonardr] which appeared in the 
dev list but not here, so I add it for the completeness of the record:
{quote}
There is nothing magic about how Acrobat/Reader goes from XMP to DocInfo
(and vice-versa).  It is documented in our own specs (the XMP specs,as you
point to) as well as being standardized in the PDF/A and PDF/X standards
from ISO.
{quote}

> getKeywords returns null although keywords are present
> --
>
> Key: PDFBOX-2201
> URL: https://issues.apache.org/jira/browse/PDFBOX-2201
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 1.8.5, 1.8.6, 1.8.7, 2.0.0
> Environment: Win64
>Reporter: Walter Kehl
>Priority: Minor
> Fix For: 1.8.7, 2.0.0
>
> Attachments: Roland_Berger_TAB_Industry_4_0.pdf
>
>
> When accessing a PDF document which clearly has keywords in its meta data , 
> the function call 
> PDDocumentInformation documentInfo = document.getDocumentInformation();
> String info = documentInfo.getKeywords();
> returns null. 
> Sample PDF is attached. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (PDFBOX-2267) IOException and partial rendering and colorspace creation error

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr resolved PDFBOX-2267.
-

Resolution: Fixed

> IOException and partial rendering and colorspace creation error
> ---
>
> Key: PDFBOX-2267
> URL: https://issues.apache.org/jira/browse/PDFBOX-2267
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing, Rendering
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 1.8.7, 2.0.0
>
> Attachments: PDFBOX-2265-igalia.pdf
>
>
> I get this exception with the attached PDF, and the upper arc of the image is 
> not rendered:
> {code}
> java.io.IOException: Unknown colorspace 
> type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
> COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
> COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
> (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
> COSFloat{0.824905}]}) }
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
> {code}
> There are several causes: (1) in PDICCBased.createColorSpace() the variable 
> numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
> fixed in the 2.0 version but not in the 1.8 version. Because the exception 
> isn't caught correctly, the alternate color space is to be used. (3) The 
> implementation of getAlternateColorSpaces() (that part existed before it 
> became an apache project) thinks that this is an array of colorspaces.This
> {code}
> [/Lab< 127.0]/WhitePoint[0.964203 1.0 0.824905]>>]
> {code}
> is considered an array of two colorspaces. This is contrary to the spec, 
> which mentions "An alternate colour space". I will fix the bug without 
> changing the API in 1.8, but will change the API in 2.0, which will be
> {code}
> public PDColorSpace getAlternateColorSpace() throws IOException
> {code}
> instead of
> {code}
> public List getAlternateColorSpaces() throws IOException
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2265) ArrayIndexOutOfBoundsException in PDICCBased.loadICCProfile

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2265:


Description: 
I get this exception with the attached file:
{code}
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.loadICCProfile(PDICCBased.java:116)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.(PDICCBased.java:84)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:135)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.(PDDeviceN.java:87)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:123)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
at 
org.apache.pdfbox.pdmodel.graphics.shading.PDShading.getColorSpace(PDShading.java:212)
{code}

The cause is this line:
{code}
float[] initial = new float[getColorSpaceType()];
{code}
replacing it with this line that makes more sense
{code}
float[] initial = new float[getNumberOfComponents()];
{code}
gets rid of the exception. I assume that this is a typo, i.e. wrong line was 
hit in the IDE in the popup. 

The file now renders without exception. There's a different exception in 1.8, 
see PDFBOX-2267.

  was:
I get this exception with the attached file:
{code}
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.loadICCProfile(PDICCBased.java:116)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.(PDICCBased.java:84)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:135)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.(PDDeviceN.java:87)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:123)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
at 
org.apache.pdfbox.pdmodel.graphics.shading.PDShading.getColorSpace(PDShading.java:212)
{code}

The cause is this line:
{code}
float[] initial = new float[getColorSpaceType()];
{code}
replacing it with this line that makes more sense
{code}
float[] initial = new float[getNumberOfComponents()];
{code}
gets rid of the exception. I assume that this is a typo, i.e. wrong line was 
hit in the IDE in the popup. 

The file now renders without exception. There's a different exception in 1.8, 
I'll recheck the file after all the shading changes (including several 
bugfixes) have been implemented there.


> ArrayIndexOutOfBoundsException in PDICCBased.loadICCProfile
> ---
>
> Key: PDFBOX-2265
> URL: https://issues.apache.org/jira/browse/PDFBOX-2265
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 2.0.0
>
> Attachments: igalia-header-proof.pdf
>
>
> I get this exception with the attached file:
> {code}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.loadICCProfile(PDICCBased.java:116)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.(PDICCBased.java:84)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:135)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.(PDDeviceN.java:87)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:123)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
>   at 
> org.apache.pdfbox.pdmodel.graphics.shading.PDShading.getColorSpace(PDShading.java:212)
> {code}
> The cause is this line:
> {code}
> float[] initial = new float[getColorSpaceType()];
> {code}
> replacing it with this line that makes more sense
> {code}
> float[] initial = new float[getNumberOfComponents()];
> {code}
> gets rid of the exception. I assume that this is a typo, i.e. wrong line was 
> hit in the IDE in the popup. 
> The file now renders without exception. There's a different exception in 1.8, 
> see PDFBOX-2267.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2267) IOException and partial rendering and colorspace creation error

[ASF subversion and git services (JIRA)]

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

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

Commit 1617331 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1617331 ]

PDFBOX-2267: treat /Alternate as ONE colorspace

> IOException and partial rendering and colorspace creation error
> ---
>
> Key: PDFBOX-2267
> URL: https://issues.apache.org/jira/browse/PDFBOX-2267
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing, Rendering
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 1.8.7, 2.0.0
>
> Attachments: PDFBOX-2265-igalia.pdf
>
>
> I get this exception with the attached PDF, and the upper arc of the image is 
> not rendered:
> {code}
> java.io.IOException: Unknown colorspace 
> type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
> COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
> COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
> (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
> COSFloat{0.824905}]}) }
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
> {code}
> There are several causes: (1) in PDICCBased.createColorSpace() the variable 
> numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
> fixed in the 2.0 version but not in the 1.8 version. Because the exception 
> isn't caught correctly, the alternate color space is to be used. (3) The 
> implementation of getAlternateColorSpaces() (that part existed before it 
> became an apache project) thinks that this is an array of colorspaces.This
> {code}
> [/Lab< 127.0]/WhitePoint[0.964203 1.0 0.824905]>>]
> {code}
> is considered an array of two colorspaces. This is contrary to the spec, 
> which mentions "An alternate colour space". I will fix the bug without 
> changing the API in 1.8, but will change the API in 2.0, which will be
> {code}
> public PDColorSpace getAlternateColorSpace() throws IOException
> {code}
> instead of
> {code}
> public List getAlternateColorSpaces() throws IOException
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2267) IOException and partial rendering and colorspace creation error

[ASF subversion and git services (JIRA)]

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

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

Commit 1617330 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1617330 ]

PDFBOX-2267: treat /Alternate as ONE colorspace

> IOException and partial rendering and colorspace creation error
> ---
>
> Key: PDFBOX-2267
> URL: https://issues.apache.org/jira/browse/PDFBOX-2267
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing, Rendering
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 1.8.7, 2.0.0
>
> Attachments: PDFBOX-2265-igalia.pdf
>
>
> I get this exception with the attached PDF, and the upper arc of the image is 
> not rendered:
> {code}
> java.io.IOException: Unknown colorspace 
> type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
> COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
> COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
> (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
> COSFloat{0.824905}]}) }
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
> {code}
> There are several causes: (1) in PDICCBased.createColorSpace() the variable 
> numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
> fixed in the 2.0 version but not in the 1.8 version. Because the exception 
> isn't caught correctly, the alternate color space is to be used. (3) The 
> implementation of getAlternateColorSpaces() (that part existed before it 
> became an apache project) thinks that this is an array of colorspaces.This
> {code}
> [/Lab< 127.0]/WhitePoint[0.964203 1.0 0.824905]>>]
> {code}
> is considered an array of two colorspaces. This is contrary to the spec, 
> which mentions "An alternate colour space". I will fix the bug without 
> changing the API in 1.8, but will change the API in 2.0, which will be
> {code}
> public PDColorSpace getAlternateColorSpace() throws IOException
> {code}
> instead of
> {code}
> public List getAlternateColorSpaces() throws IOException
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: PDFBox 1.8.7 release?

[Maruan Sahyoun]

Am 11.08.2014 um 18:59 schrieb Andreas Lehmkuehler :

> Hi,
> 
> 
> Am 11.08.2014 18:35, schrieb John Hewson:
>> Andreas,
>> 
>> What I had been thinking was that now that 2.0 is getting closer that me 
>> wight want to do less with 1.8, but I agree with you that we don’t need any 
>> fixed rules, staying flexible is better. It sounds like we might want to 
>> think about some guidelines for 1.8 after 2.0 is released to avoid a 
>> “Windows XP” situation, but we’re not at that point yet.
> Yes, good point. Hopefully 1.8.7 will be the last 1.8 release before 2.0 :-)
> 

As 2.0 breaks the current API (which is intended) I suspect that there will be 
bugfixes for 1.8 needed for some time.

>> Cheers
>> 
>> -- John
> 
> BR
> Andreas Lehmkühler
> 
>> 
>> On 11 Aug 2014, at 03:57, Andreas Lehmkühler  wrote:
>> 
>>> Hi,
>>> 
 John Hewson  hat am 7. August 2014 um 18:48 geschrieben:
 
 
 Perhaps we should stop adding new features to 1.8, and only fix the most
 problematic bugs?
>>> We never were that strict about the contents of a bugfix release in the 
>>> past.
>>> We always added some improvements or new features. Most of them were small
>>> and/or hadn't a huge impact on the code/functionality. Some were added
>>> because people were eagerly waiting for them. There aren't any rules what
>>> to add or not and IMHO we don't need any.
>>> 
>>> 
>>> BR
>>> Andreas Lehmkühler
>>> 
 
 -- John
 
> On 7 Aug 2014, at 09:11, Tilman Hausherr  wrote:
> 
> +1
> 
> but after I've ported the GSoC2014-improved shading package to 1.8
> 
> Tilman
> 
> Am 07.08.2014 12:35, schrieb Andreas Lehmkühler:
>> Hi,
>> 
>> there is already a number of solved issues and I guess it's
>> time for a new bugfix release.
>> 
>> I'm working on PDFBOX-2250 and I'd like to finish that
>> first but how about a new release in 2 or 3 weeks from now?
>> 
>> WDYT?
>> 
>> BR
>> Andreas Lehmkühler
> 
>> 
>> 
> 

[jira] [Updated] (PDFBOX-2268) AES-256 decryptions fails

[Michele Balistreri (JIRA)]

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

Michele Balistreri updated PDFBOX-2268:
---

Description: 
When opening a document encrypted with AES-256 (owner password only) by 
providing no password, the isUserPassword method fails, since it tries, 
indirectly, to decrypt a null pointer by calling computeUserPassword. The 
result of computeUserPassword would be ignored even if the call succeeded, 
since it is not need for AES-256 encryption.

Also, the code validating the Perms dictionary is correct, but unfortunately 
not even Acrobat seems to write Perms correctly (in my case P = F0C0 and Perms 
= F2C0), so that check needs to be relaxed. Perhaps logging the issue instead 
of throwing an exception would be more adequate.

Provided is a patch for both issues. I understand it is probably suboptimal but 
I am completely new to the project and have not yet had the time to study all 
coding conventions. Considering the patch is very small maybe someone can take 
it as a pointer of what needs to be changes.

  was:
When opening a document encrypted with AES-256 (owner password only) by 
providing no password, the isUserPassword method fails, since it tries 
(indirectly) to decrypt a null pointer.

Also, the code validating the Perms dictionary is correct, but unfortunately 
not even Acrobat seems to write Perms correctly (in my case P = F0C0 and Perms 
= F2C0), so that check needs to be relaxed. Perhaps logging the issue instead 
of throwing an exception would be more adequate.

Provided is a patch for both issues. I understand it is probably suboptimal but 
I am completely new to the project and have not yet had the time to study all 
coding conventions. Considering the patch is very small maybe someone can take 
it as a pointer of what needs to be changes.


> AES-256 decryptions fails
> -
>
> Key: PDFBOX-2268
> URL: https://issues.apache.org/jira/browse/PDFBOX-2268
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Michele Balistreri
> Attachments: AES256-fix.diff
>
>
> When opening a document encrypted with AES-256 (owner password only) by 
> providing no password, the isUserPassword method fails, since it tries, 
> indirectly, to decrypt a null pointer by calling computeUserPassword. The 
> result of computeUserPassword would be ignored even if the call succeeded, 
> since it is not need for AES-256 encryption.
> Also, the code validating the Perms dictionary is correct, but unfortunately 
> not even Acrobat seems to write Perms correctly (in my case P = F0C0 and 
> Perms = F2C0), so that check needs to be relaxed. Perhaps logging the issue 
> instead of throwing an exception would be more adequate.
> Provided is a patch for both issues. I understand it is probably suboptimal 
> but I am completely new to the project and have not yet had the time to study 
> all coding conventions. Considering the patch is very small maybe someone can 
> take it as a pointer of what needs to be changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2268) AES-256 decryptions fails

[Michele Balistreri (JIRA)]

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

Michele Balistreri updated PDFBOX-2268:
---

Description: 
When opening a document encrypted with AES-256 (owner password only) by 
providing no password, the isUserPassword method fails, since it tries 
(indirectly) to decrypt a null pointer.

Also, the code validating the Perms dictionary is correct, but unfortunately 
not even Acrobat seems to write Perms correctly (in my case P = F0C0 and Perms 
= F2C0), so that check needs to be relaxed. Perhaps logging the issue instead 
of throwing an exception would be more adequate.

Provided is a patch for both issues. I understand it is probably suboptimal but 
I am completely new to the project and have not yet had the time to study all 
coding conventions. Considering the patch is very small maybe someone can take 
it as a pointer of what needs to be changes.

  was:
When opening a document encrypted with AES-256 (owner password only) by 
providing no password, the isUserPasswordMethod fails, since it tries to 
decrypt a null pointer.

Also, the code validating the Perms dictionary is correct, but unfortunately 
not even Acrobat seems to write Perms correctly (in my case P = F0C0 and Perms 
= F2C0), so that check needs to be relaxed. Perhaps logging the issue instead 
of throwing an exception would be more adequate.

Provided is a patch for both issues. I understand it is probably suboptimal but 
I am completely new to the project and have not yet had the time to study all 
coding conventions. Considering the patch is very small maybe someone can take 
it as a pointer of what needs to be changes.


> AES-256 decryptions fails
> -
>
> Key: PDFBOX-2268
> URL: https://issues.apache.org/jira/browse/PDFBOX-2268
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Michele Balistreri
> Attachments: AES256-fix.diff
>
>
> When opening a document encrypted with AES-256 (owner password only) by 
> providing no password, the isUserPassword method fails, since it tries 
> (indirectly) to decrypt a null pointer.
> Also, the code validating the Perms dictionary is correct, but unfortunately 
> not even Acrobat seems to write Perms correctly (in my case P = F0C0 and 
> Perms = F2C0), so that check needs to be relaxed. Perhaps logging the issue 
> instead of throwing an exception would be more adequate.
> Provided is a patch for both issues. I understand it is probably suboptimal 
> but I am completely new to the project and have not yet had the time to study 
> all coding conventions. Considering the patch is very small maybe someone can 
> take it as a pointer of what needs to be changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2268) AES-256 decryptions fails

[Michele Balistreri (JIRA)]

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

Michele Balistreri updated PDFBOX-2268:
---

Attachment: AES256-fix.diff

Patch for issue PDFBOX-2268

> AES-256 decryptions fails
> -
>
> Key: PDFBOX-2268
> URL: https://issues.apache.org/jira/browse/PDFBOX-2268
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: Michele Balistreri
> Attachments: AES256-fix.diff
>
>
> When opening a document encrypted with AES-256 (owner password only) by 
> providing no password, the isUserPasswordMethod fails, since it tries to 
> decrypt a null pointer.
> Also, the code validating the Perms dictionary is correct, but unfortunately 
> not even Acrobat seems to write Perms correctly (in my case P = F0C0 and 
> Perms = F2C0), so that check needs to be relaxed. Perhaps logging the issue 
> instead of throwing an exception would be more adequate.
> Provided is a patch for both issues. I understand it is probably suboptimal 
> but I am completely new to the project and have not yet had the time to study 
> all coding conventions. Considering the patch is very small maybe someone can 
> take it as a pointer of what needs to be changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PDFBOX-2268) AES-256 decryptions fails

[Michele Balistreri (JIRA)]

Michele Balistreri created PDFBOX-2268:
--

 Summary: AES-256 decryptions fails
 Key: PDFBOX-2268
 URL: https://issues.apache.org/jira/browse/PDFBOX-2268
 Project: PDFBox
  Issue Type: Bug
  Components: PDModel
Affects Versions: 2.0.0
Reporter: Michele Balistreri


When opening a document encrypted with AES-256 (owner password only) by 
providing no password, the isUserPasswordMethod fails, since it tries to 
decrypt a null pointer.

Also, the code validating the Perms dictionary is correct, but unfortunately 
not even Acrobat seems to write Perms correctly (in my case P = F0C0 and Perms 
= F2C0), so that check needs to be relaxed. Perhaps logging the issue instead 
of throwing an exception would be more adequate.

Provided is a patch for both issues. I understand it is probably suboptimal but 
I am completely new to the project and have not yet had the time to study all 
coding conventions. Considering the patch is very small maybe someone can take 
it as a pointer of what needs to be changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2267) IOException and partial rendering and colorspace creation error

[ASF subversion and git services (JIRA)]

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

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

Commit 1617326 from [~tilman] in branch 'pdfbox/branches/1.8'
[ https://svn.apache.org/r1617326 ]

PDFBOX-2267: use getter instead of uninitalized variable; rethrow unhandled 
exception; treat /Alternate as ONE colorspace

> IOException and partial rendering and colorspace creation error
> ---
>
> Key: PDFBOX-2267
> URL: https://issues.apache.org/jira/browse/PDFBOX-2267
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing, Rendering
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 1.8.7, 2.0.0
>
> Attachments: PDFBOX-2265-igalia.pdf
>
>
> I get this exception with the attached PDF, and the upper arc of the image is 
> not rendered:
> {code}
> java.io.IOException: Unknown colorspace 
> type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
> COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
> COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
> (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
> COSFloat{0.824905}]}) }
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
> {code}
> There are several causes: (1) in PDICCBased.createColorSpace() the variable 
> numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
> fixed in the 2.0 version but not in the 1.8 version. Because the exception 
> isn't caught correctly, the alternate color space is to be used. (3) The 
> implementation of getAlternateColorSpaces() (that part existed before it 
> became an apache project) thinks that this is an array of colorspaces.This
> {code}
> [/Lab< 127.0]/WhitePoint[0.964203 1.0 0.824905]>>]
> {code}
> is considered an array of two colorspaces. This is contrary to the spec, 
> which mentions "An alternate colour space". I will fix the bug without 
> changing the API in 1.8, but will change the API in 2.0, which will be
> {code}
> public PDColorSpace getAlternateColorSpace() throws IOException
> {code}
> instead of
> {code}
> public List getAlternateColorSpaces() throws IOException
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: PDFBox 1.8.7 release?

[Andreas Lehmkuehler]

Hi,


Am 11.08.2014 18:35, schrieb John Hewson:

Andreas,

What I had been thinking was that now that 2.0 is getting closer that me wight 
want to do less with 1.8, but I agree with you that we don’t need any fixed 
rules, staying flexible is better. It sounds like we might want to think about 
some guidelines for 1.8 after 2.0 is released to avoid a “Windows XP” 
situation, but we’re not at that point yet.

Yes, good point. Hopefully 1.8.7 will be the last 1.8 release before 2.0 :-)


Cheers

-- John


BR
Andreas Lehmkühler



On 11 Aug 2014, at 03:57, Andreas Lehmkühler  wrote:


Hi,


John Hewson  hat am 7. August 2014 um 18:48 geschrieben:


Perhaps we should stop adding new features to 1.8, and only fix the most
problematic bugs?

We never were that strict about the contents of a bugfix release in the past.
We always added some improvements or new features. Most of them were small
and/or hadn't a huge impact on the code/functionality. Some were added
because people were eagerly waiting for them. There aren't any rules what
to add or not and IMHO we don't need any.


BR
Andreas Lehmkühler



-- John


On 7 Aug 2014, at 09:11, Tilman Hausherr  wrote:

+1

but after I've ported the GSoC2014-improved shading package to 1.8

Tilman

Am 07.08.2014 12:35, schrieb Andreas Lehmkühler:

Hi,

there is already a number of solved issues and I guess it's
time for a new bugfix release.

I'm working on PDFBOX-2250 and I'd like to finish that
first but how about a new release in 2 or 3 weeks from now?

WDYT?

BR
Andreas Lehmkühler

[jira] [Commented] (PDFBOX-2266) NPE when converting page to image

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2266:
-

You can also use {{new Color(0, 0, 0, 0);}} to get transparency on non-white 
backgrounds.

> NPE when converting page to image
> -
>
> Key: PDFBOX-2266
> URL: https://issues.apache.org/jira/browse/PDFBOX-2266
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Jen Huang
>Priority: Minor
> Attachments: powerpoint2011.pdf
>
>
> I have a pdf that throws an NPE in version 2.0.0 when rendering a specific 
> page to an image.  I've tested the pdf with 1.8.6 and it worked correctly.  
> It logged a warning (java.io.IOException: Error: Unknown shading type 0) but 
> did not throw any exceptions.  I will attach the pdf.  Let me know if you 
> need any more info.
> ! java.lang.NullPointerException: null
> ! at 
> org.apache.pdfbox.pdmodel.graphics.color.PDPattern.toPaint(PDPattern.java:125)
>  ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at 
> org.apache.pdfbox.rendering.PageDrawer.getNonStrokingPaint(PageDrawer.java:710)
>  ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at org.apache.pdfbox.rendering.PageDrawer.fillPath(PageDrawer.java:773) 
> ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at 
> org.apache.pdfbox.util.operator.graphics.FillNonZeroRule.process(FillNonZeroRule.java:36)
>  ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at 
> org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:564)
>  ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at 
> org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268)
>  ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at 
> org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235)
>  ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at 
> org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:189)
>  ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:168) 
> ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:228) 
> ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at 
> org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:160) 
> ~[pdfbox-2.0.0-SNAPSHOT.jar:na]
> ! at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:83) 
> ~[pdfbox-2.0.0-SNAPSHOT.jar:na]



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2267) IOException and partial rendering and colorspace creation error

[John Hewson (JIRA)]

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

John Hewson commented on PDFBOX-2267:
-

+1

> IOException and partial rendering and colorspace creation error
> ---
>
> Key: PDFBOX-2267
> URL: https://issues.apache.org/jira/browse/PDFBOX-2267
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing, Rendering
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 1.8.7, 2.0.0
>
> Attachments: PDFBOX-2265-igalia.pdf
>
>
> I get this exception with the attached PDF, and the upper arc of the image is 
> not rendered:
> {code}
> java.io.IOException: Unknown colorspace 
> type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
> COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
> COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
> (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
> COSFloat{0.824905}]}) }
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
> {code}
> There are several causes: (1) in PDICCBased.createColorSpace() the variable 
> numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
> fixed in the 2.0 version but not in the 1.8 version. Because the exception 
> isn't caught correctly, the alternate color space is to be used. (3) The 
> implementation of getAlternateColorSpaces() (that part existed before it 
> became an apache project) thinks that this is an array of colorspaces.This
> {code}
> [/Lab< 127.0]/WhitePoint[0.964203 1.0 0.824905]>>]
> {code}
> is considered an array of two colorspaces. This is contrary to the spec, 
> which mentions "An alternate colour space". I will fix the bug without 
> changing the API in 1.8, but will change the API in 2.0, which will be
> {code}
> public PDColorSpace getAlternateColorSpace() throws IOException
> {code}
> instead of
> {code}
> public List getAlternateColorSpaces() throws IOException
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: PDFBox 1.8.7 release?

[John Hewson]

Andreas,

What I had been thinking was that now that 2.0 is getting closer that me wight 
want to do less with 1.8, but I agree with you that we don’t need any fixed 
rules, staying flexible is better. It sounds like we might want to think about 
some guidelines for 1.8 after 2.0 is released to avoid a “Windows XP” 
situation, but we’re not at that point yet.

Cheers

-- John

On 11 Aug 2014, at 03:57, Andreas Lehmkühler  wrote:

> Hi,
> 
>> John Hewson  hat am 7. August 2014 um 18:48 geschrieben:
>> 
>> 
>> Perhaps we should stop adding new features to 1.8, and only fix the most
>> problematic bugs?
> We never were that strict about the contents of a bugfix release in the past.
> We always added some improvements or new features. Most of them were small
> and/or hadn't a huge impact on the code/functionality. Some were added
> because people were eagerly waiting for them. There aren't any rules what
> to add or not and IMHO we don't need any.
> 
> 
> BR
> Andreas Lehmkühler
> 
>> 
>> -- John
>> 
>>> On 7 Aug 2014, at 09:11, Tilman Hausherr  wrote:
>>> 
>>> +1
>>> 
>>> but after I've ported the GSoC2014-improved shading package to 1.8
>>> 
>>> Tilman
>>> 
>>> Am 07.08.2014 12:35, schrieb Andreas Lehmkühler:
 Hi,
 
 there is already a number of solved issues and I guess it's
 time for a new bugfix release.
 
 I'm working on PDFBOX-2250 and I'd like to finish that
 first but how about a new release in 2 or 3 weeks from now?
 
 WDYT?
 
 BR
 Andreas Lehmkühler
>>> 

[jira] [Updated] (PDFBOX-2267) IOException and partial rendering and colorspace creation error

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2267:


Attachment: PDFBOX-2265-igalia.pdf

> IOException and partial rendering and colorspace creation error
> ---
>
> Key: PDFBOX-2267
> URL: https://issues.apache.org/jira/browse/PDFBOX-2267
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing, Rendering
>Affects Versions: 1.8.6, 1.8.7, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 1.8.7, 2.0.0
>
> Attachments: PDFBOX-2265-igalia.pdf
>
>
> I get this exception with the attached PDF, and the upper arc of the image is 
> not rendered:
> {code}
> java.io.IOException: Unknown colorspace 
> type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
> COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
> COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
> (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
> COSFloat{0.824905}]}) }
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
>   at 
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
> {code}
> There are several causes: (1) in PDICCBased.createColorSpace() the variable 
> numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
> fixed in the 2.0 version but not in the 1.8 version. Because the exception 
> isn't caught correctly, the alternate color space is to be used. (3) The 
> implementation of getAlternateColorSpaces() (that part existed before it 
> became an apache project) thinks that this is an array of colorspaces.This
> {code}
> [/Lab< 127.0]/WhitePoint[0.964203 1.0 0.824905]>>]
> {code}
> is considered an array of two colorspaces. This is contrary to the spec, 
> which mentions "An alternate colour space". I will fix the bug without 
> changing the API in 1.8, but will change the API in 2.0, which will be
> {code}
> public PDColorSpace getAlternateColorSpace() throws IOException
> {code}
> instead of
> {code}
> public List getAlternateColorSpaces() throws IOException
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PDFBOX-2267) IOException and partial rendering and colorspace creation error

[Tilman Hausherr (JIRA)]

Tilman Hausherr created PDFBOX-2267:
---

 Summary: IOException and partial rendering and colorspace creation 
error
 Key: PDFBOX-2267
 URL: https://issues.apache.org/jira/browse/PDFBOX-2267
 Project: PDFBox
  Issue Type: Bug
  Components: Parsing, Rendering
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
 Fix For: 1.8.7, 2.0.0


I get this exception with the attached PDF, and the upper arc of the image is 
not rendered:
{code}
java.io.IOException: Unknown colorspace 
type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, COSFloat{0.0}, 
COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, COSFloat{127.0}, 
COSFloat{-128.0}, COSFloat{127.0}]}) 
(COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
COSFloat{0.824905}]}) }
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
{code}
There are several causes: (1) in PDICCBased.createColorSpace() the variable 
numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
fixed in the 2.0 version but not in the 1.8 version. Because the exception 
isn't caught correctly, the alternate color space is to be used. (3) The 
implementation of getAlternateColorSpaces() (that part existed before it became 
an apache project) thinks that this is an array of colorspaces.This
{code}
[/Lab<>]
{code}
is considered an array of two colorspaces. This is contrary to the spec, which 
mentions "An alternate colour space". I will fix the bug without changing the 
API in 1.8, but will change the API in 2.0, which will be
{code}
public PDColorSpace getAlternateColorSpace() throws IOException
{code}
instead of
{code}
public List getAlternateColorSpaces() throws IOException
{code}




--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: PDFBox 1.8.7 release?

[Andreas Lehmkühler]

Hi,

> John Hewson  hat am 7. August 2014 um 18:48 geschrieben:
>
>
> Perhaps we should stop adding new features to 1.8, and only fix the most
> problematic bugs?
We never were that strict about the contents of a bugfix release in the past.
We always added some improvements or new features. Most of them were small
and/or hadn't a huge impact on the code/functionality. Some were added
because people were eagerly waiting for them. There aren't any rules what
to add or not and IMHO we don't need any.


BR
Andreas Lehmkühler

>
> -- John
>
> > On 7 Aug 2014, at 09:11, Tilman Hausherr  wrote:
> >
> > +1
> >
> > but after I've ported the GSoC2014-improved shading package to 1.8
> >
> > Tilman
> >
> > Am 07.08.2014 12:35, schrieb Andreas Lehmkühler:
> >> Hi,
> >>
> >> there is already a number of solved issues and I guess it's
> >> time for a new bugfix release.
> >>
> >> I'm working on PDFBOX-2250 and I'd like to finish that
> >> first but how about a new release in 2 or 3 weeks from now?
> >>
> >> WDYT?
> >>
> >> BR
> >> Andreas Lehmkühler
> >

[jira] [Commented] (PDFBOX-2201) getKeywords returns null although keywords are present

[Walter Kehl (JIRA)]

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

Walter Kehl commented on PDFBOX-2201:
-

Tilman,

thanks for the help, it works beautifully now. I guess I should have asked 
first in the mailing list before entering a bug. Next time I will do that. 
I really appreciate PDFBox and the support you give it. 

Best Regards
Walter





> getKeywords returns null although keywords are present
> --
>
> Key: PDFBOX-2201
> URL: https://issues.apache.org/jira/browse/PDFBOX-2201
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 1.8.5, 1.8.6, 1.8.7, 2.0.0
> Environment: Win64
>Reporter: Walter Kehl
>Priority: Minor
> Fix For: 1.8.7, 2.0.0
>
> Attachments: Roland_Berger_TAB_Industry_4_0.pdf
>
>
> When accessing a PDF document which clearly has keywords in its meta data , 
> the function call 
> PDDocumentInformation documentInfo = document.getDocumentInformation();
> String info = documentInfo.getKeywords();
> returns null. 
> Sample PDF is attached. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)