[
https://issues.apache.org/jira/browse/PDFBOX-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14042550#comment-14042550
]
Pat Hickey commented on PDFBOX-1872:
------------------------------------
The structure is as described in the (edited) first message
* (folder icon) Metadata:Stream(Metadata:XML)
** (folder icon) Filter:Array
*** (bullet icon) \[0\]Crypt
** (bullet icon) Length:6302
** (bullet icon) Subtype: XML
** (bullet icon) Type:Metadata
The output document (of a simple load/decrypt/write program) has the same
structure, with encrypted metadata.
I found a public reference to the PDF, although it appears to be a later edit.
It exhibits the same behavior though.
https://www.dpdhl.com/content/dam/Investors/Events/Reporting/2013/DPDHL_Annual_Report_2012.pdf
> PDMetadata.exportXMPMetadata fails when Metadata has encrypted stream
> ---------------------------------------------------------------------
>
> Key: PDFBOX-1872
> URL: https://issues.apache.org/jira/browse/PDFBOX-1872
> Project: PDFBox
> Issue Type: Bug
> Components: JempBox, PDModel
> Affects Versions: 1.8.3
> Environment: Not sure it matters, but Solaris (SunOS 5.10), java
> 1.6.0_19,
> Reporter: Pat Hickey
> Assignee: Andreas Lehmkühler
> Priority: Minor
>
> When the Metadata is encoded with the Crypt filter, exportMetadata() fails to
> parse the XML. My guess is that PDDocumentCatalog.getMetadata() gives
> PDMetadata the raw stream, instead of the filtered one. Then
> PDMetadata.exportXMPMetadata() calls XMPMetadata.load(), which cannot parse
> the encrypted stream.
> While I cannot post the document (proprietary), the outline shown by
> PDFDebugger goes like this:
> Root:Dictionary(Catalog)
> + AcroForm:Dictionary
> - Metadata:Stream(Metadata:XML)
> - Filter:Array
> o [0] Crypt
> o Length:6302
> o Subtype:XML
> o Type:Metadata
--
This message was sent by Atlassian JIRA
(v6.2#6252)
