[
https://issues.apache.org/jira/browse/PDFBOX-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16764195#comment-16764195
]
Maruan Sahyoun edited comment on PDFBOX-3111 at 2/9/19 6:04 PM:
----------------------------------------------------------------
There is some progress but still a lot of work to do. I can now merge
textfields into a single one and create/rearrange the kids array. Unfortunately
that already adds a lot of code to the PDFMergerUtility (which is already very
long). One thing I need to look into is to assign the fields as a parent entry
to the widget. (Currently there are no PD methods to get/set that). Other than
that the merged fields entries are identical to what Acrobat produces.
[~tilman] WDYT about moving specific merge routines to a new handler such as
{{AcroFormMergeHandler}}. Won't change the current public API of
{{PDFMergerUtility}} but will expose new ones as the handler API has either to
be package private or public if we move it to a subfolder (which I'd prefer). I
think we can go away with a single {{merge}} method and maybe setters/getters.
We could come up with a interface {{PDFMergeHandler}} for that. Would do that
in a second step as soon as the merging text fields is done.
was (Author: msahyoun):
There is some progress but still a lot of work to do. I can now merge
textfields into a single one and create/rearrange the kids array. Unfortunately
that already adds a lot of code to the PDFMergerUtility (which is already very
long). One thing I need to look into is to assign the fields as a parent entry
to the widget. (Currently there are no PD methods to get/set that). Other than
that the merged fields entries are identical to what Acrobat produces.
[~tilman] WDYT about moving specific merge routines to a new handler such as
{{AcroFormMergeHandler}}. Won't change the current public API of
{{PDFMergerUtility}} but will expose new ones as the handler API has either to
be package private or public if we move it to a subfolder (which I'd prefer). I
think we can go away with a single {{merge}} method and maybe setters/getters.
We could come up with a interface {{PDFMergeHandler}} for that.
> Replicate Acrobat behavior when merging PDFs with interactive forms
> -------------------------------------------------------------------
>
> Key: PDFBOX-3111
> URL: https://issues.apache.org/jira/browse/PDFBOX-3111
> Project: PDFBox
> Issue Type: New Feature
> Components: AcroForm
> Affects Versions: 1.8.10, 2.0.0
> Reporter: Maruan Sahyoun
> Assignee: Maruan Sahyoun
> Priority: Major
> Fix For: 2.0.14, 3.0.0 PDFBox
>
> Attachments: proof.pdf
>
>
> When PDFs containing interactive forms are merged using Acrobat, fields with
> the same name are merged into one. That's different to the current behavior
> of PDFBox which renames to be merged fields so they have a unique name (see
> PDFBOX-3094).
> In addition Acrobat supports merging documents with interactive forms into
> collections when keeping the existing (duplicate) fields is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
