Path: 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 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_