this is even the designated way
I apologize but using the document versus the window return the same error.
In both case I must save in a file, not in a string.
KOENIG Yvan (VALLAURIS, France) jeudi 11 juillet 2013 15:14:03
kel1: Thanks for your “«data rdat…” workaround, it does indeed work for creating PDF files. Is this the bom? How do you get it?
FWIW, I’ve corresponded with the developers of PDFpenPro. Their application (for all the good things it does) cannot make a new PDF file without copying at least parts of some existing PDF file. I’ve represented strongly that IMO they need to give their application the capacity to create a new file de novo.
That app is something like Preview. It can edit pdfs, but can’t make them.
In TextEdit, export a blank document as pdf. Then, with the AppleScript Editor, run:
set f to choose file read f as data
Copy the data from the result window and set a variable to it. You could make your script create rtf or pdf by just switching the data.
Edited: BTW, that is not the BOM. Long ago I used to call it the BOM and never found out if it was true that I can remember. I think it’s called the type identifier. But when you get the data like this, I have suspicions that the data includes the formatting info also.
It’s a bit of both. A file or alias specifier has always been the correct form to use with ‘save’, although many applications have become more tolerant of text paths over the years and I seem to remember that ‘save’ in the Jaguar version of TextEdit only worked with POSIX paths!
But now, sandboxed applications ” of which TextEdit is one ” must be given a proper specifier or they won’t be allowed to do the save.
I knew the change introduced by Sandboxing.
I was mainly puzzled by the two messages using a string as file specifier but maybe their authors are using pre-Lion systems.
KOENIG Yvan (VALLAURIS, France) jeudi 11 juillet 2013 18:45:04