You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Kevin Ternes <KT...@thegeneral.com> on 2015/10/12 21:22:56 UTC

Visibility of PDFCloneUtility

The visibility of org.apache.pdfbox.multipdf.PDFCloneUtility in 2.0.0-SNAPSHOT is default.
Shouldn't it actually be public?

Re: Visibility of PDFCloneUtility

Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,

> Am 20.10.2015 um 20:12 schrieb Tilman Hausherr <TH...@t-online.de>:
> 
> 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.

the list can be extended - fields, annotations, bookmarks, attachments ... - so anything beyond the pure page content.

Maruan


> 
> 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:THausherr@t-online.de]
>> Sent: Monday, October 19, 2015 1:37 PM
>> To: users@pdfbox.apache.org
>> 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: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org


Re: Visibility of PDFCloneUtility

Posted by Tilman Hausherr <TH...@t-online.de>.
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:THausherr@t-online.de]
> Sent: Monday, October 19, 2015 1:37 PM
> To: users@pdfbox.apache.org
> 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: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org


RE: Visibility of PDFCloneUtility

Posted by Kevin Ternes <KT...@thegeneral.com>.
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:THausherr@t-online.de] 
Sent: Monday, October 19, 2015 1:37 PM
To: users@pdfbox.apache.org
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: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org


Re: Visibility of PDFCloneUtility

Posted by Tilman Hausherr <TH...@t-online.de>.
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: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org