[comp.sys.mac] Installing Fonts & DA's in applications

mikem@gaudi (Mike Mize) (03/06/90)

I just found out the other day that you can install fonts and DAs in
applications.  I tried this and was successfull but could not help but
wonder what it would buy me.  Does anyone know of any advantage to this?

Michael  Mize -- mikem@gaudi.csufresno.edu

nebel@wam.umd.edu (Chris D. Nebel) (03/07/90)

In article <9003060003.AA08520@gaudi> mikem@gaudi (Mike Mize) writes:
>I just found out the other day that you can install fonts and DAs in
>applications.  I tried this and was successfull but could not help but
>wonder what it would buy me.  Does anyone know of any advantage to this?

Doing this gives you a font or DA that will only be availible to the
program you put it in.  So if you had some wierd, special purpose DA
that you only used in a particular program and you didn't want to use
up a DA slot, you could install it in the program instead of the
System.  With things like Suitcase around, this case doesn't come up
very much.

Installing fonts in applications can be extremely useful if you're a
programmer.  Say for some reason you need a special font, but putting
in the System (or, worse yet, making the user install it) would be
ugly.  So, you put in right in your application, and it's there when
you need it.  No muss, no fuss, no bother.

Also, you can put fonts and DAs in _any_ file, not just applications.
This leads to an interesting trick: if you put a font in a Hypercard
stack, that stack will be able to use the font, whether or not the
font is in the System.  I believe that Apple says this is Not A Good
Thing To Do, but it's worked just fine for me.


Chris Nebel
nebel@wam.umd.edu 

mjohnson@Apple.COM (Mark B. Johnson) (03/07/90)

In article <1990Mar6.165630.29382@wam.umd.edu> nebel@wam.umd.edu (Chris D. Nebel) writes:
>In article <9003060003.AA08520@gaudi> mikem@gaudi (Mike Mize) writes:
>>I just found out the other day that you can install fonts and DAs in
>>applications.  I tried this and was successfull but could not help but
>>wonder what it would buy me.  Does anyone know of any advantage to this?
>

Don't do it...don't do it...don't do it.  If you need a font, ship a Suitcase
file and ask the user to install it in their System file.  Especially don't
do it with documents and HyperCard stacks.


-- 
Mark B. Johnson                                            AppleLink: mjohnson
Developer Technical Support                         domain: mjohnson@Apple.com
Apple Computer, Inc.         UUCP:  {amdahl,decwrl,sun,unisoft}!apple!mjohnson

"You gave your life to become the person you are right now.  Was it worth it?"
                                                         - Richard Bach, _One_

brian@cs.utah.edu (Brian Sturgill) (03/07/90)

> From: mjohnson@Apple.COM (Mark B. Johnson)
> 
> In article <1990Mar6.165630.29382@wam.umd.edu> nebel@wam.umd.edu (Chris D. Nebel) writes:
> >In article <9003060003.AA08520@gaudi> mikem@gaudi (Mike Mize) writes:
> >>I just found out the other day that you can install fonts and DAs in
> >>applications.  I tried this and was successfull but could not help but
> >>wonder what it would buy me.  Does anyone know of any advantage to this?
> >
> 
> Don't do it...don't do it...don't do it.  If you need a font, ship a Suitcase
> file and ask the user to install it in their System file.  Especially don't
> do it with documents and HyperCard stacks.
> 

Why oh why, when Apple does not want you to do something, they tell
you not to do it, but never why you should not do it?
This is especially annoying when they tell you not to do something
they have in the past said you can do...

Quote from IM I (10th printing), p. 104:

	Resource files aren't limited to applications; anything stored in a
	a file can have its own resources.  For instance, an unusual font
	used in only oe document can be included in the resource file for that
	document rather than in the system resource file.

It sounds like a good scheme to me (provided you think resources
are a good idea to begin with), why did it change?
If it hasn't changed, why is a hypercard stack different?

Brian
-----------------
Brian Sturgill
brian@cs.utah.edu

geoff@pmafire.UUCP (Geoff Allen) (03/07/90)

mikem@gaudi (Mike Mize) writes:
>
>I just found out the other day that you can install fonts and DAs in
>applications.  I tried this and was successfull but could not help but
>wonder what it would buy me.  Does anyone know of any advantage to this?

(For those not familiar with the technique, hold down option while
clicking the ``Open'' button in Font/DA Mover.)

With DAs, at least, this can be a handy way to get around the system
limit of 15 DAs.  (And it's a bit cheaper than Suitcase, Font/DA
Juggler, et. al.). 

