Finder file mapping

Thank you, everyone, for your comments and suggestions.

First, I would like to report to you that my problem is fixed now.
(disregarding Finder's 'bug', that is.)

The help came from Jolin, who said:

> > If I have a thousand such files, I can open 10 Get Info windows at
> > a time, and the problem would be completely solved by a mere
> > hundred passes.
>
> Select multiple files, hold down the 'ctrl' key when choosing 'Get
> Info' (or press ctrl-cmd-I) and you can open one 'Get Info' window
> for all the files. This way you can change the 'Open with' for a
> group of files in one step.
>
Bravo! That was what I needed. Thank you!!
Indeed. Ctrl-cmd-I opened a Multiple-Item-Info window, from which
I can change the setting for dozens of files at once!

I am now 100% happy. AppleScript may not be able to do it, but
Finder's (hidden) menu item was able to do it!


Sander asked:

> > (And, there is _no_possible_ ApplliScript method to reach
> > the Open With... pop-up menu in the Get Info dialog, I suppose.)
>
> Not entirely sure what exactly you mean... You can add scripts to the
> contextual menu through Big Cat: <http://ranchero.com/bigcat/>.
>
Which script?
I know how to set file's creator code with AppleScript, but I do not
know how to set one particular file's preferred open-with application
in the way as set via the pop-up menu in Finder's Get Info window.
If you know, please instruct me the exact AppliScript command that
does it.


Sander wrote:

> I'm not sure (these things change in each Mac OS X version) but I think type
> identifiers (UTIs) override creator code. So you might want to compare the
> type identifiers of those files that are bound to Alpha and those bound to
> JeditX. In AppleScript:
> type identifier of (info for (choose file))
>
> UTIs, introduced in Tiger, allow for much more detailed differentiation than
> file type/creator codes do. Hopefully, you can use two different UTIs, one
> for files you want opened in Alpha, and one for ones you want opened in
> JeditX. I do not know what would be the right tool to set files' type
> identifiers, nor how to decide exactly what UTI to assign... I suppose you
> can make up your own, but that might not be necessary/ideal. Hopefully
> someone else can jump in here.
>
I don't understand, sorry. _All_ of my text files, English text files
that are saved by AlphaX, Japanese text files that are saved by JeditX,
or text files transferred from my PowerMac (Mac OS 9.2.2-J), return the
same. That is, _all_ of them return:

"com.apple.traditional-mac-plain-text"

for my "type identifier of (info for (choose file))" AppleScript run.
No difference between the English and Japanese documents.


You said:
> UTIs, introduced in Tiger, allow for much more detailed differentiation
> than file type/creator codes do.
>
I agree it's more "detailed" than type (that's 'TEXT'), but
I strongly disagree your saying that it is more detailed than creator.

Just saying "com.apple.traditional-mac-plain-text" does _not_
differentiate which application created that file, at all!


Todd wrote:

> RCDefaultApp may be able to help you with this.
>
No! I definitely do not want all text files be opened by a single
application. I want certain (English) text files be opened with AlphaX,
and certain other (Japanese) text files be opened with JeditX.


Johann wrote:

> I think, but am not certain, that for file types that have not been
> expressly set to open with a certain default application, Mac OS X uses
> either the oldest (from install date) application that can handle that file
> type, or the most recent application that can handle that file type. Your
> data would seem to indicate that it is the "oldest".
>
So, you mean that file's creator code is ignored, do you?

(I guess TextEdit, Safari, ..., etc, were "older" than Jedit4 on the
machine, all of which "can handle" the 'TEXT' file type...?)


kazar quotes from <http://kb.iu.edu/data/aemh.html>:

> While file types and creators are supported in Mac OS X, not all files
> have them,

If creators are supported in Mac OS X, then why it is not supported
in Mac OS X Finder launching document files? I would consider it as
a bug.

