This happens because the AcroForm dictionary is not imported.
You can import this dictionary yourself. For example, like this:

Usage


and ImportAcroForm


The correct structure of the document should be like in the image below. The code forms such a structure by cloning the AcroForm dictionary and by re-forms the array of fields with actual object numbers.

There are some problems with this logic as well as with the ImportPages(..) logic which prevents copying form fields that are not flat / not top level only.

1st: ImportPages(..) does not appear to properly handle copying / updating the 'Parent' and 'Kids' references from the source document to the destination document.

Using an example source document with:




There are essentially 5 annotation widgets (kid1, kid2, kid3, kid4, and Field3).

After calling ImportPages(..) kid1, kid2, kid3, kid4 and field3 will all be cloned and copied to the new document.

But ClonedKid1.Parent, ClonedKid2.Parent, ClonedKid3.Parent, and ClonedKid4.Parent will all still point back to the original Field1 and Field2 objects which were never cloned to the new document. Additionally Field1.Kids and Field2.Kids will point to the original document Kid1, Kid2, Kid3, Kid4, not the cloned ones.

In addition to the references pointing to the old document's objects, the ImportAcroForm(..) logic you provided copies the annotations to the fields array is if they're all top level. Given the above input 'fields' you would end up with a copied fields array that looks like:



I wrote a routine to take a stab at cloning/copying the parents to the new document and ensuring the field structure is preserved. It works up until the point I attempt to save the new pdf, then the execution environment crashes with an underlying win32 exception. I'm not sure why.

If I attempt to save to a file it outputs a file before crashing and the output file appears to be valid (at least valid enough that I can then re-open it as a pdf and/or inspect the fields and see that the structure was preserved).

The attempt is contained in this gist:
https://gist.github.com/...893a335ba99aca8cbd915822

Edited by user Friday, October 18, 2019 10:27:05 AM(UTC)  | Reason: Not specified

Try to change "T" (or TU ot TM) entry in the field's dictionary.

from PDF specification:

T - text string - (Optional) - The partial field name (see “Field Names,” below; see also implementation notes 116 and 117 in Appendix H).

TU - text string - (Optional; PDF 1.3) - An alternate field name to be used in place of the actual field name wherever the field must be identified in the user interface (such as in error or status messages referring to the field). This text is also useful when extracting the document’s contents in support of accessibility to users with disabilities or for other purposes (see Section 10.8.2, “Alternate Descriptions”).

TM - text string - (Optional; PDF 1.3) - The mapping name to be used when exporting interactive form field data from the document

Field Names

The T entry in the field dictionary (see Table 8.69 on page 675) holds a text string
defining the field’s partial field name. The fully qualified field name is not explicitly defined but is constructed from the partial field names of the field and all of its ancestors. For a field with no parent, the partial and fully qualified names are the same. For a field that is the child of another field, the fully qualified name is formed by appending the child field’s partial name to the parent’s fully qualified name, separated by a period (.):

parent’s_full_name.child’s_partial_name