[
https://issues.apache.org/jira/browse/PDFBOX-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15125397#comment-15125397
]
Rees Byars commented on PDFBOX-3218:
------------------------------------
My apologies for creating and closing multiple pull requests. I keep working on
this in short spans of free time and have been guilty of rushing a bit.
The latest pull request attempts to fix the field renaming, 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
>
> 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]