If you have a DA that is specific to a particular application (like the
version of Word Finder distributed with MS Word) you can free up one of
your precious 15 slots by putting it in the application, rather than the
System.

Another example is the ``MAUG Forums DA'' which lists all the areas in
MAUG on CompuServe (so you can figure out where you want to go while the
meter isn't ticking).  Since it's communications-related, why not put it
in your communications program? Voila! Another DA slot becomes
available. 

-- 
Geoff Allen         \  Computers are useless.  
uunet!pmafire!geoff  \  They can only give you answers.
bigtex!pmafire!geoff  \		-- Pablo Picasso

dave@PRC.Unisys.COM (David Lee Matuszek) (03/07/90)

In article <39241@apple.Apple.COM> mjohnson@Apple.COM (Mark B. Johnson) writes:
>In article <1990Mar6.165630.29382@wam.umd.edu> nebel@wam.umd.edu (Chris D. Nebel) writes:
>>In article <9003060003.AA08520@gaudi> mikem@gaudi (Mike Mize) writes:
>>>I just found out the other day that you can install fonts and DAs in
>>>applications.  I tried this and was successfull but could not help but
>>>wonder what it would buy me.  Does anyone know of any advantage to this?
>>
>
>Don't do it...don't do it...don't do it.  If you need a font, ship a Suitcase
>file and ask the user to install it in their System file.  Especially don't
>do it with documents and HyperCard stacks.
>
>
>-- 
>Mark B. Johnson                                            AppleLink: mjohnson
>Developer Technical Support                         domain: mjohnson@Apple.com
>Apple Computer, Inc.         UUCP:  {amdahl,decwrl,sun,unisoft}!apple!mjohnson
>
>"You gave your life to become the person you are right now.  Was it worth it?"
>                                                         - Richard Bach, _One_


My understanding, bolstered by things I have read in Inside Mac and
elsewhere, is that adding fonts and DAs to an application is a GOOD
THING.  That resources were designed with exactly this in mind.  That
adding fonts to documents was specifically recommended.

If it were not for your .signature I would assume you didn't know what
you were talking about.  However, that particular .signature strongly
implies that you do (or at least should) know what you're talking
about.  Accordingly, I think you owe us an explanation, not just an
exhortation.

-----

News flash, May 1990:  "Don't make menu selections," says Apple Tech
Support.  "Menus are only there to help you find the command keys."

-- Dave Matuszek (dave@prc.unisys.com)
-- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA  19301
-- Any resemblance between my opinions and those of my employer is improbable.
  << Those who fail to learn from Unix are doomed to repeat it. >>

rotberg@dms.UUCP (Ed Rotberg) (03/08/90)

From article <39241@apple.Apple.COM>, by mjohnson@Apple.COM (Mark B. Johnson):
>>>I just found out the other day that you can install fonts and DAs in
>>>applications.  
> 
> Don't do it...don't do it...don't do it.  If you need a font, ship a Suitcase
> file and ask the user to install it in their System file.  

Mark,

Why should I not have a custom font in my application.  I have already done
this in my commercial brdige hand dealing program (the font supports special
bridge symbols) and it works just fine.  The only problem that I have
encountered with a custom font is that if I try to use PREVIEW to examine
my printed output onscreen, it doesn't seem to want to use the application
specific font.  It works just fine to every "real" printer I've tried it
with though.  Please be specific as to why I shouldn't do this (or why I
should force my users, many of whom are NOT computer savvy, to install a font
that will be worthless for anything but my program).

	- Ed Rotberg -

mjohnson@Apple.COM (Mark B. Johnson) (03/08/90)

In article <1990Mar6.112240.1783@hellgate.utah.edu> brian@cs.utah.edu (Brian Sturgill) writes:
>
>Why oh why, when Apple does not want you to do something, they tell
>you not to do it, but never why you should not do it?
>This is especially annoying when they tell you not to do something
>they have in the past said you can do...
>
>Quote from IM I (10th printing), p. 104:
>
>	Resource files aren't limited to applications; anything stored in a
>	a file can have its own resources.  For instance, an unusual font
>	used in only oe document can be included in the resource file for that
>	document rather than in the system resource file.
>
>It sounds like a good scheme to me (provided you think resources
>are a good idea to begin with), why did it change?
>If it hasn't changed, why is a hypercard stack different?
>

Do you always believe everything Inside Macintosh says, especially a volume
which was written and has not been revised since 1984?  Times have changed
as systems have changed.  We've documented the reasons for this in Technical
Notes for some time now.