That is, if no default app is specified for the file type, and
no filenmae extension is given, but if the file creator code is
provided, then LaunchServices should use that data
(_not_ "the oldest application that can handle that file type")
in choosing the application that opens the document file.


kazar wrote:

> I don't recall if you stated how all these English and Japanese text
> documents arrive on your hard drive to begin with
>
Those TEXT document files come from my PowerMac running Mac OS 9.2.2-J,
which still is my main machine. Text document files travel back and
forth between the two machines, so putting filename extension to
virtually all files is out of the question, sorry.

The English TEXT files and the Japanese TEXT files are already clearly
distinguished by the files' creator code. Simple.


But in any case, I am happy now, as I said, thanks to Jolin's
wonderful suggestion about using ctrl-cmd-I in Finder.
I can now use the 'Open With' pop-up menu on the
Multiple-Item-GetInfo window, to set the preferred application
for any number of files at a time. I can set any application for
_those_ document files only, at any time, at my will.

Case solved.

Thank you again, everyone.

Mark
--
Mark Nagata
mailto:nagatakurims.kyoto-u.ac.jp
TidBITS Japanese Translation Team
http://www.tidbits.com/tb-issues/lang/jp/

At 16:20 on 21-03-2008, Datatude wrote:
> On 2008-03-21 9:48 AM, Jolin M Warren wrote:
>> The creator code _should_ determine what app opens your documents,
>
> Are you sure about that?

As I recall, OS X uses the following "flow" to decide which application to
use when opening a file:

Application binding ==> Creator Code ==> file extension ==> File Type

In other words, if you've used the Open With setting to tell OS X to open a
text file with JEdit, it will be opened with JEdit. If no application
binding is present, OS X will look for a legacy Creator Code. If that isn't
found, the file extension takes precedence. If there's no file extension,
the legacy File Type code determines the application, based on your
file-mapping setting for that file type. Finally, if none of these are
present, the document is, well, generic; you'll be asked which program you
want to use to open the document.

At least that's how it was a couple years back; I haven't researched this
recently, although I'd be surprised if Apple changed the behavior.

On 21-Mar-2008, at 17:20, Datatude wrote:
> On 2008-03-21 9:48 AM, Jolin M Warren wrote:
>> The creator code _should_ determine what app opens your documents,
>
> Are you sure about that? I cannot claim any academic/book knowledge on
> this topic, but just as a matter of observation on my OS X computers
> it
> seems the Finder gives predominance to the filename extension (a sea
> change from OS 9, yes) for the Open With ... choice it makes, and does
> not care about creator code (which I have read is much deprecated and
> due to disappear from the Mac OS at some point).

No, creator code is NOT deprecated and is NOT due to disappear. And
yes, the order of precedence is well defined by Apple and metadata
type/creator is ahead of extension.

<http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/FileSystemGuidelines.html
 >

"Whenever you save a document, you should make sure the file you
create for that document contains the following information:

     * A type code
     * A creator code
     * A filename extension"

<http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/FilenameExtensions.html#//apple_ref/doc/uid/20002297-110671
 >

"Applications may set a creator type for documents they create. Doing
so creates a tight binding between the document and the application
that created it. Applications should not quietly change the creator
type for documents that already have one. If you want to change the
creator type of documents your application opens, your application
should post a Save dialog when the user saves the file. This gives the
user an opportunity to rename the file as needed. You might need to do
this if editing a document in your application changes the type of the
file. In this case, you should also assign an appropriate filename
extension to the file in the Save dialog."


> For example, I have done a Get Info/Change All on a jpeg so that all
> jpegs are opened with Graphic Converter. If I double-click in the
> finder
> on any document with a .jpg extension, whether it was created or saved
> with GC, or is downloaded and has no icon/no creator code, or was
> created with, say, Photoshop -- REGARDLESS OF CREATOR

Yes, because the user specified choice is the top precedence. You set
"change all", and the system respects that.

Here is the order that LaunchServices uses:

