Stefan Ziegler created PDFBOX-5629:
--------------------------------------
Summary: Custom AcroForm Field renaming function in
PDFMergerUtility
Key: PDFBOX-5629
URL: https://issues.apache.org/jira/browse/PDFBOX-5629
Project: PDFBox
Issue Type: Wish
Components: Utilities
Affects Versions: 2.0.28
Reporter: Stefan Ziegler
In PDFMergerUtility field name collisions are handled. The second field gets a
new name like dummyFieldName1. The number is incremented with each new
collision.
Could you please add a new protected method where these collisions are handled?
Then we can extend PDFMergerUtility and override the method and give it a
better name.
dummyFieldName doesn't say much currently and there you can't derive what this
was about. We would find better e.g. the following version:
For example, if there is a field named XXX in both documents, then during
collision resolution the second field could get one like XXX+1. We would then
increment the number at the end if there would be further fields with the name.
The advantage is that the actual name XXX is kept, because this name contains
the information about what kind of field it was. With dummyFieldName you don't
know anymore what it was about.
In the end, you would simply create the following method, which then contains
the current implementation:
{code:java}
protected void handleFieldNameCollision(PDAcroForm destAcroForm, PDAcroForm
srcAcroForm, PDField srcField, COSDictionary dstField);{code}
The default implementation of the method above can simply be the following,
which is what you currently do:
{code:java}
protected void handleFieldNameCollision(PDAcroForm destAcroForm, PDAcroForm
srcAcroForm, PDField srcField, COSDictionary dstField) {
final String prefix = "dummyFieldName";
for(int i=1;; i++) {
String newName = prefix + i;
if (destAcroForm.getField(newName) == null) {
dstField.setString(COSName.T, newName);
break;
}
}
}{code}
Then we can simplify the acroFormLegacyMode function like this:
{code:java}
private void acroFormLegacyMode(PDFCloneUtility cloner, PDAcroForm
destAcroForm, PDAcroForm srcAcroForm) throws IOException
{
List<PDField> srcFields = srcAcroForm.getFields();
COSArray destFields; if (!srcFields.isEmpty())
{
// get the destinations root fields. Could be that the entry doesn't
exist
// or is of wrong type
COSBase base = destAcroForm.getCOSObject().getItem(COSName.FIELDS);
if (base instanceof COSArray)
{
destFields = (COSArray) base;
}
else
{
destFields = new COSArray();
}
for (PDField srcField : srcAcroForm.getFields())
{
COSDictionary dstField = (COSDictionary)
cloner.cloneForNewDocument(srcField.getCOSObject());
// if the form already has a field with this name then we need to
rename this field
// to prevent merge conflicts.
if (destAcroForm.getField(srcField.getFullyQualifiedName()) != null)
{
handleFieldNameCollision(destAcroForm, srcAcroForm, srcField,
dstField);
}
destFields.add(dstField);
}
destAcroForm.getCOSObject().setItem(COSName.FIELDS,destFields);
}
}{code}
This would be the same as the current implementation but this gives us the
ability to override handleFieldNameCollision so that we can handle name
collisions in a different way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
