We are seeing an odd form behavior and have isolated the apparent trigger to something we are doing in the form script. I'm hoping someone can confirm they see the same problem, details follow:
With that simple form, open the form via the browser (we've tested with both IE and Chrome) and without doing anything else, just save the form (with a new name). When we do that, the saved copy of the form is significantly bigger than the copy we started with. If we then repeat the process using the newly saved file, the third copy is bigger than the second.
This file growth does not happen if you open the file in Adobe Reader (instead of in the browser).
When we look at the file contents via a text editor, what we have found is that each save via the browser is tacking on a chunk of data to the end of the file AFTER the %%EOF mark. This new section appears to be one or more object definitions and ends with another %%EOF. The first portion of the file (prior to the first %%EOF) is identical in all versions of the file.
If you take a copy of the file that has these extra section added, then open and save it in Adobe Reader, it eliminates those extra sections and you get a 'clean', small version of the file again. So those extra sections are clearly erroneous and unnecessary.
Another thing worth noting, we took the script for setting the field access property out of the docReady event and put it as the click event on a button added to the form. If you then open the form, press the button and save it you see the file growth (but not if you don't press the button.) So it doesn't appear related to the docReady event, or timing of when we set the access property of the field.
On the small test form described above the growth of the file is around 13KBytes. But in testing with our real forms we've found that the amount of growth seems to be tied to the size/complexity of the form and the form data. In our most complex form with multiple pages with hundreds of fields and a large amount of XML data (form size is 2+MB), we are getting a file size increase of 700KBytes on each save. This is a therefore, a significant issue for us, particularly since the process in which the form is used requires the users to save it a couple of times a day over the period of a month or more.
What is the value of "Preserve scripting changes to form when saved:" on the defaults tab of Form Properties? If Automatically, does changing to Manually fix the issue?
The test form had that property set to Automatic. I changed it to Manually but I still see the issue unfortunately.
I'm not sure if there is a way for me to actually attach my test form here. I don't have any place to host it that I could just link to.
I would start by exporting the XML data from the form before and after it grows to see if it is the underlying data that is growing and where. Did you define a schema and bind your form fields to a data connection created from the schema? That is always my first step when creating a form. It makes for a smaller saved file not including multiple levels of sub forms in the data structure.
We've have done that with our real forms showing this problem and the XML data does not grow, it's identical. The simple test form I created to reproduce the problem (which just has one field on it) doesn't have a schema defined on it.
If the exported XML is the same, I doubt adding a schema will help other than it may make the file growth smaller. I am thinking the extra data after the EOF is the form data, multiple saves, save multiple copies and opening in Acrobat combines it all together. It is just a theory though.
That may be what it is. It's not even full Acrobat that cleans it up, it's simply opening and saving it in Adobe Reader. The fact that we only see the growth when opening the form via the browser seems to indicate there is a difference in the functioning of Adobe Reader and the control (supplied with Adobe Reader) which the browser uses to open a PDF.