<http://developer.apple.com/technotes/tn/tn2017.html>
1 Has the user specified the application for this document?
2 If a creator was provided, look for applications with the creator.
3 If an extension was provided, look for applications that claim they
can open files with the provided extension (comparison of extensions
is case insensitive).
4 If a file type was provided, look for applications that claim they
can open files with the provided type.
5 In any case, if the located application does not claim to handle
documents like the supplied inputs, it is not considered eligible and
is skipped.
6 Select the first application from the collection giving preference
first to native applications, then Classic applications.
7 Break any ties of the same application by choosing the latest
version number.

So, the user choice is first, followed by the creator code, then the
extension, and THEN the file type code.

At 04:13 on 23-03-2008, Datatude wrote:
> come up with a means to apply a unique extension for Japanese files

While it is true that Apple emphasises that filename extensions are
important in OS X, I don't believe they ever advocate a user should
make up their own extensions. And this issue shows how inept filename
extensions are -- I want some HTML files to open in Camino and some
in PageSpinner; I want some text files to open in TextWrangler and
some in TextEdit. There's no way to specify this with filename
extensions. And creating two extensions ('.phtml' and '.chtml') is
really the _wrong_ way to achieve my aims. Both files are HTML files,
I just want them bound to different applications. Trying to embed
binding information into file type information will lead to misery in
the future.

> downloaded docs that almost always have type/creator info stripped anyhow.

Actually, Camino assigns type/creator codes to files it downloads
(which also shows that you were right to be suspicious about the
comment stating that no OS X-native applications set type/creator
codes).

Anyway, I agree that type/creator codes have been left in for legacy
support and that Apple originally pushed people towards filename
extensions. As Sander has pointed out, Apple is now moving towards
UTIs which are constructed based on a variety of factors (both
type/creator codes and filename extensions) but which we can't
explicitly set. However, throughout all of this file creator codes
should work to ensure a file will open in a particular application.
This has been successful on my computer for years now (except when
LaunchServices gets messed up!). All-in-all, though, I think the fact
that Apple has not come up with a robust system that addresses both
typing and application binding for files is the biggest deficiency in
OS X. Type/creator codes were far from perfect, but they were a lot
better than the total mess we've been living with for years!

_________________
=> Jolin

At 04:16 -0700 UTC, on 2008-03-24, Mark Nagata wrote:

[...]

> Indeed. Ctrl-cmd-I opened a Multiple-Item-Info window, from which
> I can change the setting for dozens of files at once!

FWIW, Cmd-Opt-I does the same, but gives you a floating window. A downside is
that you can only close that window with a mousepointer. The upside is that
you can change your selection; the floating window will immediately reflect
that change.

[...]

>> > (And, there is _no_possible_ ApplliScript method to reach
>> > the Open With... pop-up menu in the Get Info dialog, I suppose.)
>>
>> Not entirely sure what exactly you mean... You can add scripts to the
>> contextual menu through Big Cat: <http://ranchero.com/bigcat/>.
>>
> Which script?

I don't know. As I said, I am "not entirely sure what exactly you mean". It
would probably be more useful if you'd explain what you're asking, than to
ask what my answer means :)

> I know how to set file's creator code with AppleScript, but I do not
> know how to set one particular file's preferred open-with application
> in the way as set via the pop-up menu in Finder's Get Info window.

Sorry, I don't know how to do that through AS.

[... UTIs]

> _All_ of my text files [...] return:
>
> "com.apple.traditional-mac-plain-text"

Hrmpf. That's not one I had expected. More something like public.text.plain.
Oh well, I guess UTIs aren't that mature yet (in Tiger at least).

To explain: I would think that with UTIs something like this were possible:
"public.text.plain.ascii", "public.text.plain.utf-8",
"public.text.plain.iso-2022-jp", etc.

[...]

> Just saying "com.apple.traditional-mac-plain-text" does _not_
> differentiate which application created that file, at all!

