Barcode encoding killing performance

[Former Community Member]

First off I will just say due to customer restrictions I can not distribute this form

So I have a form with 5 pages and 3 barcodes.  The logic for encoding the barcode is in a custom javascript in the calculate method.  I have found that the performance is horrible with scrolling being choppy, tab navigation difficult and the selection of a field being terribly delayed.  I tried moving the logic of the barcode encoding to prePrint, since I really don't need the BC update till then, I get my msgbox at the top of the method and another one at the bottom but the BC does not physically change when printed, even though my last msgbox displays what the BC is supossed to be set to.  Added the logic to postPrint, preSave, postSave and in no instance does the barcode appearance change.  The big positive is without the script in the calculate methos the performance is great, and form navigations flows smoothly.

Please let me know if you have any thoughts on how I might either stop calculate from sucking the life out of my CPU, or how to get other methods to render the BC?  Also along the lines of the BC, I told it to only be visible on print but it is still appearing on the screen, thoughts?

Thank you so much

Cameron

[Former Community Member]

Cameron,

There are a number of factors that can influence the processing overhead required to perform barcode encoding. I assume you are referring to the PaperForms barcode and the PDF417 symbology. This list of factors is not inclusive.

1) XML kills. Avoid using XML formatting.

2) Use single case. The PDF417 encoder spec (not the Reader/Acrobat implementation of the spec) has to encode a character indicating case switching each and every time it encounters a case switch in the data being encoded. Punctuation in the form text introduces the same issue.

3) The use of the compression option increases processing time and can actually reduce data capacity. The compression ratio is highly dependent upon the characteristics of the data being encoded.

4) The complexity of the form and the method for accessing data to be encoded in the barcode. A form with dynamic subforms and tables may require xfa.resolveNode() to access data. This is unavoidable and will influence performance.

5) The number of form fields and the number of events associated with the form fields. A lot of calculate and validation events is going to influence the general performance of the form (and may be hard to avoid).

I would discourage moving barcode encoding from the barcode calculate event. It introduces the likelihood that data will not get encoded.

Steve

[Former Community Member]

Thank you for the reply.

1) I am avoiding XML formatting, everything is pipe delimited.

2)I convert everything to uppercase before encoding.

3)I am not using compression

4)Yes many things are dynamic so I have to use resolveNode.

5)Yes there is a lot of validation and some of it is complex and there is no way around it.

I did find though that moving encoding to the prePrint and preSave works well for performance and that the reason things were not getting encode was because I was doing prePrint and preSave at the barcode level.  I moved encoding to these two methods at the Page level and now I have both the performance I need and the encoding upon print.

The barcode still won't hide itself in reader until printed but I can live with that.