To quote from Technical Note #192:

Fonts In An Application?

There are two problems when printing application fonts with the LaserWriter
driver.  Application fonts are fonts that are stored in the resource fork of
the application's resource file rather than being stored in the System file.
The first problem occurs when the application font has the same name as the
application's resource file.  If this is the true, the LaserWriter driver
incorrectly assumes that the application's resource file is a font file, and
closes it after using the font.  To solve this problem, developers should make
sure the name of the application font (i.e., the 'FOND' resource) is different
from the name of the application's resource file.  Since the application can
still be renamed by the user, developers should try to select a unique font
name.  If the font name does not appear in a font menu, developers can simply
append the application's creator string onto the desired font name (i.e.,
'MyApplicationFont ZZAP').

The second problem with application fonts only occurs when background printing
is enabled.  When a print job is performed in the background, the LaserWriter
driver writes all of the data to be printed into a file (called a spool file)
for printing at a later time by Print Monitor.  Since the LaserWriter driver
has no way of knowing when the file will actually be printed, it cannot assume
that the application will still be open when the job is printed.  This is a
problem if the application contains application fonts that Print Monitor needs
at print time.  To solve this problem, the LaserWriter driver must determine
whether the fonts needed by the application are resident in the System file or
in the application file.  If they are in the application file, the driver must
copy them into the spool file so they are available to Print Monitor.  This
practice can lead to very large spool files, as well as a significant loss of
performance when background printing is enabled.  To solve these and other user
interface problems related to application fonts, Apple strongly recommends that
developers ship custom application fonts as suitcase files for the user to
install in the System file.

And more from Technical Note #245

How Does This Affect You?

This Note describes how font family IDs are distributed.  Developers who use a
font as a method of storing symbols which are used in a palette or store a font
in the resource fork of their application for some other special purpose,
should use numbers in the range 32,256-32,767.  Fonts designed specifically to
be stored in an application's resource fork should not be registered.  There
are very few good reasons for storing fonts in an application's resource fork,
as it can create serious problems for a user who tries to print a document that
uses that font when background printing is on.  Fonts should never be stored in
a document's resource fork.  Storing fonts in a document's resource fork is a
known cause of heap corruption.  Note that HyperCard stacks are documents.  If
you feel that your stack looses all its artistic merit without a certain font,
you should license it for distribution in a suitcase file and let the users
install it in their systems.


So you seek, we do explain why not to do it and the world has changed since
1984.  When you read Inside Macintosh (until the day it can be updated), please
check Technical Notes to see if the advice given in 1984 is still valid in
1990.

-- 
Mark B. Johnson                                            AppleLink: mjohnson
Developer Technical Support                         domain: mjohnson@Apple.com
Apple Computer, Inc.         UUCP:  {amdahl,decwrl,sun,unisoft}!apple!mjohnson

"You gave your life to become the person you are right now.  Was it worth it?"
                                                         - Richard Bach, _One_

brian@cs.utah.edu (Brian Sturgill) (03/08/90)

> From mjohnson@Apple.COM Wed Mar  7 10:08:19 1990
> ...
> In article <1990Mar6.112240.1783@hellgate.utah.edu> brian@cs.utah.edu (Brian Sturgill) writes:
> >
> >Why oh why, when Apple does not want you to do something, they tell
> >you not to do it, but never why you should not do it?
> >This is especially annoying when they tell you not to do something
> >they have in the past said you can do...
> >
> >Quote from IM I (10th printing), p. 104:
> >
> >	Resource files aren't limited to applications; anything stored in a
> >	a file can have its own resources.  For instance, an unusual font
> >	used in only oe document can be included in the resource file for that
> >	document rather than in the system resource file.
> >
> >It sounds like a good scheme to me (provided you think resources
> >are a good idea to begin with), why did it change?
> >If it hasn't changed, why is a hypercard stack different?
> >
> 
> Do you always believe everything Inside Macintosh says, especially a volume
> which was written and has not been revised since 1984?  Times have changed
> as systems have changed.  We've documented the reasons for this in Technical
> Notes for some time now.
...(References to Tech notes explaining why)
> So you seek, we do explain why not to do it and the world has changed since
> 1984.  When you read Inside Macintosh (until the day it can be updated), please
> check Technical Notes to see if the advice given in 1984 is still valid in
> 1990.