Right. I'm just saying that with UTIs creator codes are not necessary
anymore. A UTI like "public.text.plain.ascii" could be bound to Alpha and
"public.text.plain.iso-2022-jp" to JeditX. This is a nicer scheme than the
old file type/creator code combos, because it can work across machines.
Suppose you have a file that, through creator code, is bound to JeditX. You
move it to a machine that has no JeditX. You then have only the (not very
user-friendly) creator code as a clue which application to open it with. A
UTI would be easier to read.

(I know this is somewhat theoretical as long as Apple doesn't provide a
decent GUI to allow people to actually work with UTIs.)

> Todd wrote:
>
>> RCDefaultApp may be able to help you with this.
>>
> No! I definitely do not want all text files be opened by a single
> application.

Right. But we're trying to help by figuring out if your files already do have
something that can be used to recognize whether they are english or japanese,
and use that to bind each to an application, which RCDefaultApp can do.
(RCDefaultApp allows you to make UTI-based bindings btw).

Anyway, now that you've solved your problem, you mihgt want to consider using
a naming scheme like I suggested. Instead of just "filename.txt", name your
files "filename.en.txt" and "filename.jp.txt". That way, if your
LaunchServices database ever gets screwed up, you'll still have a (visual and
thus more user-friendly) indentifier through which you can quickly configure
things again (or even just make incidental decisions). It would also be
helpful when you transfer your files to some other machine. (You now have the
creator types set as you want them, but that won't help when you move the
file to an environment that doesn't know about creator types: anything not
Mac.)

[...]

> Those TEXT document files come from my PowerMac running Mac OS 9.2.2-J,
> which still is my main machine. Text document files travel back and
> forth between the two machines, so putting filename extension to
> virtually all files is out of the question, sorry.

I don't understand. Mac OS pre-X has no problem with file name extensions
other than that it doesn't consider them very important. What would be the
problem to add file name extensions? (Other than the work, but part of that
could no doubt be automated.)


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

At 04:16 -0700 UTC, on 2008-03-24, LewisGmail wrote:

[...]

> Here is the order that LaunchServices uses:
>
> <http://developer.apple.com/technotes/tn/tn2017.html>

That says it was "Updated: [Apr 17 2001]", long before UTIs were introduced
(in Tiger). It cannot be describing the current situation anymore.


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On 03/25/2008 06:59 AM, "Sander Tekelenburg" <tekelenbeuronet.nl> wrote:

>
>> I know how to set file's creator code with AppleScript, but I do not
>> know how to set one particular file's preferred open-with application
>> in the way as set via the pop-up menu in Finder's Get Info window.
>
> Sorry, I don't know how to do that through AS.

In Mac OS X 10.5 at least, you do it via System Events. The Default
application is a r/w property of a file. You can't do it via the Finder, at
least not in AppleScript.

--
John C. Welch

At 04:59 on 25-03-2008, Sander Tekelenburg wrote:
> FWIW, Cmd-Opt-I does the same, but gives you a floating window. A
> downside is that you can only close that window with a mousepointer.

