steve@violet.berkeley.edu (Steve Goldfield) (05/17/89)
I used Suitcase II to add lots of additional fonts. I have a MacDraw (old version) file which uses Chicago and Times. When I launched it with the additional fonts, I noticed that the fonts in the document changed; for instance the font menu said I was using Camelot. I also had trouble trying to change the fonts; with the very long list of fonts, the font size overprinted the list and Chicago wasn't visible. When I removed the suitcase with the additional fonts, the fonts returned to their original values. I know that the author of Suitcase II reads this group. Perhaps he or someone else can explain what was going on (it appeared that the font numbers were changed ?) and what to do to fix it. Steve Goldfield
gaynor@armadillo.cis.ohio-state.edu (Vampire) (05/17/89)
In article <24495@agate.BERKELEY.EDU> steve@violet.berkeley.edu (Steve Goldfield) writes: >When I launched it (old MacDraw) with the additional fonts, I noticed that >the fonts in the document changed; for instance the font menu said I was >using Camelot. I also had trouble trying to change the fonts; with the very >long list of fonts, the font size overprinted the list and >Chicago wasn't visible. I have noticed similar problems with "old" MacDraw (pre MacDraw II), but not just with Suitcase - it happens on any setup with a large number of fonts. For one reasons or another, MacDraw wasn't able to handle large font lists. Made for lots of problems when I took MD files made on a floppy system to be laser-printed on a Mac w/ a HD and gobs of fonts. -=- | Jim Gaynor..."The Vampire Lestat" UseNet: gaynor@cis.ohio-state.edu | | The Ohio State University - Dept. of Philosophy, Dept. of Computer Science | >> "It is useless for sheep to pass resolutions in favor of vegetarianism << >> while wolves remain of a different opinion." - William Ralph Inge <<
drc@claris.com (Dennis Cohen) (05/17/89)
In article <48702@tut.cis.ohio-state.edu> Vampire <gaynor@cis.ohio-state.edu> writes: >In article <24495@agate.BERKELEY.EDU> steve@violet.berkeley.edu (Steve Goldfield) writes: >>When I launched it (old MacDraw) with the additional fonts, I noticed that >>the fonts in the document changed; for instance the font menu said I was >>using Camelot. I also had trouble trying to change the fonts; with the very >>long list of fonts, the font size overprinted the list and >>Chicago wasn't visible. > > I have noticed similar problems with "old" MacDraw (pre MacDraw II), >but not just with Suitcase - it happens on any setup with a large number of >fonts. For one reasons or another, MacDraw wasn't able to handle large >font lists. Made for lots of problems when I took MD files made on a floppy >system to be laser-printed on a Mac w/ a HD and gobs of fonts. > The behavior described was typical of the original MacDraw code, done at Apple in the very early days of the Mac. Rather than storing the font name or number, the programmer chose to store the position in the font menu for the objects. If you added or deleted fonts from the Font Menu so that the order changed, you were going to get some very strange results. Even if there had been rules in those days, the programmer could have gone wrong since, at various times, Apple has waffled on whether the font name or number should be the information stored -- currently it is name. -- Dennis Cohen Claris Corp. ------------ Disclaimer: Any opinions expressed above are _MINE_!
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (05/18/89)
In article <10168@claris.com> drc@claris.com (Dennis Cohen) writes: >In article <48702@tut.cis.ohio-state.edu> Vampire <gaynor@cis.ohio-state.edu> writes: .>In article <24495@agate.BERKELEY.EDU> steve@violet.berkeley.edu (Steve Goldfield) writes: .>>When I launched it (old MacDraw) with the additional fonts, I noticed that .>>the fonts in the document changed; for instance the font menu said I was .>>using Camelot. I also had trouble trying to change the fonts; with the very .>>long list of fonts, the font size overprinted the list and .>>Chicago wasn't visible. >The behavior described was typical of the original MacDraw code, done at >Apple in the very early days of the Mac. Rather than storing the font name >or number, the programmer chose to store the position in the font menu for >the objects. If you added or deleted fonts from the Font Menu so that the >order changed, you were going to get some very strange results. Sorry for the long included text, but context is context. What is happening, is that Suitcase is randomly renumbering the FOND resources to avoid conflicts. You can recover your old font numbers (you DO remember them, don't you? No? Well, look at IM-I for the basic ones) by using ResEdit to change the resource numbers of the FOND resources back to the simple numbers used before. Here is my list: 0 Chicago 2 New York 3 Geneva 4 Monaco 5 Venice 6 London 7 Athens 8 San Francisco 11 Cairo 12 Los Angeles 13 Zapf Dingbats 14 Bookman 15 N Helvetica Narrow 16 Palatino 18 Zapf Chancery 20 Times 21 Helvetica 22 Courier 23 Symbol 24 Mobile 33 Avant Garde 34 New Century Schoolbook 128 Sonata (not a basic font) It is not necessary to change FONT or NFNT numbers. Marc Kaufman (kaufman@polya.stanford.edu)
brecher@well.UUCP (Steve Brecher) (05/20/89)
Context: a user had problems with an obsolete version of MacDraw when making additional fonts available via Suitcase II. Responders indicated that the obsolete MacDraw's font menu does not handle availability of "many" fonts. In article <9264@polya.Stanford.EDU>, kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes: > Suitcase [II] is randomly renumbering the FOND resources to avoid > conflicts. Suitcase II does not renumber FONDs. A utility which is part of the Suitcase II product, Font Harmony, may in some cases renumber FONDs in suitcase files which the user chooses to process. The original poster did not mention using Font Harmony. In fact, not using it (i.e., having font number conflicts) may have been part of his problem. (Font Harmony's renumbering is not random.) > You can recover your old font numbers ... by using ResEdit to change the > resource numbers of the FOND resources back to the simple numbers used > before. ... It is not necessary to change FONT or NFNT numbers. If a FOND is renumbered via ResEdit, it is also necessary to change the family ID number inside the FOND, to renumber any associated FONTs, and to change the FONT entries in the FOND's association table. -- brecher@well.UUCP (Steve Brecher)
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (05/20/89)
In article <11750@well.UUCP> brecher@well.UUCP (Steve Brecher) writes: >In article <9264@polya.Stanford.EDU>, kaufman@polya.Stanford.EDU >(Marc T. Kaufman) writes: -> Suitcase [II] is randomly renumbering the FOND resources to avoid -> conflicts. >Suitcase II does not renumber FONDs. A utility which is part of the >Suitcase II product, Font Harmony, may in some cases renumber FONDs in >suitcase files which the user chooses to process. The original poster did >not mention using Font Harmony. In fact, not using it (i.e., having font >number conflicts) may have been part of his problem. Yes, of course. I used Font Harmony when making up the suitcases. >(Font Harmony's renumbering is not random.) ?? It sure seems isomorphic to random. It is not RANDOM only in the sense that it insures non-conflict with other FOND ids. -> You can recover your old font numbers ... by using ResEdit to change the -> resource numbers of the FOND resources back to the simple numbers used -> before. ... It is not necessary to change FONT or NFNT numbers. >If a FOND is renumbered via ResEdit, it is also necessary to change the >family ID number inside the FOND, to renumber any associated FONTs, and to >change the FONT entries in the FOND's association table. I didn't renumber the family ID or the FONTs, since Font Harmony changed everything to NFNTs, which certainly don't need to be renumbered. Marc Kaufman (kaufman@polya.stanford.edu)
brecher@well.UUCP (Steve Brecher) (05/22/89)
In article <9334@polya.Stanford.EDU>, kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes: > [Font Harmony's font renumbering] sure seems isomorphic to random. It is not > RANDOM only in the sense that it insures non-conflict with other FOND ids. It is not random in any sense. FOND IDs are chosen by a deterministic algorithm that (a) avoids using numbers in 0..255 where possible, i.e., where the family is all-NFNT (b) avoids conflict with IDs already in use on the user's system; (c) minimizes the chance of future conflict with IDs assigned by Apple to font vendors; and (d) minimizes the chance of conflict with FONTs embedded in applications. -- brecher@well.UUCP (Steve Brecher)
pv9y@vax5.CIT.CORNELL.EDU (05/24/89)
In article <11765@well.UUCP> brecher@well.UUCP (Steve Brecher) writes: > >In article <9334@polya.Stanford.EDU>, kaufman@polya.Stanford.EDU (Marc T. >Kaufman) writes: > >> [Font Harmony's font renumbering] sure seems isomorphic to random. It is not >> RANDOM only in the sense that it insures non-conflict with other FOND ids. > >It is not random in any sense. FOND IDs are chosen by a deterministic >algorithm that (a) avoids using numbers in 0..255 where possible, i.e., where >the family is all-NFNT (b) avoids conflict with IDs already in use on the >user's system; (c) minimizes the chance of future conflict with IDs assigned >by Apple to font vendors; and (d) minimizes the chance of conflict with FONTs >embedded in applications. >-- > >brecher@well.UUCP (Steve Brecher) There is a conflict with method (a) of the algorithm which I just ran into. It seems that WordPerfect Corp. set up WordPerfect so that it only recognizes FOND numbers under 255. Kind of dumb, although it is being fixed as we speak. So if you suddenly can't select a font from your Font menu, that font may have a FOND id over 255. My question to Steve is whether or not there is any way of making sure certain fonts end up in a certain range of numbers? I don't really care if my weird bitmap fonts are over 255 (and I won't care at all soon), but I was having a nightmare not being able to use Bookman or Palatino, etc. I fixed everything using ResEdit, but now I'm afraid to re-Harmonize for fear of messing it up again. Any suggestions (other than hassle WordPerfect, who have been remarkably prompt and helpful whenever I call)? Actually, while I'm on the subject of WordPefect, if you use Deneba Software's Comment 2.0, the line number in WordPerfect is messed up by AutoLoader. Don't know why and haven't gotten to calling Deneba yet. Also, WordPerfect 1.02 introduced a bug which keeps the program from informing the user if Timed Backup files exist after a crash. This only happens on occasion, but is a pain. The work around is to use Files Management to change the type of the file to WPD0 from whatever it is, WPTV I think. Then you can open it normally. Nice being ableto do that from within a program, rather than having to mess with ResEdit. Adam Engst Unassociated thoughts . . . .