another PDF/Acrobat-related problem. When trying to save a PDF with a long filename, the filename is always cut after 29 digits and a “#0” is attached, for example, the proper filename was supposed to be
PD 18 322-11 Fügen_von_PLEXIGLAS®_in_Deutsch.pdf
What’s happening is
PD 18 322-11 Fügen_von_PLEXIG#0
The script:
tell application "Adobe Acrobat Pro"
open ":Volumes:CI:CI Drees Design:¢ SKRIPTDATEN ¢:PD"
do script theJava
save active doc to file saveOrdner
end tell
As you can tell, nothing fancy here. A PDF is opened, some information is filled in by way of JavaScript and the file is saved under in a different name in a different location, resulting in the abbreviated version shown above. Any ideas on why this is happening and how I could get around it? Is it an AppleScript limitation or could Acrobat be the culprit? Actually I presume the problem is probably, as per usual, in front of the computer…
First, I don’t think your script will work because “:Volumes:CI:CI Drees Design:¢ SKRIPTDATEN ¢:PD” is not a valid path… so Acrobat won’t be able to open it. Colon delimited paths always start with the name of your hard drive which I don’t see here.
But assuming your script will work somehow, you can use a “work-around” if you can’t solve your issue directly in application “Adobe Acrobat Pro”. You could use a short name in Acrobat, and then use the Finder to rename that file after its saved with the long name. I don’t believe you’ll have the “too many characters” issue with the Finder.
set saveFolder to "Macintosh HD:wherever:"
set shortName to "a.pdf" -- note we use "a.pdf" as a temporary name
set longName to "PD 18 322-11 Fügen_von_PLEXIGLAS®_in_Deutsch.pdf"
tell application "Adobe Acrobat Pro"
open file "Macintosh HD:Volumes:CI:CI Drees Design:¢ SKRIPTDATEN ¢:PD"
do script theJava
save active doc to file (saveFolder & shortName)
close active doc
end tell
tell application "Finder"
set name of file (saveFolder & shortName) to longName
end tell
tell application "Adobe Acrobat Pro"
open file (saveFolder & longName)
end tell
Hi,
thanks for the replys, let me step through them:
No, this works just fine.
It’s an AFP mounted volume.
Oh, the path works. Since it’s addressing a mounted network volume, having it start with the hard drive wouldn’t make sense in this scenario I suppose.
Awesome suggestion, I’m going to do this until I’m able to resolve the issue directly…or just stay with it, if a nonworkaround-solution doesn’t seem possible.
Thanks for the fast input everyone. @sbriss: I hope, you can work with the infos I gave, I’m looking forward to hearing from you…or anyone else, for that matter. Until then: workaround it is.
