0

This is a really strange one. Our company has has an InDesign script that, near the end, calls Acrobat (by way of Applescript) to open a PDF file, replace a page in it, then save the file and close it. We've been using this script for over a year and a half now with no issues on 8 of the 9 computers we have. That last one, however, is giving me an odd message when it tries to open and save the file.

To be clear, all 9 computers are Macs, all running OS X 10.9.5 Mavericks. The script is on a central server, so they're all using the same file:

var unlockCover2014 = app.trustedFunction(function (fName, fPrefix)
{
    app.beginPriv();
    var folderPrefix = fName.match(/^.*?(?=JOBS)/);
    console.println("fName is " + fName);
    console.println("folderPrefix is " + folderPrefix);
    var myDoc = app.openDoc(folderPrefix + "Product Templates/ProofCoverNew/proof_cover_2014.pdf");
    myDoc.replacePages(0, fName, 0, 0);
    myDoc.saveAs(fName);
    myDoc.closeDoc(true);
    app.endPriv();
});

This file is stored in the correct folder to be a Folder-level script. 8 of the computers work through this without any trouble whatsoever. The 9th, however, puts this into Acrobat's Javascript console:

fName is /ArtDept/ArtDept/JOBS/425000-425999/425000 Folder/425000_cover.pdf
folderPrefix is /ArtDept/ArtDept/

RaiseError: This file is already open.
Doc.saveAs:9:
 ===> This file is already open.

I do not understand why this computer, alone, thinks that the PDF files are open already. The problem that arises from this is that, when the main InDesign script is done running, two documents are still open in Acrobat, and the one it's supposed to save does not get saved.

Any ideas about what's going on here?

Sturm
  • 689
  • 2
  • 23
  • 52

2 Answers2

1

Is it possible that the Acrobat script is ran while InDesign has not totally ended writing the PDF File if this is what we are talking about ? Or maybe there are some network latencies that make the file not reachable for the moment.

I would advice using a delay to (in)validate that theory.

delay 3

On another end, why do you need to replace file. I mean can't this be thought in InDesign Scripting Scope only ? Just curious.

Loic
  • 2,173
  • 10
  • 13
  • I'm afraid your idea of introducing a delay does not work. (Incidentally, the command `delay` does not exist in Javascript, so I had to use [a custom function](http://www.sitepoint.com/delay-sleep-pause-wait/) in order to introduce a 3-second delay.) Thus, I don't think the problem lies in the script running too fast or asynchronously so that the PDF file isn't completely written before Acrobat tries to open it. Nice thought, though. – Sturm Feb 19 '15 at 14:23
  • As for why this needs to be done in the first place: As far as I know, InDesign does not have the capability to add editable form fields to a PDF file; only Acrobat can. Thus, we have a custom "template" which has all of the editable fields on (essentially) a blank page. The Acrobat part of the script is supposed to open that template, replace the blank page with the one exported from InDesign, then save & close that template to a new file in the proper location. Seems silly, but unless InDesign has the capability to add editable form fields to PDFs, this is what we must do. – Sturm Feb 19 '15 at 14:26
1

I did finally discover what the problem was. I feel a bit silly about how (almost) obvious it is, but perhaps it might help others in my situation.

I disabled the line in the main InDesign script that was calling Acrobat, figuring I'd come back to that problem later after I dealt with some other issues. When I did so and ran the main script again, I discovered that Acrobat does, in fact, already open up a copy of that cover sheet PDF sometime during the execution of the main script! I was shocked, at first, but then I did a headdesk when I quickly realized the cause:

InDesign on this computer is set, by default, to automatically open a PDF after exporting it.

So, I just added a short line to the part of my code that sets the PDF Export Preferences to turn that feature off:

with (app.pdfExportPreferences)
{
    pageRange = proofRange;
    if (multiColor) pageRange = colorTable.toString();
    useSecurity = true;
    disallowChanging = true;
    disallowCopying = false;
    disallowDocumentAssembly = true;
    disallowExtractionForAccessibility = false;
    disallowFormFillIn = true;
    disallowHiResPrinting = false;
    disallowNotes = true;
    disallowPlaintextMetadata = true;
    disallowPrinting = false;
    changeSecurityPassword = "(NOPE)";
    viewPDF = false;
}

It's the viewPDF line at the end. (Sorry, I don't think I can highlight it with markdown.) I do feel silly that I overlooked such a semi-obvious cause, but I hope this might help someone else who is experiencing a similar issue. Thanks for trying to help anyway, @Loic.

Sturm
  • 689
  • 2
  • 23
  • 52