[
https://issues.apache.org/jira/browse/PDFBOX-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256454#comment-15256454
]
Alexander Kriegisch edited comment on PDFBOX-3323 at 4/25/16 3:09 PM:
----------------------------------------------------------------------
Good catch!!! I am so sorry I was looking for the problem in PDFBox. I did so
because under Windows everything was alright.
I am accounting for that when doing the document merge via
{code}return new ByteArrayInputStream(mergedPDFOutputStream.toByteArray(), 0,
mergedPDFOutputStream.size());{code}
but not really when copying the XMP data:
{code}cosXMPStream.write(xmpOutputStream.toByteArray());{code}
Instead that should be:
{code}cosXMPStream.write(xmpOutputStream.toByteArray(), 0,
xmpOutputStream.size());{code}
So I am keeping my memory-saving approach with the state-exposing memory stream
but just doing it right. The Jenkins build is also green now.
P.S.: When will 2.0.1 with the two improvements be released? I am just asking
because tomorrow morning we are building our next Maven release, but we cannot
have snapshot dependencies in it. If you are planning to release later I will
just create an intermediary release candidate artifact in our 3rd party repo,
so please do not feel pressurised. It is just a question.
P.P.S.: I have also updated my sample code above in order fopr it to contain
the fix discussed here.
was (Author: kriegaex):
Good catch!!! I am so sorry I was looking for the problem in PDFBox. I did so
because under Windows everything was alright.
I am accounting for that when doing the document merge via
{code}return new ByteArrayInputStream(mergedPDFOutputStream.toByteArray(), 0,
mergedPDFOutputStream.size());{code}
but not really when copying the XMP data:
{code}cosXMPStream.write(xmpOutputStream.toByteArray());{code}
Instead that should be:
{code}cosXMPStream.write(xmpOutputStream.toByteArray(), 0,
xmpOutputStream.size());{code}
So I am keeping my memory-saving approach with the state-exposing memory stream
but just doing it right. The Jenkins build is also green now.
P.S.: When will 2.0.1 with the two improvements be released? I am just asking
because tomorrow morning we are building our next Maven release, but we cannot
have snapshot dependencies in it. If you are planning to release later I will
just create an intermediary release candidate artifact in our 3rd party repo,
so please do not feel pressurised. It is just a question.
> 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]