It is true as you say that the Tech Notes explain this problem (and
thanks for the references).  But I think you missed the point of my
message; Apple frequently says things IN THIS NEWSGROUP like "Don't do
X".  What I (and others responding to the original message) want is
Apple responses to say "Don't do X, because ...".  "Don't do X, for
details see TN###,TN###" would be fine too.

Now to your note:  In summary of the TN's,  I believe the reason one
should not put Fonts in ones applications is that Apple goofed the MAC
to LaserWriter ROM code, and so printing does not necessarily work with
fonts in an application/document resource fork?  I find this odd,
couldn't the System file just contain patches?  Seems odd to give up
the flexibility.  And certainly despite what the TN says there are many
good reasons to want NOT to have the fonts installed.  The recent
posting about the bridge font is a very good example.

Also, I did not (and you can check my letter saved above) say I believe
everything in Inside Mac.  Times have indeed changed, and I believe
Apple should have realized that things change long ago, and kept IM up
to date.  Tech notes are nice as a temporary measure, but who has time
to read 200+ of them?  Further why should I?  I cannot think of another
vendor that tells its customers that in order to look information up
about its product, one should consult the manual of 6 years ago (which
is in reality one 3 manual set, with 2 large patch sets), and then
supplement that information by looking through 200+ large "patches".
If my Sun Tech Rep told me I would have to do that I'd fall in the
floor laughing -- then switch vendors*.  Alas, with Apple, this is not a
funny, fictional situation.

*(No offense intended to Sun here.
	Sun does an excellent job keeping their documentation up to date.)

Brian
-------------
Brian Sturgill
brian@cs.utah.edu

isle@eleazar.dartmouth.edu (Ken Hancock) (03/09/90)

In article <1001@dms.UUCP> rotberg@dms.UUCP (Ed Rotberg) writes:
>Mark,
>
>Why should I not have a custom font in my application.  I have already done
>this in my commercial brdige hand dealing program (the font supports special
>bridge symbols) and it works just fine.  The only problem that I have
>encountered with a custom font is that if I try to use PREVIEW to examine
>my printed output onscreen, it doesn't seem to want to use the application
>specific font.  It works just fine to every "real" printer I've tried it
>with though.  Please be specific as to why I shouldn't do this (or why I
>should force my users, many of whom are NOT computer savvy, to install a font
>that will be worthless for anything but my program).
>
>	- Ed Rotberg -

First of all, this should really be in comp.sys.mac programmer.  I'm
putting follow-ups there.

Inside Macintosh should be used as a starting point and not the
be-all and end-all of programming the Macintosh.  Many of the
points or recommendations which were originally stated in IM
may have been changed for various reasons:

1) The certain method no longer works with the current software.
2) The folks at Apple aren't omnicient and found that they had
   boo-boo'ed and that it's a bad idea (Fonts in Applications
   is an example)
3) There's a better way...

Unfortunately, technotes aren't as widely available as they should
be.  (Actually, IM should be updated, incorporating Technote changes...)

Ken




--
Ken Hancock '90            | DISCLAIMER: I'm graduating and looking for
Consultant                 |             a job, so I'll stand by my words.
Computer Resource Center   |==============================================
Dartmouth College          | EMAIL: isle@eleazar.dartmouth.edu

leipold@eplrx7.uucp (Walt Leipold) (03/09/90)

In article <39273@apple.Apple.COM> mjohnson@Apple.COM (Mark B. Johnson) writes:
>Do you always believe everything Inside Macintosh says, especially a volume
>which was written and has not been revised since 1984?  Times have changed
>as systems have changed.  We've documented the reasons for this in Technical
>Notes for some time now.
>
> [deleted descriptions of why not to store fonts in applications
> or documents...the gist of the discussion is that some recent system
> 'enhancements' have made this kind of flexibility impossible...]

As hard as Apple's been pushing the object-oriented applecart (if you
like mixed metaphors), it's really sad to see them copping out on
something like this.  "Don't you _dare_ put fonts in application or
document files!"  Right.  The orthogonality of resources was one of the
beauties of the original Mac system; you could put any resource
anywhere, and it would get used at the appropriate time.  And the user
didn't even have to _know_ about it; the machine just did it right.
This was one of the concepts that actually made programming the Mac
easier.

Orthogonality and flexibility were Good Things back when the elegance
of the Mac meant something, but now Apple sells enough of 'em that they
don't have to bust a gut to keep things elegant and simple.  And even
though Apple pays lip-service to an object-oriented philosophy, with
its emphasis on encapsulation, you'd better not try that encapsulation
with your bridge or chess application.  No, it's too much trouble for
Apple to keep things simple, and elegant, and orthogonal.  They're too
busy with their lawsuits over Look & Feel.

