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