Problem is that some parts are not bound to a page, e.g. acroform. For
that one, the merge code is best.
If you don't have fields, you could just add pages to a PDDocument
object. Just take care not to close any source document before saving.
Tilman
Am 20.10.2015 um 16:45 schrieb Kevin Ternes:
The business use is that I am assembling and processing a number of pages into
a single PDDocument.
In certain cases, the PDDocument package needs to be split along different
workflows with certain additional pages and markup and field values for one
workflow and different additional pages and markup and field values for the
other.
The goal is to not run all the logic twice to get the two different documents.
My current solution is this:
PDDocument forkPdDocument = new PDDocument();
PDFMergerUtility mergerUtility = new PDFMergerUtility();
mergerUtility.appendDocument(forkPdDocument, srcPdDocument);
It seems like it would make more sense to use the clone utility here rather
than the merger utility.
-----Original Message-----
From: Tilman Hausherr [mailto:[email protected]]
Sent: Monday, October 19, 2015 1:37 PM
To: [email protected]
Subject: Re: Visibility of PDFCloneUtility
Am 12.10.2015 um 21:22 schrieb Kevin Ternes:
The visibility of org.apache.pdfbox.multipdf.PDFCloneUtility in 2.0.0-SNAPSHOT
is default.
Shouldn't it actually be public?
If you want that, make an argument why it should be public, i.e. what you want
to do.
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