(And of course, limiting private fonts means that you can't carry
an application which needs these fonts around on a floppy unless
it's a system disk, so the poor schmuck of a user has to either
run the Installer every time he makes a copy of his program or has
to run Font/DA Mover every time he moves his floppy to a different
machine.  Great.  Thanks for looking out for the little guy.)

[Flame off]

Sorry, it's been a bad day.  

>-- 
>Mark B. Johnson                                            AppleLink: mjohnson
>Developer Technical Support                         domain: mjohnson@Apple.com
>Apple Computer, Inc.         UUCP:  {amdahl,decwrl,sun,unisoft}!apple!mjohnson
>
>"You gave your life to become the person you are right now.  Was it worth it?"


-- 
"As long as you've lit one candle,                         Walt Leipold
you're allowed to curse the darkness."       (leipolw%esvax@dupont.com)
--
--
The UUCP Mailer

dplatt@coherent.com (Dave Platt) (03/09/90)

In article <20157@dartvax.Dartmouth.EDU> isle@eleazar.dartmouth.edu (Ken Hancock) writes:

> Unfortunately, technotes aren't as widely available as they should
> be.  (Actually, IM should be updated, incorporating Technote changes...)

This process is already underway.  The good folks in Apple's tech-docs
group are converting Inside Mac into a humongous HyperCard stack, with
the chapters re-ordered (Color QuickDraw follows QuickDraw, for
example), obsolete information removed (or flagged as "Don't do this any
more, it's a bad idea"), a large electronic index added, and about ten
zillion cross-references to the Tech Notes stack.  The resulting
collection of data is somewhat larger than 10 megabytes... and it's VERY
useful.

An early edition of "SpInside Mac" is available on The Release Version
of Phil & Dave's Excellent CD [Which Is Only Available to Partners
Associates and Certified Developers and Cannot be Purchased by Others
for Any Amount of Money].  APDA says that they'll be distributing the
"real" SpInside Mac once the bugs are out of it.

-- 
Dave Platt                                             VOICE: (415) 493-8805
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: dplatt@coherent.com
  INTERNET:       coherent!dplatt@ames.arpa,  ...@uunet.uu.net 
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303

mjohnson@Apple.COM (Mark B. Johnson) (03/09/90)

In article <49028@coherent.coherent.com> dplatt@coherent.com (Dave Platt) writes:
>
>This process is already underway.  The good folks in Apple's tech-docs
>group are converting Inside Mac into a humongous HyperCard stack, with
>the chapters re-ordered (Color QuickDraw follows QuickDraw, for
>example), obsolete information removed (or flagged as "Don't do this any
>more, it's a bad idea"), a large electronic index added, and about ten
>zillion cross-references to the Tech Notes stack.  The resulting
>collection of data is somewhat larger than 10 megabytes... and it's VERY
>useful.

Just want to clarify that this version, SpInside Macintosh, was done by a
team of people from DTS with cooperation from Developer Technical Pubs, not
tech-docs group.  From this basis, the Developer Technical Publications
group is working on a much improved version which should see the light of
day later this year.  New features include references to the MPW interface
files, a cleaner interface, and some large speed gains.  Until that time,
SpInside Macintosh 1.0 and maybe some minor revisions are available.

>
>An early edition of "SpInside Mac" is available on The Release Version
>of Phil & Dave's Excellent CD [Which Is Only Available to Partners
>Associates and Certified Developers and Cannot be Purchased by Others
>for Any Amount of Money].  APDA says that they'll be distributing the
>"real" SpInside Mac once the bugs are out of it.
>
If you are not a Partner or Associate, you will soon be able to get
SpInside Macintosh and a few other goodies in a manner and for a price
(neither of which can be discussed at this time) I am sure you will
find worth the wait.  Until that time, please trust that we are doing
everything possible to put this out as fast as we can and the most
efficient way possible for your budget.

-- 
Mark B. Johnson                                            AppleLink: mjohnson
Developer Technical Support                         domain: mjohnson@Apple.com
Apple Computer, Inc.         UUCP:  {amdahl,decwrl,sun,unisoft}!apple!mjohnson

"You gave your life to become the person you are right now.  Was it worth it?"
                                                         - Richard Bach, _One_

lsr@Apple.COM (Larry Rosenstein) (03/10/90)

