You can read the file and find this line:
<xmp:CreatorTool>Adobe InDesign 7.0</xmp:CreatorTool>
It'll tell you the version (5.0,6.0,7.0, etc.)
I'm pretty sure it used to be xap instead of xmp, but I don't remember off hand which version it changed.
This xmp/xap confusion seems to be prevalent in a lot of places.
We have some software that postprocesses PDFs generated by InDesign on the basis of embedded metadata in those images.
Under CS3, regardless of whether the input image had an xmpMM:DocumentID="uuid:FAFABABE..." or an xapMM:DocumentID="uuid:FAFABABE...", the generated PDF would always have an xapMMmm:DocumentID="uuid:FAFABABE...".
But under CS5, the generated PDFs have xmpMM:DocmentID="uuid:FAFABABE..." -- at least as log as the input does. Go figure...
(back on target for a moment)
Also, watch out. There may be multiple <xmp:CreatorTool> lines. Guess what version of InDesign created this layout?:
$ < file.indd strings -a | grep -i creatortool | sort | uniq -c | sort -nr 84 xap:CreatorTool="Adobe InCopy 5.0" 41 xmp:CreatorTool="Adobe InCopy 7.0" 20 xmp:CreatorTool="Adobe InCopy 5.0" 10 xmp:CreatorTool="Adobe Photoshop CS5 Macintosh" 5 xmp:CreatorTool="Adobe Illustrator CS5" 4 xmp:CreatorTool="Adobe InDesign 5.0" 4 xmp:CreatorTool="Adobe InCopy 4.0" 3 xmp:CreatorTool="Adobe Illustrator CS4" 3 xap:CreatorTool="Adobe Illustrator CS5" 2 <xmp:CreatorTool>Adobe Photoshop CS5 Macintosh</xmp:CreatorTool> 2 <xmp:CreatorTool>Adobe InDesign 7.0</xmp:CreatorTool> 2 xmp:CreatorTool="Adobe Illustrator CS3" 1 xmp:CreatorTool="Microsoft 1 xmp:CreatorTool="Adobe Photoshop CS Macintosh" 1 xmp:CreatorTool="Adobe InDesign CS3 (5.0.4)" 1 xmp:CreatorTool="Adobe InCopy 7.0" 1 xmp:CreatorTool="Adobe Illustrator CS2" $
p.s.: this was not a specially crafted example. It was the first one I tried.
Or you could do something like this....
on open myFile
tell application "Finder"
set myFile to myFile as alias
set mytype to file type of file myFile
if mytype = "IDd3" then
display dialog "This is a CS file."
Build it out with as many versions as you need. Save as an application and drop a file on top of it. I've only had it fail a few times on files where the file type got corrupted in transit, but it has worked for most of them. On those few cases where it's failed, I just opened the document and looked at the version history to get the last saved version.
Not sure where Steven's code is, but RorohikoKris gave the algorithm in Identify the Application Version Cs/Cs2/Cs3???. Though I'm a little confused as to whether he means byte offsets (counting from 0) or byte numbers counting from 1. An INDD file on an Intel mac has a 0x07 at offset 0x020 (32 decimal). In any case, I don't see any examples of anyone who has implemented the code to do the proper byte-swapping for endianness.
My experience is that Mary's method is just not reliable because the Finder gets confused.
Allison, do you want us to mash the above into something usable in AppleScript, or do you have a solution that is good enough?
Hi, John, thanks for your feedback.
I'm just curious -- I know my method isn't 100% reliable because I have occasionally seen a file type get lost, i.e. that there can sometimes be NO file type showing for a file. I address that in my fuller version of the script with a dialog that just says something like "File type not found" when all the other if/then's have been tried and failed, and in those rare instances, I just check it manually.
But is it possible that it would get confused to the point of reporting the *wrong* file type -- for example, showing a file as an "IDd5" when it's really an "IDd6"? I would be more concerned about it giving me false information than I am about it just not being able to answer the question.
Yes, it can definitely report the wrong type.
For instance, install CS5 on a machine that had CS3. Now all previous CS3 layouts show up as CS5 documents.
What I am uncertain on is if the problem will show up on individual files -- I know you can see "all CS3" will show up as CS5, but I don't know if some CS3 files may show up as CS5 and some not.
The correct order of information is:
GUID: 16 bytes. Must be: 0606EDF5-D81D-46e5-BD31-EFE7FE74B71D
Magic: 8 bytes. Usually the text "DOCUMENT" -- I suspect it's *always* this, because ID cannot read/write other file types...
Endianness: 1 byte. 1=little endian (Intel), 2=big endian (Motorola)
"Irrelevant stuff": 4 bytes. (Not my name! It says so in the official documentation!)
Version: 4 bytes, in "endianness" mode.
Yes, the *icon* shows as the latest version, regardless of which version the file really is. If it didn't, we wouldn't be having this discussion -- you could simply tell by looking at the icon which version it was.
But if you ask the file for its file type, the file type still shows as the last version it was saved in, no matter what other versions you have installed. I spot-tested a bunch of files dating from 2002 to present (I had to add the file type for ID2, the last pre-CS version), and it performed just fine on all of them, and I have not had ID2, CS or CS2 installed for some time. I even tried it on some CS5 files, although I don't have CS5 installed yet and it reported back correctly as CS5.
As I said, the only issue I've seen is where a file type gets stripped out entirely, but in the environment I'm working in, I've seen it happen only rarely. However, I absolutely concede that YMMV.
My test case wasn't what the icon appeared as, but instead what version of InDesign it opened with. Possibly that's not the right test, I guess, since maybe you might want to open a CS3 file in CS5... (I feel like there's another subtlety to the problem I am not recalling...)
Jongware: what's the source for that? Buried somewhere in the SDK?
Mary… file type still works as you would expect even with CS5… I'd forgotten that one… That's trying to learn JS for you…
John, that would be the wrong test… When installing app's they bump the systems launch services preference. Opening files should look up this first for the latest version (This was a PITA when I had just installed the trial version)… Sure all the file icons get updated but the file type remains static… or so it appears to me…
Just to add a bit to this, I currently have CS3 and CS4. If I double-click a CS3 file with neither app running, it'll launch CS4. If I open the CS3 application first and then double-click a CS3 file, it won't launch CS4 -- it'll use the application that's open. And if I have CS3 open and double-click a CS4 file to open it.... nothing happens. It doesn't open it, doesn't throw an error message, and doesn't launch CS4.
Yes, thanks, Mark, that's what I was saying -- that it does pick up the correct file type from a CS5 file, even though I don't have CS5 on my machine yet.
Mary, your little script is just what I needed.
I was able to use that information to direct ID CS3 files to open in CS3 and CS5 files to open in CS5 based on the file type.
Can you elaborate on when you got the no file type errors? Do you know what causes some file to not have the file type associated with the file?
Excellent, glad to hear that worked for you.
I'm not 100% sure how the files get corrupted, just that sometimes "file type" shows as completely blank. I've read elsewhere that it may have something to do with resource forks getting stripped out if the files go cross-platform; can't confirm whether that's the case or not. I added a line into my script to give me an error message if file type = "" so I know I have to open that one and look at its history.