|
Pdf treats
all fields with the same name as different instances of the same field, all
having the same value. This can be handy (repeating the same information
on every page), and can be a real Problem (combining multiple instances of the
same form, or different forms with matching field names).
In general,
it's a good idea to avoid gluing forms together. You have two
options:
1) Flatten
the forms before combining them. After flattening, they're not forms...
end of problem.
2) Rename
the fields as you import them. You could try giving all the fields from a
given document the same parent (Doc1.field1, Doc1.field2, doc2.field1,
doc2.field2), or just changing them entirely
(fieldname_randomUniqueString).
I don't know
that iText supports changing 'parentage' while renaming
fields.
When
renaming, you're almost certainly breaking all but the simplest of the script on
those forms... calculation scripts in particular. Parsing that script in
an effort to rename the fields within that script doesn't always work
either. Some scripts might build a fieldname before using it. A
calculation might rely on the different line-item costs being named in a
particular way and create a loop that builds those names as it
goes:
var total =
0;
for (var i =
1 to 10) {
var
fldName = "lineItem_" + i;
var
fld = getField( fldName );
total
+= fld.value;
}
Commander
Data might be able to parse that script correctly, but nothing we can reasonably
build will.
OTOH, such
script could be rewritten with changes like this in mind... a field that thinks
it's name should start with "total" could check it and apply any additions
(before or after) to the field names it builds.
Flattening
is usually the best bet.
--Mark Storer #include <disclaimer>
|