In article <1990Mar8.202458.22809@eplrx7.uucp> leipold@eplrx7.uucp (Walt 
Leipold) writes:

> As hard as Apple's been pushing the object-oriented applecart (if you
> like mixed metaphors), it's really sad to see them copping out on
> something like this.  "Don't you _dare_ put fonts in application or
> document files!"  

Object-oriented programming has nothing to do with the ability to put 
fonts in applications.  One is a high-level design strategy, and the other 
is a low-level technical detail.

Other people have already noticed that certain print drivers (e.g., Glue) 
won't work properly when the fonts are stored in applications.  That's a 
consequence of the fact that if fonts come from applications then the 
application resource file has to be opened to access the font.  (I would
venture that Glue has never worked properly with fonts stored in 
applications.)

Apple went to some lengths to ensure that this works with background 
LaserWriter printing, but the solution is not ideal.  Glue would have to 
do the same thing (ie, copy the application fonts to its output file.)

From reading the relevant Tech Note (192) it appears that if the 
application font isn't used for printing, then there's no problem.  

Also, note that putting fonts in documents, has rarely worked.  (Old 
timers might recall discussions about putting fonts in MacWrite documents.) 
That's because most applications either don't use the resource fork of 
documents, don't keep it open, or build a list of available fonts when the 
appliation starts up.

> beauties of the original Mac system; you could put any resource
> anywhere, and it would get used at the appropriate time.  And the user
> didn't even have to _know_ about it; the machine just did it right.

This is an overgeneralization.  The Resource Manager does look up 
resources, but it doesn't magically find them where ever they may live.  
In the case of printing, the Resource Manager can't find fonts stored in 
applications, unless that application resource file is opened or the fonts 
are somehow copied to the spool file (or Glue picture).

> Orthogonality and flexibility were Good Things back when the elegance
> of the Mac meant something, but now Apple sells enough of 'em that they
> don't have to bust a gut to keep things elegant and simple.  

Well, if we take out background printing, then things will be simple 
again.  The Glue printer driver still won't work, however.

In general, the system software people have busted many guts trying to 
maintain backward compatibility, while moving the system software forward.  
Fonts in applications do work with background printing, although the Tech 
Note points out the disadvantages.  (Take a look at Tech Note 268 to see 
what the sound people did to accommodate application.)

Things would be much easier if we didn't try to add all those new features 
(like background printing), but I doubt that users would prefer that 
alternative.  

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1

vanover@bcsaic.UUCP (Jann VanOver) (03/16/90)

Hey, guys, how about a non-technical answer to this question.

Do you have the RIGHT to distribute the fonts in question?  
                ^^^^^
If you built them yourself, then it is a pure-technical issue.  
       -------------------          ^^
If they've been acquired, they are not yours to give away.  
                --------           ^^^ ^^^^^ ^^ ^^^^ ^^^^
Make sure you've negotiated a distribution agreement with the author 
before thinking about breaking Apple's tech. rules.

Jann
vanover@atc.boeing.com

edwin_l_king@dinghy.cis.ohio-state.edu (03/23/90)

In article <39241@apple.Apple.COM> mjohnson@Apple.COM (Mark B. Johnson) writes:
>In article <1990Mar6.165630.29382@wam.umd.edu> nebel@wam.umd.edu (Chris D. Nebel) writes:
>>In article <9003060003.AA08520@gaudi> mikem@gaudi (Mike Mize) writes:
>>>I just found out the other day that you can install fonts and DAs in
>>>applications.  I tried this and was successfull but could not help but
>>>wonder what it would buy me.  Does anyone know of any advantage to this?
>>
>
>Don't do it...don't do it...don't do it.  If you need a font, ship a Suitcase
>file and ask the user to install it in their System file.  Especially don't
>do it with documents and HyperCard stacks.
>
>
 
  OK, Mark, I'll bite. Why not? I'm tired of
  "Don't do it!" 
  "Why not?"
  "Cause Apple said so."
  What will happen? Will the Non-Compatibility Fairy come down and do
a Rambo on my hard disk?
  Just curious.

  elk

psych@watserv1.waterloo.edu (R.Crispin - Psychology) (03/23/90)

I have installed fonts in many applications, files and stacks without a problem. I do it
if a special font is needed that I normally don't use. It saves me having a cluttered
system. It does not work with all files since some applications don't recognize fonts
in a 'data' file.
 
Richard Crispin
Department of Psychology
University of Waterloo
Waterloo, Ont.   N2L 3G1
(519)885-1211 ext. 2879