Actually, hitting cmd-opt-I again will close the window. When trying
to close floating windows, it's worth trying the same shortcut keys
you used to open it (doesn't always work, but often does).

At 04:59 on 25-03-2008, Sander Tekelenburg wrote:
>> Just saying "com.apple.traditional-mac-plain-text" does _not_
>> differentiate which application created that file, at all!
>
> Right. I'm just saying that with UTIs creator codes are not
> necessary anymore. A UTI like "public.text.plain.ascii" could be
> bound to Alpha and "public.text.plain.iso-2022-jp" to JeditX.

I don't really agree that UTIs eliminate the need for creator codes.
Information describing a file's content (its type) is completely
different, conceptually and often in practice, than the information
about what application should open a file. I could have files that
are all Unicode text and even if Apple started using a UTI such as
'public.text.plain.utf-8' I would still want some to open in
TextWrangler and others to open in TextEdit. (As it turns out, Apple
seems to use either 'public.plain-text' or
'com.apple.traditional-mac-plain-text' for text files' UTIs, so we
don't even get information about whether they're Unicode or not.)

_________________
=> Jolin

This all continues to be a mess, but I am rarely surprised/disappointed by the application that opens a file when I double click it. Why? Because if I anticipate any ambiguity, or want to work with a file across several applications, I drag the file to the icon of the desired application in the Dock.

Yes, my dock has a zillion little icons in it, but the position of applications in my dock rarely changes and I use modest magnification increase the size of the target as I get near it.

It's really quite liberating to grab any pdf, for example, and drag it to Preview if I want a lovely concordance style search or to Acrobat if I want to do some touch-up editing.

I just scanned this thread and didn't see this mentioned anywhere. You can right click on any file and pick an "Open with" for just that file "that" time.

David

On 24-Mar-2008, at 05:16, Dan Frakes wrote:
> At 16:20 on 21-03-2008, Datatude wrote:
>> On 2008-03-21 9:48 AM, Jolin M Warren wrote:
>>> The creator code _should_ determine what app opens your documents,
>>
>> Are you sure about that?
>
> As I recall, OS X uses the following "flow" to decide which
> application to
> use when opening a file:
>
> Application binding ==> Creator Code ==> file extension ==> File Type
>
> In other words, if you've used the Open With setting to tell OS X to
> open a
> text file with JEdit, it will be opened with JEdit. If no application
> binding is present, OS X will look for a legacy Creator Code. If
> that isn't
> found, the file extension takes precedence. If there's no file
> extension,
> the legacy File Type code determines the application, based on your
> file-mapping setting for that file type. Finally, if none of these are
> present, the document is, well, generic; you'll be asked which
> program you
> want to use to open the document.

Except for your use of the word 'legacy' this is all correct. There are
a couple of other steps as I showed in my posting, but for the vast
majority of files, those 4 steps are the only ones that matter.

--On 3/25/08 4:59 AM -0700 Sander Tekelenburg wrote:

> At 04:16 -0700 UTC, on 2008-03-24, Mark Nagata wrote:

>> Just saying "com.apple.traditional-mac-plain-text" does _not_
>> differentiate which application created that file, at all!
>
> Right. I'm just saying that with UTIs creator codes are not necessary
> anymore. A UTI like "public.text.plain.ascii" could be bound to Alpha and
> "public.text.plain.iso-2022-jp" to JeditX.

Maybe not necessary anymore in THIS case--English versus Japanese text--but
still necessary in general.

My biggest annoyance on this front is HTML files. There are, in my universe,
two categories of HTML files: things I want to view, and things I want to edit.

With a creator code, I can set downloads to be created by FireFox (since I
usually want to view them) and keep my own web page files created by BBEdit
(since I usually want to edit them). Software developers who provide HTML
read-me files can give them the Safari creator code, knowing that 99% of users
want to view them in a browser rather than a text editor.

My (not-that-satisfactory) solution is to keep the public.html UTI bound to
BBEdit, and to attach individual files to FireFox on an as-needed basis.

The worst case I've encountered is an application--I forget which--where the
help/documentation files were HTML files stored inside the application package,
and the help routine called the OS to open the files using the default, which
in my case was BBEdit. So the only way to make the help open directly in a
readable format was to go into the package and change the "Open With..."
application for the help files I found in there.

(Yes, they coulda/shoulda used a file:// URL, which would have opened the file
in the default browser. But still--there is a difference between HTML-to-edit
and HTML-to-view, and UTIs are completely useless for making that distinction.)

Dave Scocca

At 04:12 on 30-03-2008, Dave Scocca wrote:
> Software developers who provide HTML read-me files can give them
> the Safari creator code, knowing that 99% of users want to view
> them in a browser rather than a text editor.

Or leave the creator code blank so the user's default HTML handler
opens the files. This is one of the cases where not using a creator
code is actually useful!

_________________
=> Jolin

On or about 3/30/08 4:12 AM, thus spake "Dave Scocca" <davescocca.org>:

> My biggest annoyance on this front is HTML files. There are, in my universe,
> two categories of HTML files: things I want to view, and things I want to
> edit.

In my universe, there is one category of HTMLs: things I sometimes want to
view and sometimes want to edit. So no mapping-based division of labor can
work. I've added to my Finder a command "Open With BBEdit." So double-click
does one thing (open for viewing), select and "Open With BBEdit" does
another (open for editing). Problem solved. m.

--On 3/30/08 12:52 PM -0700 Jolin M Warren wrote:

> At 04:12 on 30-03-2008, Dave Scocca wrote:
>> Software developers who provide HTML read-me files can give them
>> the Safari creator code, knowing that 99% of users want to view
>> them in a browser rather than a text editor.
>
> Or leave the creator code blank so the user's default HTML handler
> opens the files. This is one of the cases where not using a creator
> code is actually useful!

But what if the user's HTML handler is BBEdit? That's explicitly what the
developer DOESN'T want to happen with a help file--for the user to get a screen
of HTML gibberish rather than a readable help document.

Actually, I just discovered that even a file:// URL doesn't get sent to the
browser. Using the creator code for Safari or Apple's Help Viewer (or using an
event to tell the browser to open the file) seems to be the only way to
guarantee that the help file will be readable.

