I’m trying to do something pretty simple., use a JavaScript (JS) from AppleScript (AS) to get Acrobat to save a document. In my script the user has two options, to save the file in the default location which is hard-coded into the script or to save it wherever they specify. When default is chosen, everything works. When they specify a location, it all goes to crap. I’ve inspected both the path string and the JS command string I’m sending to Acrobat. They are identical. I’ve even taken the option where I specify the save location and then choose the default location and it fails! In this case the path and command strings appear exactly identical (as far as display dialog is concerned). The error is “ doesn’t understand the do script message”. In Acrobat I also get the error from the JS console “ReferenceError: dle2 is not defined”. Any ideas??
Its not a very simple script (as a whole), but I’ll post what I believe to be the relevant portions. May have to end up posting it all, guess we’ll see. A lot of this isn’t as pretty as it should be, since I’ve been trying anything I can think of to modify it to work. Hopefully I’ve just been looking at all this too long and the answer is really obvious.
display dialog "Please select the folder with the images for PDF conversion."
set docFolder to (choose folder with prompt "Select the folder containing the images for PDF conversion.")
set pathChoice to button returned of (display dialog "Where should I save the files?" buttons {"Default", "Choose Location"} default button 1)
set defaultLocale to "The Great Library:New Arrivals:"
set pathChoice2 to pathChoice as string
if pathChoice is "Default" then
convertFiles(docFolder as string, defaultLocale)
else
set pathChoice2 to (choose folder)
set pathChoice to pathChoice2 as string
convertFiles(docFolder as string, pathChoice)
end if
--display dialog "Please enter the name for your output file:" default answer ""
--set file_name2 to text returned of the result
on convertFiles(docFolder, restingPlace)
.
.
.
tell application "Finder"
set macTempPath to ""
tell application "MSG Helpers"
set macTempPath to UNIXtoMac(tempPath)
end tell
set newFileAlias to ((macTempPath & file_name & ".tiff") as string) as alias
end tell
tell application "Acrobat 5.0"
activate
open newFileAlias
-- set restingPlace to restingPlace as string
tell application "MSG Helpers"
set restingPlace to MactoUNIX(restingPlace)
end tell
-- set restingPlace to restingPlace as alias
--display dialog restingPlace2 & "HELLO"
set randomNum to random number from 1 to 1000
set randomNum to round randomNum
set comboStr to (restingPlace & randomNum & ".pdf") as string
display dialog "this.saveAs("" & comboStr & "")" as string
set commandStr to ("this.saveAs("" & comboStr & "")") as string
do script commandStr
--display dialog js
--do script js
tell application "Finder"
tell application "MSG Helpers"
set restingPlace to UNIXtoMac(restingPlace)
end tell
set name of file ((randomNum & ".pdf") as string) of folder restingPlace to ((file_name & ".pdf") as string)
end tell
quit
end tell
The functions that it calls I don’t think are the problem, because they’re also used when I use the hard coded string.
You’ve got a lot of stuff going on here that probably doesn’t need to be included. What is “MSG Helpers”? If this is just to convert Mac paths to Unix paths (and vice versa), you should just use POSIX Path/File calls. Why are your calls to this application nested in Finder blocks? Where do you define the “file_name” variable? Why are you setting a random number in the file name (there are better ways to generate a unique name if this is, in fact, what you want to do). Acrobat also has a native AppleScript “save” command, why aren’t you using this?
MSG Helpers is a collection of functions I’ve built up over time. I’m using my own path conversion functions, because I wrote them before AppleScript had POSIX path handlers, they work well, and I don’t see any reason to change. The calls are currently nested because when I first write scripts I just write them in a logical order to me. Later on go back and try to make as few nested calls as possible, I’m not to this stage yet. Like I said, I only included the relevant parts of the script, file_name is set as the name of folder. The random number is used because Acrobat 5 does not properly support long file name so you end up with hexadecimal crap at the end of a long file name. The file is named something short enough then, and renamed after Acrobat saves it. The random number prevents collisions with other files that may exist in the destination folder, as well as allowing me to know what the name of the newly saved file is, as the hexadecimal addition is unprecdictable. I have never succeeded in getting Acrobat 5’s save command to work properly, if you know how I’d be all too happy to use it. Please note that I need a Save As, not just a save. Let me outline the script’s function entirely.
TIFF files are saved in a series of folders. The script is given a base folder ot process. It does a recursive depth first traversal of the directory tree rooted at the folder specified by the user. For each folder which contains only image files it uses a command line utility to turn them into multi-page TIFF files. Acrobat is then instructed to open these multi-page TIFF files and save them as a PDF file.
My real question is, why, when given identical (as fas as I can inspect) strings does Acrobat produce different results?
In an attempt to see if the strings being fed to Acrobat differ between using the default location and a user-defined one, I wrote them out to a file before handing them to Acrobat.
this.saveAs(“/Volumes/The Great Library/New Arrivals/890.pdf”)
this.saveAs(“/Volumes/The Great Library/New Arrivals/244.pdf”)
The top line was when I did a user-defined location, it failed as usual. The bottom is when default was picked, it succeeded.
I have NO experience with Acrobat, and I haven’t examined your script, so this is a general shot in the dark related only to the quoted material.
I’m aware that paths and Unicode text have some type of relationship which I don’t understand. Is it possible that the default path is returned as Unicode text and the user-defined path is not? If so, this ‘might’ explain the different behaviors that you are seeing. To test this, try changing ‘as string’ to “as text” or ‘as Unicode text’ when generating the paths.
– Rob (answering on less than the recommended daily dose of caffeine)
Tried changing all my casts to “as text” with no effect. But that is the kind of difference that I feel that this is. I mean, as far as I can inspect, the inputs are identical. Unfortunately I can’t look at the raw memory representation of these two strings.
You might want to take a look at the class of the paths to see if they differ. I know that it seems nitpicky but it’s sometimes the simple things that cause us the most trouble.
set foo to POSIX path of (choose file) as text
(class of foo) as text
--> string
display dialog result
set foo to POSIX path of (choose file) as Unicode text
(class of foo) as text
--> Unicode text
display dialog result
Everything checks out as a string. I’m pretty fanatical about casting things to strings. I’m a native C programmer and the loosely-typed scripting languages make me nervous, so I tend to make sure I know what type is being put where. Thanks again for the suggestion though.
Hmm, the “save” command is giving me problems in X but not in 9.x. Here is a workaround albeit not a great one. When Acrobat opens an image, it automatically converts it to a PDF in your hidden Temporary Items folder. This script will grab that file, move it to the destination folder, and rename it to the desired name. Not terribly elegant but it works for me:
This may actually be the problem. Try casting them as unicode text. According to stuff that I’ve read, AppleScript likes unicode for paths. I guess that I should have stated this in my first reply.
I had a similarly ugly “hack” until I tried to start using the “Save As” function in JS. Unfortunately I only run on Mac OS X here now. Still, under OS 9 I was never able to get Save As to work correctly, could you give me a code snipet?
Rob,
The thing is that AppleScript is not interpretting the path. Acrobat is interpretting the path as a JavaScript.
I’ve found a workable, fairly simple, solution. If I write the string out to a file and then read it back in before handing it to Acrobat, everything works. While this doesn’t explain why something is mis-behaving, its a pretty easy fix.
What a coincidence. I just spent a while working out that bug. I posted the solution to this BBS Sept 23, 2003 under the Subject “Applescript → Javascript → Acrobat 6.0”
The code is there to translate the text to a class Acrobat Javascript will accept.
My code was for Acrobat 6.0. The save as command was more limited in Acrobat 5.0