Huge performance issue when calculating fields in Acrobat

[tmmls]

Hi,

With this post I would like to ask a question.

I have a 50 page PDF document and each page contains 4 columns of 15 fields. The total of each column of fields should be summarized. when using a script in Acrobat to calculate the fields based on the field names. The script works fine, but when entering values into the fields, using the tab key, it takes 3-4 seconds to navigate between the text fields.

I'm using this script...

event.value = myCalculation(this, "01-A-1");
function myCalculation(myDoc, myText){
     var myResult = 0;
     for (var i=0; i<myDoc.numFields; i++) {
         var f = myDoc.getField(myDoc.getNthFieldName(i));
               if (f.name.indexOf(myText) == 0){
                     myResult = myResult + Number(f.value);
                }
     }
     return myResult;
}

The script checks every element in the document after a field is changed and that's probably the reason the script is slow. Does the Acrobat DOM contains a page object containing only the fields of a certain page ? By checking only the elements of a specific page in stead of the entire document, will boost the performance.

Using the default sum function (without) scripting doesn't affect the performance and works very fast.

Does anyone have any suggestions how this can be solved using scripting ?

Thanks

[try67]

Since the list of fields to add doesn't change (I assume) while the file is being used, you can just hard-code it into your code, instead of iterating over the entire file's (or page's) fields each time.

Alternatively, you can save all the fields' names into an array, and then split it by page number, on the doc-load event. That way you would only need to iterate over that array, instead of the actual fields, which is much faster.

[Thom Parker · Accepted solution]

Another option is to use the "dot" notation to group fields. Then use the "field.getArray()" function to get just the fields needed for the calculation.

Also, it's better to define the My calculation function at the document level so it's defined only once, when the document is opened.

Just doing this will help.  Then you can use the same column summing function in every calculation. If you use the "dot" notation to group column fields, then the input parameter to this function would be the group name.

A note on the SUM function. It is JavaScript. The difference is that you define specific fields for it to sum, instead of iterating over the entire document field set. And redefining a function each time.

Calculations are always a performance issue because they are run every time any field on the form changes. The only way to deal with this is to minimize the number and size of the calculation scripts. 

[tmmls]

Update.

When creating a large PDF-form containing a few hundred fields and a lot of automatic calculated fields, huge performance issues occur. Navigating between fields using the tab key, will take multi seconds to process. My only guess is that any change to a field will trigger the re evaluation process of all fields and all calculated fields.

Eventually, we used a workaround to solve our PDF nightmare, using the feedback of Thom Parker and others.

To solve the issue, we completely disabled automatic field calculations using Javascript ...

app.calculate = false;
this.calculate = false;

On each required field, we added "on blur" action, which triggered a Javascript to perform the required field calculation.

All scripts were saved on a document level. In the scripts, we looped over the required fields using the "dot" notation, limiting the ittiriation process significantly.

One final note. When trying to create "enterprise grade pdf form applications", you quickly stumble on the limitations of Acrobat. The application can be used to build some small pdf-forms, but is not up to the task when building larger pdf-forms. The "prepare form" and "Javascript" modules lack basic important features. Also, the very limited form building features in Adobe Indesign, makes the whole PDF form design and build process not as plezant as it could be.  Adobe should consider bringing the entire PDF form building process to Adobe Indesign. There is definitely room for improvement in the whole PDF form building process.

[Thom Parker]

The best form designer from Adobe is the LiveCycle Designer, now called AEM, which makes no sense to me. Unfortunately, AFAIK, this tool does not create regular AcroForms. It's just for the big bucks enterprise crowd.  It's always amazed me that they have this great platform for creating forms, but haven't made it available to the largest group of PDF forms in existence. It's like they want AcroForms to die. 

InDesign is to too much of an expert tool to be used as a general form designer. If you're going have a good form designer, it has to be usable by the people who are creating the forms, not just design experts. Acrobat works on this level, so it is a good compromise, just not good enough.

There are 3rd party PDF form design products. I don't know anything about them, but I'd think that if someone was to create such a tool, the idea would be to make it better than the Acrobat "Prepare Form" tools.

[Joel_Geraci]

You can actually create AcroForms from LiveCycle Designer... sort of. When you create a Static XFA form, a set of AcroForm fields also get created. If you have a COS editor, you can pop open the PDF, delete the XFA dictionaries and... poof!... you're left with a vanilla AcroForm.

At some point, I'll get around to posting a service that does this online.

[Thom Parker]

Yeah, I invented this bit In fact, I created a plug-in years ago for making this conversion.  It's pretty great, but its only a partial solution. For example, the field names are horrendous. And it only works for the layout portion. You still have to make all the appearance and scripting additions in Acrobat. Although several of these options could be handled through the plug-in.