Try this:
#################################### #!/usr/bin/pythonw
from appscript import *
qxd = app('QuarkXPress')# get the page width pw_hm = qxd.documents[1].page_width.get() # pw_hm is quarks class horizontal_measurement
# coerce horizontal_measurement to k.Float pw_float = qxd.coerce(pw_hm,to=k.Float) print pw_float
###################################
Quark uses a lot of special data types:
agate_units
centimeter_units
cicero_units
inch_units
inch_decimal_units
millimeter_units
pica_units
point_units
base_units
font_units
grid_increment_units
inset_units
leading_units
outset_units
thick_units
trap_units
agates_point
agates_rectangle
centimeters_point
centimeters_rectangle
ciceros_point
ciceros_rectangle
inches_point
inches_rectangle
measurements_point
measurements_rectangle
millimeters_point
millimeters_rectangle
percent_point
picas_point
picas_rectangle
points_point
points_rectangle
angle_measurementYou must be very carefull to use the right data type. This is not an appscript problem! This is a Quark "feature".
If you use has's help() function for the document object you will get exactly the info you need. Try
qxd.help('-t document')and you will get:
======================================================================== ========
Appscript Help (-t document)
Reference: app(u'/Applications/QuarkXPress/QuarkXPress.app')
------------------------------------------------------------------------ --------
Terminology for document class
Class: document -- A document
Parent:
default_document
Properties:
......
page_height : k.vertical_measurement (r/o) -- the height of a page in this document
page_width : k.horizontal_measurement (r/o) -- the width of a page in this document
-------
page_height and page_width are properties of the class document.
The page inherits these properties from the document.
This is another Quark "feature". The object hierachy in Quark is not tree but a labyrinth.
I did coding with AppleScript for years. Most of them to drive QuarkXpress and I agree with has's statments
that you have to distinguish application-related problems from language-related problems!
For the past 2 hours I did my first lines of code with appscript. I'm pretty sure that I will switch to appscript!
Has did a really good job!
Peter
Am 01.04.2005 um 16:23 schrieb has:
'me' wrote:
tell application "QuarkXPress" tell document 1 set pw to page width as real
pw = app('QuarkXPress').documents[1].page_width.get(astype=k.Float)
But I haven't a clue where to find Quark's coercion method,
You pass the type you want the result returned as as an optional argument to the command. It's the same for any app, e.g.:
from appscript import *
print app('Finder').home.items.get(astype=k.alias_list) # return a list of Carbon.File.Aliases
Of course, working out what coercions an application implements can be a barrel of laughs as it's one of those items that's often not documented by the developer.
or the keyword for number.
AE type constants are in Carbon/AppleEvents.py. Appscript scrapes the constant names and lops off the 'type' so that e.g. typeChar becomes k.Char, typeFloat becomes k.Float, etc. A better system is definitely needed, but I haven't figured one out yet.
Any other suggestions for converting this AppleScript coercion into python?
tell application "QuarkXpress"
tell document 1
set pw to (page width as number)
pw.get(astype=k.Char) ## it doesn't like 'astype' or 'k.Char'
The 'astype' argument should work ok. The problem is figuring out what value to supply; you'll get a coercion error otherwise. Try k.Float (what AS calls 'real').
pw.get(type=appscript.k.inch_units) Unfortunately, using one of Quark's classes simply returns another <_AE.AEDesc object>
The 'type' keyword argument isn't recognised, so is simply ignored. (I should really go back to raising an error on unknown argument names.)
The trick of passing a coercion was a complete surprise.
It's what AS does, except AS obfuscates it to look like it's the language doing the coercion, not the application. AS is master of leaky abstractions.
That idea isn't really obvious from the very nice documentation for appscript.
That's because I somehow forgot to document it. Apologies; I've added it to my TO DO list.
I am still hoping to spawn a more fruitful discussion of how to explore an app's interface using appscript.
What do you need to know?
The built-in help() system is good for interactive exploration. Of course, since it depends on the application's terminology resource it can't show you any information not already supplied there; all it does is present what is available in a more helpful fashion. The appscript documentation still lacks a section on the basic concepts and principles behind application scripting which is a problem if you don't already know what you're looking at; obviously this will be addressed at some point.
But if we're complaining about having to be pre-cognizant of the most minute detail
for an App's implementation of AppleScript before being able to do anything with it;
I'd like to point out that being omniscient is a standard requirement for writing IN AppleScript.
Yep. Appscript is NOT a magic fix for the problems caused by individual applications' weird or broken scripting implementations and painfully inadequate documentation; the only solution for that is for individual users to petition those applications' developers to fix these problems. File bug reports, file feature requests, have all your fellow users get onto them too.
The one thing appscript does give you is a decent language to write your scripts in. The AppleScript language, while it has some nice features and [largely unrealised] ideas, is mostly a piece of crud: slow, buggy, woefully short on the sorts of basic functionality you'd expect from any half-decent scripting language, and virtually zero library support. (Not the fault of the AS developers; blame the clueless suits in Apple management for suddenly choking off its life support two minutes after it was born and neglecting it ever since.)
To do the most simple thing, you must bang your head against the wall until you hit upon the secret. Either by chance or by reading other people's discoveries. You're never, ever privy to the source. Don't even try to ask.
The first really useful thing to learn in AppleScript is how to distinguish application-related problems from language-related problems. At least with appscript you only have the application-related problems to deal with (well, once it's finished, anyway; for now there's still some appscript-related issues to knock out, which is why threads like this are always very helpful for me too). And once you know a problem is application related, you'll know exactly whose balls to go bust until it gets fixed. :) No doubt starting with lots of very insistent requests for radically improved documentation.
I am honestly amazed appscript works at all.
I'm not. The underlying technology - Apple events - is really quite sound, if not quite of the comfort levels we're used to seeing in these days of XML-RPC, SOAP, etc. (Remember, OS 7 was designed to run on 30MHz machines with a couple MB of RAM.) Probably the biggest problem is that the original APIs for resolving Apple events and object specifiers are pretty hairy, much harder to master than the equivalent APIs for assembing GUI interfaces, so designing and implementing scripting interfaces was really tough for application developers to do well. Plus you've got good old early-90s Apple slinging all this wonderful powerful complex technology out the door and then not bothering to explain to anyone how to actually use it.
Cocoa Scripting was created to address the former problem (though CS still has lots of problems of its own), and Apple are ever-so-slowly starting to move on the latter (but still have a very long way to go). And hopefully application developers will start providing better documentation and implementations, especially if/when appscript and its ilk start drawing in sizeable numbers of tech-savvy and very demanding new users for this technology, cos there's nothing like a big vocal userbase banging at the door to motivate developers to do better. ;)
Cheers,
has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
