Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!sun-barr!decwrl!adobe!gelphman
From: gelphman@adobe.COM (David Gelphman)
Newsgroups: comp.sys.mac
Subject: Re: Font Translation Problems
Message-ID: <1137@adobe.UUCP>
Date: 1 Sep 89 01:06:27 GMT
References: <44968@bbn.COM>
Reply-To: gelphman@adobe.UUCP (David Gelphman)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 45

In article <44968@bbn.COM> mfrishko@BBN.COM () writes:

>
>I developed a specialized font, an edited version of zapf dingbats (actually,
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                  this is the problem, see below
>the font has nothing to do with zapf dingbats, but I started with zapf
>dingbats for reasons I can't recall now).  Since I edited zapf dingbats,
>I called it "my Zapf Dingbats".  I gave it a font number of 203.   So the
>name and number were distinct from zapf dingbats.  
>
>When I printed a document using this font on the laser printer, I was surprised
>to find that it had substituted zapf dingbats!  Of course, my new font
>was just a screen bitmap, but I expected that the bits would be sent to
>the laser printer (Apple Laserwriter II).
>
>My question is:  how is font info sent to the laser printer, and how does
>it decide what to substitute?  Does the font number get sent, or the name,
>or both?  Is it possible that it noticed that "my zapf dingbats" and
>"zapf dingbats" are close in name, and hence substitutable?  Is there a way
>to force it to send the screen bitmap font?

>Michael Frishkopf (mfrishko@bbn.com)
>BBN Communications Corporation, Cambridge MA

Unfortunately the solution to this problem is a bit complex. The FOND resource
for PostScript fonts contains information which tells the LaserWriter 
driver what PostScript font name to use when generating the PostScript
code to send to the printer. Since you started with the FOND resource
for Zapf Dingbats the FOND still has imbedded in it that the proper
PostScript font to use is Zapf Dingbats. It sees that the printer does
indeed contain Zapf Dingbats so it goes ahead and uses it. In addition,
the FOND resource contains the width, kerning, and other associated
information for Zapf Dingbats which means that applications which use
the fractional widths contained in the FOND will be using widths appropriate
for Zapf Dingbats instead of your new font. Editting the FOND resources
is not for the faint of heart, to least not this part of the FOND. There
may be a trivial way to tell the system to ignore this information
in the FOND but I don't know what it is. In the absence of such a method,
I would recommend that you use a tool to generate fonts rather than
use ResEdit on an existing font. 

Hope this helps,
David Gelphman
Adobe Systems Incorporated