[
https://issues.apache.org/jira/browse/PDFBOX-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rees Byars updated PDFBOX-3218:
-------------------------------
Attachment: PDFBOX-3218.patch
Fixes the field renaming when merging AcroForms, while also optimizing a bit on
the nextFieldNum calculation and adding the ability in the PDFMergerUtility API
to set the desired renaming prefix and to turn off renaming altogether. Turning
off the renaming was added in support of PDFBOX-3111.
> PDFMergerUtility improperly merges AcroForms, causing some forms to break
> -------------------------------------------------------------------------
>
> Key: PDFBOX-3218
> URL: https://issues.apache.org/jira/browse/PDFBOX-3218
> Project: PDFBox
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 2.0.0
> Reporter: Rees Byars
> Attachments: PDFBOX-3218.patch
>
>
> In PDFMergerUtility.mergeAcroForm, adding a parent field to the destination
> fields automatically adds the children, but the code does not account for
> this. The result is that the same fields get added many times with different
> names. This is a silent error for most PDFs. However, for some forms, the
> resultant PDFs cause SOM expression errors in Adobe Reader.
> This problem can be reproduced by appending the following PDFs in the order
> listed:
> http://www.vba.va.gov/pubs/forms/VBA-21-4185-ARE.pdf
> http://www.vba.va.gov/pubs/forms/VBA-21-534EZ-ARE.pdf
> We were able to fix this issue for our purposes by forking the github mirror
> and altering the mergeAcroForm method to only append fields whose parent is
> null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
