Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!apple!bc From: bc@Apple.COM (bill coderre) Newsgroups: comp.sys.mac.hypercard Subject: Re: FONTs in stack: what's bad? Message-ID: <47015@apple.Apple.COM> Date: 2 Dec 90 17:38:40 GMT References: <46927@apple.Apple.COM> <1990Nov29.010919.24666@hayes.ims.alaska.edu> Organization: Apple Computer Inc., Cupertino, CA Lines: 89 Whew! I seem to have opened a whole big can of worms here! Let me try and straighten some of this out. First of all, it is not Hypercard that allows the use of fonts in its stacks. It is the Mac Toolbox, specifically the Resource Manager. In fact, were it not for some (ominous twin peaks music) CONFLICT PROBLEMS, you would be able to put pretty much any custom resource you needed wherever it best fit. Obviously, the "best" place to put a custom font that only one stack uses is in that stack. The Resource Manager will open and close the font with the stack, not requiring it to show up in your MacWord font menu for the rest of your anguished existence. But there are (more music) PROBLEMS with this pragma. Specifically, the problems arise from the fact that although the Resource Manager maintains separate resource pools for each open resource file (which would, in this case, involve a chain of pools from document to (any stacks that had been "start using"'d) to Hypercard to the System File, the Font Manager uses a single pool of its internal information. This is from Technical Note 245, August 89 version: "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 loses 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." Well, that's their opinion. As best I can tell, MacPaint, MacDraw, PixelPaint, and Hypercard all have font information in their resource forks. And, apparently, Hypercard tries to facilitate this practice by forcing the Font Manager to rebuild its internal info. Because no reason is given for the threatened "heap corruption", I cannot be sure if there is some problem with using fonts other than the Font Manager not finding what it's looking for. That will only happen if your font has the same name or ID number as some other font. Additionally, if your font has the same name as another, users will not be able to access the other version. It will be "shadowed." This also may cause problems. Since I cannot speak for the Hypercard team or DTS, I cannot offer any "official guidelines" for what works and what doesn't, but here's my personal take on the situation, guaranteed worth price paid: 1 If possible, avoid using fonts in stacks. 2 Make sure your font has a unique name and ID number. (You must make sure to understand what this means, by reading the technotes and perhaps even talking with DTS, BEFORE distributing a stack commercially. Good luck to you if you want to distribute your stack in foreign countries. You should find out about the Script Manager's constraints, as well.) (If your stack is "don't care if it crashes", make up a name with some unusual characters, use a commercial font editor to create it, and install it into your stack with the Font/DA Mover. (Hold down OPT-SHIFT while selecting Open...) The Mover will fix some of the problems for you, but don't expect miracles.) 3 Don't print your special font. That means, don't print cards on which it appears, too. Check to make sure that it isn't lurking, invisibly, as the text style of an empty field waiting to crash your stack. 4 Expect problems. Personally, I do recall Hypercard training materials saying that using fonts for animation was a great idea, and I have personally used fonts for dimming buttons in several stacks, even printed the cards in the background, without any discernable problems. I guess I've FLAUNTED DEATH without even knowing it. bill coderre now an apple employee but not an official spokesperson