Article View: comp.sys.mac
Article #47530Re: Installing Fonts & DA's in applications
From: Mark B. Johnson
Date: Wed, 07 Mar 1990 17:08
Date: Wed, 07 Mar 1990 17:08
90 lines
5452 bytes
5452 bytes
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_
Technical Details
Message-ID:
<39273@apple.Apple.COM>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!mjohnsonReferences:
<39241@apple.Apple.COM> <1990Mar6.112240.1783@hellgate.utah.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!mjohnson From: mjohnson@Apple.COM (Mark B. Johnson) Newsgroups: comp.sys.mac Subject: Re: Installing Fonts & DA's in applications Message-ID: <39273@apple.Apple.COM> Date: 7 Mar 90 17:08:19 GMT References: <39241@apple.Apple.COM> <1990Mar6.112240.1783@hellgate.utah.edu> Organization: Apple Computer Inc, Cupertino, CA Lines: 90