I’m so frustrated with raw data results in my AppleScript scripts!
Since I upgraded to Mountain Lion (yes, I know) several months ago I come accross issues because of some data returned as raw data. Unreadable! Then I have to guess what I can coerce the data to as to force the result being human readable.
So 2 questions: why is that occuring? and how to deal with that? any magic solution? More and more old good scripts are just ruined and fail at some point.
P.S.: I’m using QuarkXPress 9.5.4.1 above all, but I know that issue is not limited to Quark.
You can write the raw data to file. Then read it in human readable form depending on the type of data. Where is QuarkXPress getting the data from? What kind of file?
For instance, «data FXHM49243F00» which is a Quark’s horizontal measurement. Obviously what I’m after is sth like I’ve always been able to see: 22.274932861328 mm I can only (apparently) coercethe result to real (22.274932861328) when I’d really like to get it as I used to get. Sometimes I send the result in a dialog window to return some information, sometimes I use the results and do maths. but like that I’m stuck.
Edit: What do you mean by writing the data to a file?
You should write the complete hexvalue as a string to a file as data, then read it back as text, that is the only fix I know of, that doens’t loose precision. You can read about files and datatypes (data, <>) in Nigel Garvey’s fine filehandler tutorial here.
Yes, I tried many ways to get the hex to decimal and the closest I got was decimal 1227112192. Think I might have gotten 21.?. Writing to file and reading give I$?.
What I was thinking is that You need all four items rectangle, vertical, horizontal, and angle. Not sure how they do that in the app.
I also was thinking that the op should use an image where the data is known and compare the data.
It seems that the link I posted showed how to get the values through AppleScript commands.
OK, thanks for your inputs, guys! It does not really help me but very appreciated though.
I shall read with attention Nigel’s post. It is so frustrating to write scripts, spending hours on that, and then, some weeks or months later just being stuck.
I don’t know who to blame, Apple or Quark, but at the ned of the day only genius in scripting can keep on scripting cool when it is supposed to help Mac users automating their tasks. I’ve never really considered Automator but I’m not sure it is that easy to learn sth new in order to fix that.
As for writing to file, I’m afraid the raw data is application dependent.
I am sorry if I was unclear, there isn’t much help in reading Nigel’s tutorial on files, because Adobe seems to rely on their own reprsentation of a floating point format, which is why kel and I couldn’t coerce it. (A floating point is representented by two values, one for the mantissa, and the other for the exponent I believe. My attempt was to write the hexadecimal value, to a file, and read it back as a floating point value. The trouble is, is that the hexadecimal value isn’t big enough to be coereced into either a small real, or an extended real. I guess Adobe has realized, that they need reals of a much smaller magnitude, and therefore has created their own format that reflects that fact, and which saves some bytes here and there.)
I read in the link kel posted, that Quark Express, has some of if not the same obstacles, so similiar issues, but they had included a coerce command in their dictionary, which could solve it. That was the coerce command I referred to.
I haven’t contributed to this thread so far because I don’t have QuarkXPress and it’s not clear from the original post just where and how CMYS is seeing the raw data.
I myself never had any such problem with Mountain Lion and I don’t recall reading about anyone else experiencing it. So it’s probably not an intrinsic fault in that system.
Common situations where raw data appear are:
In error messages displayed by scripts which are run outside a script editor, because there’s nothing to decompile the codes back to the relevant keywords for display.
When there’s no corresponding keyword anyway, such as «class utf8».
When a compiled script’s opened in a script editor on a system where something it uses isn’t available ” such as a missing application or OSAX, or a different version of an application or OSAX.
I can’t think of any reason why an application should return its own raw data after a system upgrade if it previously returned AppleScript reals ” unless something happened to it during the upgrade. Have you tried reinstalling QuarkXPress?
I haven’t used QXP for years, but FWIW, this has happened several times in the past. First time was the move to PPC, then I think the move to Intel. If I remember correctly, the coercions have to be installed by a scripting addition. And it usually breaks when there’s some change that breaks the scripting addition.
There also used to be a coerce command you could use instead. I see the OP mentions getting a real from that – I suspect that’s better than he’s going to get any other way, but there used to be something like coerce to millimeter units.
The QXPScriptingAddition is a scripting addition that is needed to do all coercions from FMX data types into native AppleScript types. However, the scripting addition is no longer supported, probably when you run your script with osascript you will see in the terminal something like
dlopen(/Library/ScriptingAdditions/QXPScriptingAdditions.osax/Contents/MacOS/QXPScriptingAdditions, 262): no suitable image found.
That means that the right architecture of the executable that needs to be loaded can’t be used. When using file command I see that the scripting addition is i386 (32-bit executable). But when running AppleScript-editor in 32-bit mode it won’t help either while in Snow Leopard and Lion that was the fix.
When you can make the executable load properly you will make a lot of scripters happy, for the last few years everyone is using the explicit coerce command.
