How Do I Persist PDF JS Data Imported from External File via importDataObject

Have you tried placing all of the code that defines and populates the array in a document-level JavaScript? I seem to recall that you were earlier trying to include it in a field-level script.

Originally I had everything in the Field-Level Script, but agreed the better approach was not to commingle its working code with the data it used. I'm now importing and populating the array used by the Field-Level script in a Document-Level script but while the data is being loaded successfully and being consumed successfully by the FieldLevel script, it does not persist when the document is closed and re-opened.

Tried loading THEN deleting the code in the Document-level script where the array is defined, but the field-level script which uses that array produces undefined errors after closing and re-opening the PDF previously loaded with working data.

It seems that when a PDF is closed, the javascript state initialized by Document-level scripts gets automatically zeroed out at closing, or re-run when re-opened, so I need a way to persist globally-scoped Javascript data and structures that will be used by functions in field-level scripts driven by user actions. Documentl-level script below works, but does not persist when PDF is closed, then reopened. Perhaps my syntax for the Doc-Level script is off by being free-form javascript and perhaps it needs to be identified as via function loadData(){...}?

// function loadData(){} DO DOC-level Scripts have to be explicitly identified as functions?
// Document Script Pseudo Code
// Presume DOC SCRIPTS ARE ALWAYS RUN FIRST, SO TEST THAT EXTERNAL DATA HAS BEEN LOADED

if (typeof region == 'undefined') { // Test whether region array already created and loaded
console.println("Region Data not defined, let's load it!");
var bRtn = this.importDataObject("RawDataFile"); // BROWSE for a file to attach as "RawDataFile
console.println("RawDataFile imported");
var streamedRawData = this.getDataObjectContents("RawDataFile"); // Extract Raw data from attached file

var parsableData = util.stringFromStream(streamedRawData); // Convert data stream into parsable data

var region = []; // Define empty array to hold imported data
eval(parsableData); // Execute/Run imported javascript code to populate array
}

What I was suggesting that instead of loading the data from an external file, place the code that you were using before (but wouldn't fit in a field-level script) in a document-level script.

George,

Sorry if I wasn't clear.

The editor limitations (both Acrobat X's own built-in editor and the three external editors I've tried) prohibit actually placing/copying the 40kb data into EITHER a field-level script OR a Document-Level script.

I have created a working Document-Level script (attached previously) that can get around this editor limitation by reading an external file, converting file to a string, then evaluating it - thereby populating the array dynamically from EXTERNAL data.

However, having done that once, I want to keep and persist that data so it remains available to the field-level scripts after the PDF has been closed and then reopened again.

It would be great if I could use the editor to populate the Doc-Level script with raw data, but Acrobat X Pro on MAC doesn't permit this.

I need either:

a) a way to persist Javascript data structures WITHIN a PDF ....or

b) a way to import an EXTERNAL text file and then PERSISTENTLY store IT INSIDE the PDF such that its contents could be be accessed by the intra-PDF equivalents of importDataObject().....or

b) some other approach I've missed.

Hope that helps clarify things a bit.....

Hmm...I wonder if this is somehow a limitation on the Mac. I just created two document-level JavaScripts that are over 100,000 characters and it works fine, using Acrobat 9 on Windows XP.

So far, document-level JavaScripts are loaded by alphabetical order, so you could try breaking it up into four separate JavaScripts. In the first, define the array and do 1/4 of the pushes, 1/4 in the next, and so on.

George,

Is there a way to learn from Adobe if there are Mac-specific limitations with Javascript editor buffers, Document-level and Field-levelscript file sizes, etc? These limitations certainly exist, and I certainly can't have been the first to run into them, so it would be great to learn about them in advance rather than have to waste nearly a week re-discovering them.

I also tried to put the data into a hidden text field then do a simple...

eval(this.getField("dataField").valueAsString);

but hit another size limitation with the text field.

That said, I'll try breaking the data sets into multiple, alphabetically organized document-level scripts to see if I can "serialize" the array instantiation into pieces rather than wrestle unsuccessfully with putting them into a single script.

I just tried on a Mac with Acrobat 9 Pro and TextWrangler as an external editor and it worked with over 100K characters. Acrobat's built in editor wouldn't accept it though. I use my Mac for testing and more informal development, in part because of the console/debugger limitations.

Hopefully Max or Merlin or some other Mac enthusiast can provide more info.