phcalamai@water.UUCP (Paul H. Calamai) (05/09/85)
Perhaps I'm doing something wrong but it appears to me that desk accessories in DAM v1.3 or v1.4 format cannot be loaded using the new Font/DA mover. The new mover does however recognize these DA's if they are already loaded (using the DAMover) and can then be used to create the equivalent DA in the format readable by the new mover. Is this truly the case or am I missing something (in which case I apologize to those in-the-know). Thanks in advance, Paul (calamai@anl-mcs.arpa or phcalamai%water%waterloo.csnet)
shulman@topaz.ARPA (Jeff Shulman) (05/11/85)
In article <525@water.UUCP> phcalamai@water.UUCP (Paul H. Calamai) writes: >Perhaps I'm doing something wrong but it appears to me that >desk accessories in DAM v1.3 or v1.4 format cannot be loaded >using the new Font/DA mover. The new mover does however recognize >these DA's if they are already loaded (using the DAMover) >and can then be used to create the equivalent DA in the format >readable by the new mover. > >Is this truly the case or am I missing something (in which >case I apologize to those in-the-know). > > Thanks in advance, Paul (calamai@anl-mcs.arpa or > phcalamai%water%waterloo.csnet) DA's are implemented as device drivers. These drivers are kept in DRVR resources in the resource fork of the SYSTEM file. The Apple DA/Font mover deals directly with these resources in the resource fork. DAM, on the other had, moved these resoures to (from) the data fork of the saved DA file from (to) the resource fork of the SYSTEM file. Since the DA/Font mover is not looking in the data fork of a file (and DAM probably has its own way of storing things) the two DA movers are totally incompatible. Of course, once in the SYSTEM file, either mover will be happy to save a DA in its own format. -- Jeff uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!shulman arpa: SHULMAN@RUTGERS
maclab@reed.UUCP (Mac Development Lab) (05/12/85)
> Perhaps I'm doing something wrong but it appears to me that > desk accessories in DAM v1.3 or v1.4 format cannot be loaded > using the new Font/DA mover. The new mover does however recognize > these DA's if they are already loaded (using the DAMover) > and can then be used to create the equivalent DA in the format > readable by the new mover. > > Thanks in advance, Paul (calamai@anl-mcs.arpa or > phcalamai%water%waterloo.csnet) I would like to know exactly what the format is, if anyone knows -- I have almost finished a Rascal utility program which turns Rascal objects into Desk Accessories, and want to make sure these accessories are saved in the 'standard' format. Details, please? Scott Gillespie MacLab Reed College {decvax, ucbvax, pur-ee, uw-beaver, masscomp, cbosg, aat, mit-ems, psu-cs, uoregon, orstcs, ihnp4, uf-cgrl, ssc-vax}!tektronix \ +--!reed!maclab {teneron, ogcvax, muddcs, cadic, oresoft, grpwre, / harvard, psu-cs, omen, isonvax, nsc-pdc}-------------+
jimb@amdcad.UUCP (Jim Budler) (05/12/85)
In article <525@water.UUCP> phcalamai@water.UUCP (Paul H. Calamai) writes: >Perhaps I'm doing something wrong but it appears to me that >desk accessories in DAM v1.3 or v1.4 format cannot be loaded >using the new Font/DA mover. The new mover does however recognize >... >Is this truly the case or am I missing something (in which >case I apologize to those in-the-know). Absolutely correct. The new Mover stores the DA's as a resource, which they are. The old Shareware mover stored them as data. The new one does many checks for possible conflicts in numbers, and DA owned private resources, and will refuse to move some DA's such as the calendar DA, (I think summac), which don't properly assign private resource numbers. These often caused problems with the old DA Mover, however, and may not be a loss. Calendar could walk over other DA's if not installed first, resulting in a broken system. Much of this information came from a discussion thread on Compuserve by the author of the new mover. He's still working on updates. -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200 "... Don't sue me, I'm just the piano player!...."
ward@hao.UUCP (Mike Ward) (05/12/85)
> Perhaps I'm doing something wrong but it appears to me that > desk accessories in DAM v1.3 or v1.4 format cannot be loaded > using the new Font/DA mover. DAM stores its desk accessories in the data fork of its files. DA/Font Mover stores its fonts and desk accessories as resources in the resource fork. To change your DAM files to mover file you have to cycle them through a system file.
eilers@stolaf.UUCP (David V. Eilers) (05/16/85)
> > Perhaps I'm doing something wrong but it appears to me that > > desk accessories in DAM v1.3 or v1.4 format cannot be loaded > > using the new Font/DA mover. > > DAM stores its desk accessories in the data fork of its files. > DA/Font Mover stores its fonts and desk accessories as resources > in the resource fork. To change your DAM files to mover file > you have to cycle them through a system file. *** REPLACE THIS LINE WITH YOUR MESSAGE *** A quick method to transfer DAM formated (data) DAs to Font/DA Mover DAs is to use a ram disk with a system file on it and install your DAs in that system. It cuts the time you'll wait for these programs to access the disk dramatically. Dave Eilers ihnp4!stolaf!eilers
howard@amdahl.UUCP (Howard C. Simonson) (05/16/85)
> DA's are implemented as device drivers. These drivers are kept in DRVR > resources in the resource fork of the SYSTEM file. The Apple DA/Font > mover deals directly with these resources in the resource fork. DAM, > on the other had, moved these resoures to (from) the data fork of the > saved DA file from (to) the resource fork of the SYSTEM file. > > Since the DA/Font mover is not looking in the data fork of a file (and DAM > probably has its own way of storing things) the two DA movers are totally > incompatible. > > Of course, once in the SYSTEM file, either mover will be happy to save a > DA in its own format. > -- This brings me to a question: what about desk accesories with more than just DRVR resources. I think the DAM used to take care of it. I think I remember seeing STR and DLOG(s) showing up in my system that were obviously DA material. But now with the MV ( Moving Van ), I'm not so sure that integrity is maintained. ( Larry, if I'm wrong, give a holler ) I sat down not too many nights ago and converted all my DA's over to Resource format. What fun :-). I was tempted to fire up switcher with a small Ramdisk containing the current system and one window running DAM and the other running MV. Just tempted, not crazy. I was afraid of one too many things updating the system at once. If someone wants to try it, let me know how it all works out :-). Well now I've got some old DA's bombing on me. ( Here I insert appropriate praise for the Resume resource, THANK YOU!!! ) So my question stands, what does MV move? -- Time for a new catchy phrase in my Howard C. Simonson .signature, now if I could only ...{dragon,hplabs,ihnp4,nsc}!amdahl!howard think of one... [ Opinion? What opinion. I think you have the wrong guy... ]
jimb@amdcad.UUCP (Jim Budler) (05/16/85)
In article <1529@amdahl.UUCP> howard@amdahl.UUCP (Howard C. Simonson) writes: >> -- > >This brings me to a question: what about desk accesories with more than just >DRVR resources. I think the DAM used to take care of it. I think I remember >seeing STR and DLOG(s) showing up in my system that were obviously DA material. > >But now with the MV ( Moving Van ), I'm not so sure that integrity is >maintained. ( Larry, if I'm wrong, give a holler ) I sat down not too >many nights ago and converted all my DA's over to Resource format. >What fun :-). ... >... >it all works out :-). Well now I've got some old DA's bombing on me. >( Here I insert appropriate praise for the Resume resource, THANK YOU!!! ) >... The new DA Mover does a better job of moving private owned resources in that in many cases it will renumber the owned resources properly. There are some exceptions, but it recognizes and refuses to move those DA's. These are DA's such as the original Calendar DA, which could walk over other DA's on installation with the old DA Mover. There ARE however DA's such as the time DA which are incompatible with the new Finder. The author of the Time DA posted a revised DA with that statement, unfortunately he didn't post an explanation of the incompatibilities.-- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200 "... Don't sue me, I'm just the piano player!...."
jasond@mtuxo.UUCP (j.demont) (06/16/86)
Can anyone explain to me why within one file of fonts, Font/DA Mover 3.X and Fontastic 2.3 occasionally present the same font with different names? For example, Font/DA lists a font as Palatino 12 and Fontastic lists the same font as Moscow 12. Zapf Chancery 18 & 36 are represented as Wartburg 18 & 36 respectively in Fontastic. Also in MacDraw or MacPaint, my font menu lists the fonts Avante Garde, Bookman N Helvetica Narrow, New Century Schlbk and others that neither Font/DA or Fontastic identify as being in my system (3.1.1) file. I am using a Mac+ with Finder 5.2 and System 3.1.1. Anyone got any ideas? Any help would be appreciated. Jason De Mont (ihnp4!mtuxo!jasond)
briand@tekig4.UUCP (Brian Diehm) (06/18/86)
>Can anyone explain to me why within one file of fonts, Font/DA Mover 3.X >and Fontastic 2.3 occasionally present the same font with different names? > >I am using a Mac+ with Finder 5.2 and System 3.1.1. Using FONTastic 2.3 with a Mac Plus is guaranteed to give zany results, though I don't know if font names are among them. Altsys didn't claim compatibility with Mac Plus until version 2.6. However, I've found Version 2.7 to be buggy. In addition, note carefully that you shouldn't use Mac Plus-compatible versions to work with the System file - you should use the Font/DA Mover to do that. Personally, I think that with Mac Plus, FONTastic is not a product yet, which is too bad because it used to be a very reliable and well-designed one. Their manpower resources must be committed to Fontographer. . . Altsys will upgrade your FONTastic for $8 if you send in your old disk, or $10 if you don't but they have you registered. -Brian Diehm Tektronix, Inc.
graifer@net1.UCSD.EDU (Dan Graifer) (06/21/86)
in 1667mtuxo ihnp4!mtuxo!jasond complainst about different applications having different names for the same font I also have had some wierd problems with fonts. I recently was asked to test an application that came with an "aux" file which included some resources and data to customize the application for a particular task. One of the resources was a special font the application used. Unfor- tunately, I already had a font defined, but non existant (San Francisco 9) with the same number in my system file. I copied the application and aux file to my hard disk (system 3.1.1/finder 5.2) and tried to open the application: bizarre... the application asked for the font by number I think, and the system, not having a SF9 to give it, made one up by scaling SF18. Font/DA mover thought the font was SF9 as well, and ResEdit gave me SF9 to edit, although GetInfo in ResEdit knew the correct name for the font! My solution was to boot up ( minus harddrive) on the system the application came with, then make a new font file with just the special font. I then rebooted off my regular system, and used Font/DA mover to first delete the font that was confusing the system in the harddisk copy of the AUX file, then replace it by copying from the Font file on the floppy. This allowed Font/DA Mover to correctly create the FOND resource in the aux file to redirect calls for that font, which got renumbered to 16000 something! So try poking around with Font/DA Mover and ResEdit, and try installing the messed up fonts again. Good luck Dan Graifer
briand@tekig4.UUCP (Brian Diehm) (06/23/86)
>I also have had some wierd problems with fonts. >... the application asked for the font by >number I think, and the system, not having a SF9 to give it, made one >up by scaling SF18. Font/DA mover thought the font was SF9 as well, and >ResEdit gave me SF9 to edit, although GetInfo in ResEdit knew the correct >name for the font! The FOND resource (new to system 3.x and the new ROMs) has FOND resources. Included in each FOND (there is a FOND for each font family) is a listing of the various sizes of fonts that are present. This table is the next to last entry in the FOND resource, and at least ResEdit 1.0D12 contains a template for FONDS. Anyway, simply extending this entry, telling the resource number and size of your new font, should extend the system so that it really recognizes your new size of font. Your long method simply did this the hard way. Font/DA Mover 3.x and beyond handle and create FOND resources as needed. -Brian Diehm Tektronix, Inc.