Testing JavaScript on MAC OS

[DavidSmerda]

Hello, 

I have been editing a script originally made by Karl Heinz (link to the original script) and it works flawlessly on Windows OS. But after sharing this script with another pearson on MAC OS, they can't make it work. 

I have made sure that the obtained file path would be compatible with both Windows and MAC OS via the replace() method. 

I can't check it personally (I do not own/have access to MAC) and further investigation is quite delayed due to a different time-zone. 

Could anyone check the script and tell me what's going on?

app.addMenuItem ({cName: "DataMerge", cParent: "Edit", cExec: "DataMergeFx()"});
function DataMergeFx() {
	var sFilePath = this.path;
	var sMetadata = this.metadata;
	var newDoc = this.extractPages(0);
	newDoc.metadata = sMetadata;

	var tmpField = newDoc.addField("Directory", "text", 0, [0,0,100,100]);
	tmpField.hidden = true;
	tmpField.fileSelect = true;
	tmpField.browseForFileToSubmit(); 
	var txtValue = tmpField.valueAsString;
	var txtPath = "/" + txtValue.replace(/:\\/g,"/").replace(/\\/g,"/").replace(/:/g,"/");

	var err = 0;
	var idx = 0;
	while (err == 0) {
		err = this.importTextData(txtPath, idx);
		newDoc.flattenPages();
		if (err == -1)
			app.alert("Error: Cannot Open File");
		else if (err == -2)
			app.alert("Error: Cannot Load Data");
		//else if (err == -3) {}
		else if (err == 1)
			app.alert("Warning: User Cancelled File Select");
		else if (err == 2)
			app.alert("Warning: User Cancelled Row Select");
		else if (err == 3)
			app.alert("Warning: Missing Data");
		else if (err == 0) {
			newDoc.insertPages({cPath: sFilePath});
			idx++;
		}
	}
	newDoc.deletePages(0);
    var nPages = newDoc.numPages;
    for(i = nPages - 1; i>0; i--) {
        newDoc.movePage(0, i);
    }
	this.resetForm();
	this.dirty = false;
}

The person has enabled menu items JavaScript execution privileges and in the last conversation, they mentioned that the console error message looks like this: 

TypeError: this.extractPages() is not a function
5:Folder-Level:App:DataMerge.js

...which does not make sense to me. Nithing like this appears on Windows and the extractPages() method is well defined. 

Everything (the script file and a testing file with random namelist) can be accessed via this link. 

Thanks a lot, 
David

[try67]

That is a very strange error. I don't think it's a Mac issue, though.

Are you sure they are running it in Acrobat, and not in the free Reader?

Also, in the code there are some issues with using the "this" keyword after creating the new document. At that point, "this" might not refer to the old file any longer, so it's better to keep a variable referencing it, and use that one, instead.

[DavidSmerda]

Although I'm quite certain they have access to Acrobat Pro, I'm not sure if they are using Acrobat Reader on their own machine. I will ask them about that. 

Also, in the code there are some issues with using the "this" keyword after creating the new document. At that point, "this" might not refer to the old file any longer, so it's better to keep a variable referencing it, and use that one, instead.

By try67

I never never encountered this, so thank you for pointing that out.

After checking the JavaScript Reference page and it indeed mention the word “usually”. 

var sDoc = this;

Will this line of code suffice? 

Also, a related question to the script, but unrelated to this problem. 

I noticed that when you combine files, the file name mentioned in the tab is Binder1.pdf (also present after you activate the Save as dialog), but under the properties tab, the name is a temporary file with a random string of characters. Is there a way how to achieve something similar after extracting pages? 

[try67]

That would suffice, if you also changed all later references to "this" to be "sDoc", yes.

I believe Binder1 is the title of the file. The file-path is indeed a temporary file name. Which one of those do you want to achieve, exactly?

[DavidSmerda]

Thats the strange thing, the new file does not have any title at all: 

Also, I have also checked the Always use filename as a document title in the preferences. 

What I would like to achieve is after the user saves the document, the Save as dialog appears and the original (source document) file name will be pre-written instead of random string. 

[try67]

You're right. I don't know how they are doing it. Must be some kind of internal name property that's not accessible using a script. I'm afraid you can't populate the file-name in the Save As dialog.

[DavidSmerda]

Thanks for your time try67, 

I will create a new post later today about it, perhaps someone encountered it in the past. 
Some imposition plugins also use this (PLDA from Konika comes to my mind). But it may not be possible with JavaScript.
plugins usually use C#.  

[PDF Automation Station]

I know how to do that.  I'll post later.  On the move...

[DavidSmerda]

That is excellent. 
I will surely take a look when you post it. 

[PDF Automation Station]

Another method to consider that doesn't require extracting pages and working with two documents is to create a template from page 1 of your original document, which can already contain the hidden fileSelect field, import the first row of text data, spawn the template with bRename:true, and repeat in a loop.  Then flatten all the pages at the end, remove the first page, and save the document.

I'm writing an article about how to prepopulate the Save As dialog.  I'll link here when finished.

[DavidSmerda]

I have thought about creating a template from the source file but I quite like the functionality of creating a new document instead of modifyin the original. 

That way, the user can safely return to the original if the resulting file does not meet their expectations. 

[PDF Automation Station]

You excecute a save at the end with the file name modified.  Example:

this.saveAs(this.path.replace(".pdf","_result.pdf"));

[DavidSmerda]

A have looked the PDF reference and the fields would have different names. 

Would that work if the importTextData() works with field names?

I will check that out later tonight, so thanks for mentioning it. 

[Bernd Alheit]

You will get the error message when no document is open.

[try67]

I thought about that too, but expected that the previous lines would cause the same issue. However, it might be different for properties than for methods... So yes, of course a file must be opened in the application for this to work.

[DavidSmerda]

True, 

Thanks for pointing that out.

I will inform the person that they should have an opened document. 

[PDF Automation Station]

I just ran this.extractPages() in the console with no document open and got the exact same error.  Whether this is the issue or not (it looks like it is), it can be avoided by disabling the menu item when no document is open by adding this parameter to app.addMenuItem in the first line

cEnable:"event.rc = (app.doc != null)",

[DavidSmerda]

Excellent point. I will include this line into the final code. 

My solution, after Bernd mentioned it, was to include an if() statement which would show an alert message while running the menu Item without a document being open. 

[PDF Automation Station]

I would start by having them run this.extractPages(0) in the console and see what happens.

[DavidSmerda]

OK, that would also verify the point that try67 made about the Acrobat Reader.

Would you mind checking the code (if you have MAC OS, that is), if the MAC file path is correctly converted to the Acrobat Device Independent Path? 

[PDF Automation Station]

I'm not on a Mac.  Is it necessary when the path is coming from browseForFileToSubmit()?

[DavidSmerda]

Unfortunately yes,

I was also surprised when the output started with D:\... instead of the native D/...

Not sure if it is necessary on MAC, though. 

[PDF Automation Station]

What I mean is, the file path from browseFromFileToSubmit() does not have to be converted to anything.  The path is correct for the users' OS. 

[DavidSmerda]

You are correct. 

What confused me is that the JavaScript reference describes the cPath parameter as a device-independent path to the file. 
I tested inputting the base string from browseFromFileToSubmit(), which is device-dependent, and it works as well.
Guess I must prefer testing over blindly trusting the JavaScript reference. 

Thanks again for pointing that out. 

[PDF Automation Station]

They are both correct DI paths and when assigning a variable to the field value there is no issue.  However, if you trying to write "C:\User\etc.." in a string you will either have to convert it like you did, or escape all the back-slashes:

"C:\\User\\etc..."