Dave Scocca

At 17:04 on 30-03-2008, Dave Scocca wrote:
> --On 3/30/08 12:52 PM -0700 Jolin M Warren wrote:
>
>> At 04:12 on 30-03-2008, Dave Scocca wrote:
>>> Software developers who provide HTML read-me files can give them
>>> the Safari creator code, knowing that 99% of users want to view
>>> them in a browser rather than a text editor.
>>
>> Or leave the creator code blank so the user's default HTML handler
>> opens the files. This is one of the cases where not using a creator
>> code is actually useful!
>
> But what if the user's HTML handler is BBEdit? That's explicitly
> what the developer DOESN'T want to happen with a help file--for the
> user to get a screen of HTML gibberish rather than a readable help
> document.

If the user has BBEdit set as their default HTML handler, it's likely
that they have some knowledge of HTML and will understand what's
going on. I think it's worse to force people to use certain
applications. I never launch Safari (preferring Camino) and would
find it annoying if a developer forced me to use it for their readme
file by hard-coding Safari's creator code. This used to happen a lot
(coded to IE) in OS 9. Of course, with QuickLook this is becoming
irrelevant as I tend to use it for readmes!

Regarding help files accessed from an apps help menu, this is of
course different and should be set so they open in the help viewer,
not the user's default browser.

_________________
=> Jolin

At 04:12 -0700 UTC, on 2008-03-30, Dave Scocca wrote:

> --On 3/25/08 4:59 AM -0700 Sander Tekelenburg wrote:

[...]

>> Right. I'm just saying that with UTIs creator codes are not necessary
>> anymore. A UTI like "public.text.plain.ascii" could be bound to Alpha and
>> "public.text.plain.iso-2022-jp" to JeditX.

[...]

> With a creator code, I can set downloads to be created by FireFox (since I
> usually want to view them) and keep my own web page files created by BBEdit
> (since I usually want to edit them).

True, creator types help you there. But this sounds like an exceptional use
case to me. How many people download HTML files in order to be able to
double-click them to have the HTML be interpreted? There's no doubt in my
mind that well over 99% of users will let their browser load such files
directly -- what they call "clicking a link", "browsing".

I mean, no doubt you already need to override your browser's default
behaviour anyway to get it to save text/html files to disk. That's just how
it is with text/html: it's the most common file type that people want opened
in different apps depending on the situation. I don't believe that translates
to creator types being necessary in general.


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

