Re: path to as string
Re: path to as string
- Subject: Re: path to as string
- From: Paul Berkowitz <email@hidden>
- Date: Tue, 28 Jun 2005 11:53:18 -0700
- Thread-topic: path to as string
On 6/28/05 10:15 AM, "Matt Neuburg" <email@hidden> 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'.
>
> 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. If a string can't be represented as pure text it
> would seem most natural for it to come back as Unicode text - that's what
> the Finder does when you ask for the name of a file, for instance. I feel
> like I've walked into a hall of mirrors suddenly; I can't seem to get my
> bearings. And assuming I was thinking of explaining this to someone else, I
> really have no notion how I would do it. m.
I guess this is why they're thinking of deprecating some of this.
For a long time, before we had Unicode in AppleScript or on the Mac, we
could get a certain proportion of non-MacRoman characters via typeIntlText.
I wish someone would direct me to me specs for that type: it seems to be a
sort of hack that is able to represent a certain number of "international
characters" (Cyrillic, Central European, about 15,000 Chinese characters)
using style characteristics. Even when we got Unicode in AppleScript, some
apps could only display characters in this format and wouldn't display
Unicode characters which didn't habe International Text mappings.
There's some sort of overlap between typeStyledText and typeIntlText, at
least in AppleScript, but I don't think anyone has ever explained what it
is.
For some time now the AppleScript term 'string' has encompassed typeText,
typeStyledText and typeIntlText. If you ask any text in one of those formats
what class it is, the result is 'string'. You can ask for the same text 'as
record', and then typeStyledText and typeIntlText will return style
information «class ksty» as well as its plain text «class ktxt». But a plain
text string of typeText will error when coerced 'as record'. (You can get it
cooperate via 'as Unicode text as string as record', since the coercion of
Unicode to string, when it works - i.e. only for such characters as can be
represented in International Text - coerces to the type of 'string' that has
style properties.) I don't know what relation, if any, the «class ksty»
info, which is raw data, has to "style info" properties in applications
which implement that class.
The whole text thing is such a mess. If you check TextEdit, you'll see that
'document' has a 'text' property which is supposed to be of class 'text'
(«class ctxt» this time). If you ask for 'text of document 1' what you
actually get is - apparently - Unicode text (if you ask for class of
result), and you can get 'result as string as record'. However, TextEdit's
dictionary tells us that this 'text' class (in the Text Suite) - 'ctxt':
Rich styled text - has color, font and size properties, but no 'contents'
property or anything else that might have resulted in that Unicode text
result we got. Weird. It's got word, paragraph, character and attachments
elements, mind you.
In Tex-Edit Plus, a model AppleScript app which does styled text. the
'contents' property of selection - itself a subclass of 'text' (ctxt) - is
supposed to be of class 'international text', except here '(get selection)
as record' errors and so does '(get selection) as string as record'- it
seems instead to be plain text (typeText) - only '(get selection) as Unicode
text as string as record' works. Maybe that's an error in the TE+ dictionary
or maybe its developers just did their best with the information available:
TE+ is just about the very best implementation of AppleScript around. I
wouldn't even be surprised if the AppleScript class definitions on which it
depends (like 'international text') changed under it.
According to Chris just the other day, AppleScript is a Developer Tool. I
think what we need is some proper Developer documentation on just how text
of all types is handled in AppleScript.
--
Paul Berkowitz
_______________________________________________
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