ollef@sics.se (Olle Furberg) (11/29/90)
There has been some postings concerning FONT-resources in stacks: In <18615@unix.SRI.COM> mxmora@unix.SRI.COM (Matt Mora) writes: >Apple recommends that you don't include fonts in any documents. And since >a stack is just a document Apple recommends not putting them into a stack >either. In <37407@nigel.ee.udel.edu> johnston@oscar.ccm.udel.edu writes: >Does anyone have any thoughts on the _appropriateness_ of including >fonts with a stack? Not in the stack, that's taboo, apparently. But I can't understand this. I thought it was an accepted way to assure that the user has the resources he needs. In the Apple publication "Technical Introduction to the Macintosh Family" (ISBN 0-201-17765-X) on page 74 you could read: "The resource manager usually searches the files in the reverse order that they were opened..." [i.e. beginning with the document file] "Understanding of this search order makes it easy to share resources among applications and also to override a system resource with a custom resource." And in another Apple publication, "HyperCard Stack Design Guidelines" (ISBN 0-201-51784-1) on page 87: "If you need to use a nonstandard font for text fields, you should either install it into your stack itself, or include it as a separate font resource and instruct the users to install it into their System with the Font/DA Mover utility." If HC 2.0 can't deal with resources in the stack I'll think of it as a rather nasty bug. Besides FONT and FOND resources I also want to put KCHRs into my stacks, I hope this will be supported in future versions of HC.
jdevoto@Apple.COM (Jeanne A. E. DeVoto) (11/29/90)
In article <1990Nov28.180031.677@sics.se> ollef@sics.se (Olle Furberg) writes: >There has been some postings concerning FONT-resources in stacks: > In <18615@unix.SRI.COM> mxmora@unix.SRI.COM (Matt Mora) writes: > >Apple recommends that you don't include fonts in any documents. And since > >a stack is just a document Apple recommends not putting them into a stack > >either. > > In <37407@nigel.ee.udel.edu> johnston@oscar.ccm.udel.edu writes: > >Does anyone have any thoughts on the _appropriateness_ of including > >fonts with a stack? Not in the stack, that's taboo, apparently. > > But I can't understand this. I thought it was an accepted way to assure that >the user has the resources he needs. In the Apple publication "Technical >Introduction to the Macintosh Family" (ISBN 0-201-17765-X) on page 74 you >could read: > > "The resource manager usually searches the files in the reverse > order that they were opened..." > [i.e. beginning with the document file] > "Understanding of this search order makes it easy to share resources > among applications and also to override a system resource with > a custom resource." > >And in another Apple publication, "HyperCard Stack Design Guidelines" (ISBN >0-201-51784-1) on page 87: > "If you need to use a nonstandard font for text fields, you should > either install it into your stack itself, or include it as a separate > font resource and instruct the users to install it into their System > with the Font/DA Mover utility." > > If HC 2.0 can't deal with resources in the stack I'll think of it as a >rather nasty bug. Besides FONT and FOND resources I also want to put KCHRs >into my stacks, I hope this will be supported in future versions of HC. Well, this is kind of a complicated issue. Here's what I know about it, for whatever it's worth (with the added bonus of a brief Opinionated Rant): - Apple technical notes warn strongly against putting fonts anywhere except the system file. Fonts in applications may cause problems for Apple's print spooler, and fonts in documents are said to be a potential cause for heap corruption. (Note that this *only* applies to fonts, not other resource types such as icons.) - Many applications (for instance, terminal emulators) have fonts in the application. - Many stacks (including some distributed by Apple) include special-purpose fonts in their resource forks. - I have never heard of a problem arising from fonts in a stack. - However, there are rumors that System 7.0 will break some such stacks. - The "official line" from DTS is that you should distribute a suitcase and instructions to your users to install custom fonts into their System file. - Many users either don't know how to use Font/DA Mover or will be unwilling to go to the inconvenience of installing a font just to view your stack. - Some fonts that may be included in stacks are not appropriate for systemwide installation: for instance, I have a password font that consists of nothing but bullets, and I don't think most people will want it showing up in WriteNow. - Furthermore, since Apple's screen fonts for the standard LaserWriter faces (Times, Avant Garde, etc.) are different from the Adobe versions, and Apple does not distribute variants (italic, bold, etc), a stack may be designed with a version of a font other than the version already in the user's system. In this case, it's not a good idea to ask the user to replace the font with your version, since it will result in formatting changes to documents the user's made with that font. - When David Szetela (head of developer services) was a forum guest on CI$ a couple of months ago, this subject came up. Several HyperCard developers stated strongly that they wanted to be able to install fonts directly into their stacks without fear of compatibility problems coming up in the future. He listened to the comments and said he'd look into the technical issues involved. - As far as I can tell, HyperCard 2.0 behaves no differently with respect to fonts in a stack than 1.x did. My feeling is that if there is a bug in the Font Manager that causes heap corruption when fonts are found outside the System file then System Software should be chartered to take the time to fix that bug. If there are other technical issues around the installation of fonts in the resource chain, those issues should be resolved. It makes sense to install custom fonts in a stack; it localizes the fonts to the context in which they're used, it's transparent to the user, it doesn't require "deinstallation" of the font if the user gets rid of the stack. It makes a stack a simple self-contained module, instead of a cumbersome set of files requiring special installation procedures. It makes sense, it's in keeping with the way the resource chain is used, and if system software needs fixing in order to allow the trouble-free use of this Macintosh feature, it should be fixed. -- ========= jeanne a. e. devoto ======================================== jdevoto@apple.com | You may not distribute this article under a jdevoto@well.sf.ca.us | compilation copyright without my permission. ______________________________________________________________________ Apple Computer and I are not authorized | CI$: 72411,165 to speak for each other. |
ffdkl@acad3.fai.alaska.edu (LaSota Daniel K) (11/29/90)
Two other things to consider when moving fonts into stacks are copyrights and limited use. Copyrights: Just because you are technically able you aren't legally able to install any and every font any and everywhere. The other thing to think about is limited use. Let's say that I have installed the font "Slime" into a stack. Let's also suppose that I have installed the point sizes for 9 and 12. If a person who has Slime 9,12,14,18,20,... in their system he won't see sizes higher than 12. Use of the font in the stack inhibits use of the font in either the app or the system. So if you do install fonts make sure you install all of the necessary sizes. I have installed fonts into 2.0 stacks with no prob. I also have converted stacks that had fonts in them to 2.0 no prob. I also have run them with 7.0 no prob. What do the people at Apple DTS say? Ant Man! Dan LaSota ftdkl@acad3.fai.alaska.edu
ollef@sics.se (Olle Furberg) (11/29/90)
In <1990Nov29.010919.24666@hayes.ims.alaska.edu> ffdkl@acad3.fai.alaska.edu (LaSota Daniel K) writes: >Let's say that I have installed the font "Slime" into a stack. >Let's also suppose that I have installed the point sizes for >9 and 12. >If a person who has Slime 9,12,14,18,20,... in their system >he won't see sizes higher than 12. Use of the font in the stack Well, just change the name and id number of the font, then you will have no problems. If Slime has id=589 then take a copy of Slime, name it Slime2 and set id to 590.
lyons@gw.scri.fsu.edu ("Jim Lyons") (11/30/90)
In article <46927@apple.Apple.COM> jdevoto@Apple.COM (Jeanne A. E. DeVoto) writes: > In article <1990Nov28.180031.677@sics.se> ollef@sics.se (Olle Furberg) writes: > >There has been some postings concerning FONT-resources in stacks: > > In <18615@unix.SRI.COM> mxmora@unix.SRI.COM (Matt Mora) writes: > > >Apple recommends that you don't include fonts in any documents. And since > > >a stack is just a document Apple recommends not putting them into a stack > > >either. [Furberg quotes from Apple dox indicating it's ok to put fonts in stacks] Devoto continues: > My feeling is that if there is a bug in the Font Manager that causes > heap corruption when fonts are found outside the System file then System > Software should be chartered to take the time to fix that bug. If there > are other technical issues around the installation of fonts in the resource > chain, those issues should be resolved. It makes sense to install custom > fonts in a stack; it localizes the fonts to the context in which they're > used, it's transparent to the user, it doesn't require "deinstallation" > of the font if the user gets rid of the stack. It makes a stack a simple > self-contained module, instead of a cumbersome set of files requiring > special installation procedures. It makes sense, it's in keeping with the > way the resource chain is used, and if system software needs fixing in order > to allow the trouble-free use of this Macintosh feature, it should be fixed. Hear, hear! I can't believe there would be any other course considered by Apple on this situation. I have some stacks (ok, they're just games, but they are educational in nature) that use special purpose fonts; the fonts just contain a few characters and, without going into details, are the best way to implement the things I wanted to do in these stacks. But it would make absolutely no sense to put these in the System; they have no use whatsoever outside of these stacks. In addition to the reasons given by Jeanne, you don't want to clutter up every other application's fonts menu with useless entries. And if the user has different system disks the fonts would have to be installed in every one. If I want to show the stack on a friend's system, I have to first install the special fonts. I have always marveled at how handy this capability of HyperCard is, and haven't begun to exploit all the uses for it. Please fix it so we can put special fonts in stacks without breaking anything! Thank you. __________________Jim Lyons, innocent HyperHacker_______________ _____________________lyons@scri1.scri.fsu.edu___________________
steve@Advansoft.COM (Steve Savitzky) (11/30/90)
In article <1990Nov29.010919.24666@hayes.ims.alaska.edu> ffdkl@acad3.fai.alaska.edu (LaSota Daniel K) writes:
Two other things to consider when moving fonts into stacks are
copyrights and limited use.
Copyrights: Just because you are technically able you aren't legally
able to install any and every font any and everywhere.
Correct me if I'm wrong, but my impression from reading about recent
court decisions is that you can't copyright the appearance or bitmap
of a font. Adobe won the right to copyright its *scalable* fonts
because it was ruled that they were *programs*; presumably a different
program that happened to result in the same bitmaps would not be an
infringement of Adobe's copyright.
There may concievably be licensing restrictions on some fonts, but
that's a different matter, and might be hard to enforce. In any case,
I believe that Adobe's screen fonts are free; they *want* to spread
them around so as to make people want the scalable versions.
disclaimer:
I'm not a lawyer. Your mileage may differ.
--
\ --Steve Savitzky-- \ ADVANsoft Research Corp \ REAL hackers use an AXE! \
\ steve@advansoft.COM \ 4301 Great America Pkwy \ #include<disclaimer.h> \
\ arc!steve@apple.COM \ Santa Clara, CA 95954 \ 408-727-3357 \
\__ steve@arc.UUCP _________________________________________________________jkc@Apple.COM (John Kevin Calhoun) (12/01/90)
Here are a couple of the reasons for Apple's recommendation that fonts belong only in the System file. The Font Manager caches information about the font that's currently in use, including a reference to the block of memory where the font currently lives. If the resource file that contains the font resource is closed, the font is purged from memory. But the Font Manager may still use the cached information -- it doesn't expect the font to disappear and its cached information to become suddenly invalid. HyperCard works around this problem by invalidating the Font Manager's cached information when it closes resource files. The Font Manager expects all fonts of a font family to live in the same resource file. Therefore, if the user has installed the font "Hopatcong" in the system file in sizes of 9,10,12,18, and 24 points and you install the font "Hopatcong" in a stack in just the 9-point size, then when the user opens your stack, the Font Manager won't be able to find Hopatcong 10, 12, 18, or 24 anymore! The user will think this is bad. That's about all I know about this issue. Kevin Calhoun HyperCard Team Apple Computer, Inc. Disclaimer: I could be wrong. And if I am, it's my fault. Mine mine mine.
essam@gagme.chi.il.us (Essam Khairullah) (12/01/90)
In article <1990Nov28.180031.677@sics.se> ollef@sics.se (Olle Furberg) writes: > >There has been some postings concerning FONT-resources in stacks: > .... > In <37407@nigel.ee.udel.edu> johnston@oscar.ccm.udel.edu writes: > >Does anyone have any thoughts on the _appropriateness_ of including > >fonts with a stack? Not in the stack, that's taboo, apparently. > > .... >And in another Apple publication, "HyperCard Stack Design Guidelines" (ISBN >0-201-51784-1) on page 87: > > "If you need to use a nonstandard font for text fields, you should > either install it into your stack itself, or include it as a separate > font resource and instruct the users to install it into their System > with the Font/DA Mover utility." > > > If HC 2.0 can't deal with resources in the stack I'll think of it as a >rather nasty bug. Besides FONT and FOND resources I also want to put KCHRs >into my stacks, I hope this will be supported in future versions of HC. HC 2.0 CAN indeed deal with resources in the stack. You are certainly free to include (and in fact encouraged) to include resources in your stacks (ever try to use a XCMD/XFCN that wasn't a resource?). The problem with fonts is the ever popular......Font conflicts I have developed a commercial stack that I included a special font that was needed in the stack. The problem comes when you print on a LaserWriter or other postscript printer. Since the font is not in the System file, (or in a suitcase file used by Suitcase or Juggler) you may encounter problems when the stack is printed. My included font ended up on the LaserWriter as Times. The best solution for including fonts with stacks is by including the font as a suitcase file and instructing the user to install it in the System file. If he/she has Suitcase/Juggler then he/she must be able to figure out how to avoid font id conflicts. Just my $0.02 worth. -- Essam Khairullah essam@gagme.chi.il.us I don't got no fancy signature.
bc@Apple.COM (bill coderre) (12/03/90)
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
mxmora@unix.SRI.COM (Matt Mora) (12/04/90)
In article <47015@apple.Apple.COM> bc@Apple.COM (bill coderre) writes: >This is from Technical Note 245, August 89 version: [Stuff deleted] >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. The Tech note says its OK for an application to have Font's in its resource fork, its the documents (stacks) that they have problems with. Its just another example of hypercard breaking the rules just to suit itself. :-) (notice the smiley. Boy would I get flamed if I left that out) Maybe now that Claris has the ball, they will play by the rules. (when hypercard first came out, who was going to tell Bill "Gee, what a great program but I think we can't release it because it breaks too many Human interface Guidelines".) I think 2.0 is much better now at keeping the faith. Good work Guy/Gals! -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@sri.com SRI International | my unix mxmora@unix.sri.com ___________________________________________________________