Xref: utzoo comp.lang.postscript:7893 comp.sys.mac.apps:4540 comp.sys.mac.misc:9462
Path: utzoo!news-server.csri.toronto.edu!rutgers!att!pacbell.com!decwrl!adobe!gelphman
From: gelphman@adobe.COM (David Gelphman)
Newsgroups: comp.lang.postscript,comp.sys.mac.apps,comp.sys.mac.misc
Subject: Re: ZapfDingbats problem in FreeHand generated EPSF ?
Message-ID: <12433@adobe.UUCP>
Date: 13 Mar 91 11:11:34 GMT
Followup-To: comp.lang.postscript
Organization: Adobe Systems Incorporated, Mountain View
Lines: 29

>>I have a problem with getting ZapfDingbats in EPSF files generated by
>>Aldus FreeHand 2.0 on the Mac: they don't show up.
>>
>>Does anybody know what's going on here, is there a bug in the FreeHand
>>EPSF header?
...
>Bye the way, almost all programs I've seen do this reencoding in the prolog,
>including Apple's LaserPrep.  In the latter case, from what I can tell,
>LaserWriter driver generates a flag (True or False) for each font, giving False
>for those fonts whose encoding shouldn't be tampered with, and the procedure
>defined in the LaserPrep changes the encoding only if the flag is not False.
>
>So here is my question:  how does the LaserWriter driver figure that out?

   On the Macintosh the FOND resource contains a Font Classification
word which indicates (among other things) whether the font is a 'standard'
Mac encoded font or whether it must be specially encoded. For fonts which
are specially encoded, the FOND contains a font encoding table which 
is a delta encoding applied to that fonts built in encoding. In the case
of Symbol, the font classification indicates that it is NOT a standard
Mac encoded font so it should not be treated the same way as, say, Times-Roman
but the delta vector is zero, meaning that the font is not re-encoded from
it's built in encoding.
   This information is published in the LaserWriter Reference Manual
by Addison Wesley. 

Hope this helps,
David Gelphman
Adobe Systems Incorporated