At 03:16 -0700 UTC, on 2008-03-31, Dave Scocca wrote:

> --On 3/30/08 12:52 PM -0700 Jolin M Warren wrote:

[... text/html help files]

>> Or leave the creator code blank so the user's default HTML handler
>> opens the files. This is one of the cases where not using a creator
>> code is actually useful!

I don't know what, if anything, Apple's documentation says, but yeah, I
always thought this was the best approach.

> But what if the user's HTML handler is BBEdit? That's explicitly what the
> developer DOESN'T want to happen with a help file--for the user to get a
>screen
> of HTML gibberish rather than a readable help document.

A decent developer realizes that it's not up to him to mess with the user's
set-up. If I have HTML files mapped to BBEdit I'll damn well have a good
reason for that and I'll be quite annoyed when some developer messes that up
because he thinks he knows better.


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

At 07:40 on 31-03-2008, Sander Tekelenburg wrote:
> That's just how it is with text/html: it's the most common file
> type that people want opened in different apps depending on the
> situation. I don't believe that translates to creator types being
> necessary in general.

There are plenty examples of other files on my system that I assign
creator codes to so that some open in one application and some in
another: Word files, RTF, Excel files, text files, PDFs, etc... Just
because most people don't need creator information most of the time
doesn't mean that it's not a useful piece of metadata to support. And
it's particularly galling that we've had this flexibility since at
least the late 80s and it has been thrown into disarray by OS X!

_________________
=> Jolin

On 3/31/08 at 9:40 AM, tekelenbeuronet.nl (Sander Tekelenburg) wrote:

>At 04:12 -0700 UTC, on 2008-03-30, Dave Scocca wrote:
>
>>--On 3/25/08 4:59 AM -0700 Sander Tekelenburg wrote:
>
>[...]
>
>>> Right. I'm just saying that with UTIs creator codes are not necessary
>>> anymore. A UTI like "public.text.plain.ascii" could be bound to Alpha and
>>> "public.text.plain.iso-2022-jp" to JeditX.
>
>[...]
>
>>With a creator code, I can set downloads to be created by FireFox (since I
>>usually want to view them) and keep my own web page files created by BBEdit
>>(since I usually want to edit them).
>
>True, creator types help you there. But this sounds like an exceptional use
>case to me. How many people download HTML files in order to be able to
>double-click them to have the HTML be interpreted? There's no doubt in my
>mind that well over 99% of users will let their browser load such files
>directly -- what they call "clicking a link", "browsing".

I can't speak for everyone, but I certainly have hundreds, if
not thousands, of HTML files saved to disk for reading purposes.
(Not counting applications that store their help files as HTML.)

The key here is that HTML is currently one of the best, if not
*the* best, 'universal' formats for formatted text display. It's
readable in far more applications, across far more platforms,
than even specifically-designed compatibility formats like RTF.
I'd say it's far from the best in technical terms, but knowing
that I can take an HTML file and read it on anything that has a
web browser makes up for a lot. As a result, I tend to use it a
lot for storing reference information that needs more than just
plain ASCII formatting.

>I mean, no doubt you already need to override your browser's default
>behaviour anyway to get it to save text/html files to disk. That's just how
>it is with text/html: it's the most common file type that people want opened
>in different apps depending on the situation. I don't believe that translates
>to creator types being necessary in general.

I'll toss in an additional format: TIFF. For TIFF, take the
example of Photoshop and Painter: two applications that do very
different things with image files, both use TIFF, and saving in
TIFF is desirable because it is (at least last I heard) still
the best 'universal' non-lossy graphics format - supported by
the greatest number of programs. And while you want to save in
TIFF for compatibility, the difference in functionality between
the programs means you definitely want some to open
automatically in Photoshop and others in Painter.


Travis Butler
tbutlermac.com