[
https://issues.apache.org/jira/browse/PDFBOX-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256413#comment-15256413
]
Alexander Kriegisch edited comment on PDFBOX-3323 at 4/25/16 2:53 PM:
----------------------------------------------------------------------
Sorry, it only works on Windows. Our Jenkins server running under Linux
produces bogus XMP during the merge. The relevant part of the PDF file when
opened in a text editor looks like this:
{code}
</rdf:Description>
</rdf:RDF>
</x:xmpmeta><?xpacket end="w"?>
[Here is a series of 1042 NUL bytes, then CRLF while at the other lines there
only is simple LF at the end of each line.]
endstream
endobj
{code}
*Update:* I also noticed that under Windows the XMP data have CRLF at the end
of each XML line. Does that somehow account for a difference in buffer size?
Just speculating. But OTOH my XMP section does not have 1042 lines of code,
only 31.
*Update 2:* The document can be opened in Acrobat, the properties look good.
Even veraPDF says it is PDF/A-1b compliant. But Apache Preflight says: "7.1:
Error on MetaData, Failed to parse". The online checker at
https://www.pdflib.com/knowledge-base/xmp-metadata/free-xmp-validator/ says:
"XMP data is invalid. Reason: XMP metadata: Error parsing XML stream: not
well-formed (invalid token) in line 32, column 0" Maybe it would be a good idea
if PDFBox would create merged PDFs which are accepted by its own sibling
Preflight. ;-)
was (Author: kriegaex):
Sorry, it only works on Windows. Our Jenkins server running under Linux
produces bogus XMP during the merge. The relevant part of the PDF file when
opened in a text editor looks like this:
{code}
</rdf:Description>
</rdf:RDF>
</x:xmpmeta><?xpacket end="w"?>
[Here is a series of 1042 NUL bytes, then CRLF while at the other lines there
only is simple LF at the end of each line.]
endstream
endobj
{code}
*Update:* I also noticed that under Windows the XMP data have CRLF at the end
of each XML line. Does that somehow account for a difference in buffer size?
Just speculating. But OTOH my XMP section does not have 1042 lines of code,
only 31.
*Update 2:* The document can be opened in Acrobat, the properties look good.
Even veraPDF says it is PDF/A-1b compliant. But Apache Preflight says: "7.1:
Error on MetaData, Failed to parse". The online checker at
https://www.pdflib.com/knowledge-base/xmp-metadata/free-xmp-validator/ says:
"XMP data is invalid. Reason: XMP metadata: Error parsing XML stream: not
well-formed (invalid token) in line 32, column 0"
> Cannot set destination meta data in PDFMergerUtility
> ----------------------------------------------------
>
> Key: PDFBOX-3323
> URL: https://issues.apache.org/jira/browse/PDFBOX-3323
> Project: PDFBox
> Issue Type: Improvement
> Affects Versions: 1.8.9, 2.0.0
> Reporter: Alexander Kriegisch
> Assignee: Tilman Hausherr
> Labels: merge, metadata
> Fix For: 2.0.1, 2.1.0
>
>
> When merging multiple PDFs into one compound document via
> {{PDFMergerUtility}}, meta data like title, author, subject cannot be set but
> seem to be taken from one of the input documents. This is usually not the
> desired behaviour because as a user I have no direct influence on the meta
> data. As a user I would like to explicitly set or at least overwrite certain
> meta data for the destination document. Currently I can only set the
> destination stream or file name, but not the meta data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
