[
https://issues.apache.org/jira/browse/PDFBOX-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17741231#comment-17741231
]
Tilman Hausherr commented on PDFBOX-5629:
-----------------------------------------
I think it is a good idea and I had a look at your suggestion, but for some
reason it is less efficient, why aren't you using {{nextFieldNum}}?
> 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
> Priority: Minor
>
> 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]
