Re: path to as string
Re: path to as string
- Subject: Re: path to as string
- From: Christopher Nebel <email@hidden>
- Date: Tue, 28 Jun 2005 12:06:52 -0700
On Jun 28, 2005, at 10:15 AM, Matt Neuburg wrote:
On Mon, 27 Jun 2005 11:29:17 -0700, Christopher Nebel
<email@hidden> said:
This is the subtle bit: the AppleScript "string" type, despite
many people's fervent belief to the contrary, is *not* the same
thing as typeText -- it's allowed to carry style information as
well. Alias-to-string involves coercing the alias to a path,
which is always represented as Unicode text for fidelity reasons,
and then Unicode-text-to-string adds style information because
that's how you represent encoding information in
styled text, ergo, you get an AEDesc of typeStyledText.
You said several things there that looked like you thought (or
wanted me to think) they were totally normal and okay but which I
actually found sort of bizarre and stunning.
"string" and typeText are different? What can this mean? Does it
mean that "string" and "text" are different? No; whether I say
(path to desktop) as string
or
(path to desktop) as text
I still get a styled text as the result. Or maybe typeText and
'TEXT' are different? But typeText is defined as 'TEXT', isn't it?
And when I say
path to desktop as string
I can see that the rtyp is 'TEXT'. So in that sentence, "string"
does mean 'TEXT'.
OK, let me try this again: there are two different interpretations of
the word "string". (Or "text", for that matter; they're synonyms.)
1. When used as a parameter, say to an OSAX, it's passed as typeType
('TEXT'). In this sense, "string" == typeText.
2. As an AppleScript object type -- and this is what I was referring
to above -- a "string" is a glob of text that may or may not have
style information attached to it. In this sense, "string" !=
typeText -- it may get sent out in events as either typeText or
typeStyledText, depending on whether or not there's any style
information.
And then there's the part about using styled text to represent
encoding information, as if this were the most natural thing in the
world. Style is like bold, italic. Encoding is like -- well, it's
like encoding. They don't seem at all similar to me.
Well, they're not, really -- it's a hack from oh, around System 7, I
think. Remember, Unicode was still just a twinkle in various folks'
eyes at the time. Various regions have their own national encodings,
some of which were tweaked/invented by Apple (MacJapanese/Shift-JIS
for Japan, MacRoman (which vaguely resembles ISO-8859-1) for W.
Europe, etc.) Naturally, many of these encodings are disjoint --
there are characters in one that simply don't exist in others. In
order to allow existing applications to use multi-encoded text, they
came up with the clever (if somewhat odd) solution of declaring that
the *font* used dictated the *encoding*. For example, Geneva implies
MacRoman, but Osaka -- the Japanese visual equivalent of Geneva --
implies MacJapanese. Hence, styled text can represent Unicode with
better fidelity than plain text can, because it can use a mix of
encodings by switching fonts.
What *I* don't understand (and you can answer this one in private) is
why any of this is relevant to users, aside from the fact that you
shouldn't be saying "path to ... as string" in the first place. (Use
"as Unicode text" instead.) Picking apart AEDescs is not something
any normal user of AppleScript should need to do. I understand why
you personally do it, but that's not the same thing.
--Chris Nebel
AppleScript and Automator Engineering
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden