Path: utzoo!attcan!uunet!mcsun!ukc!cam-cl!news
From: cet1@cl.cam.ac.uk (C.E. Thompson)
Newsgroups: comp.lang.postscript
Subject: Re: Why does a font need an Encoding vector?
Message-ID: <1990Nov3.204549.21042@cl.cam.ac.uk>
Date: 3 Nov 90 20:45:49 GMT
References: <1990Oct31.225607.10364@phri.nyu.edu> <ttazromgua@visix.com> <1990Nov2.012303.9487@phri.nyu.edu> <11090@goofy.Apple.COM>
Reply-To: cet1@cl.cam.ac.uk (C.E. Thompson)
Organization: U of Cambridge Comp Lab, UK
Lines: 18

In article <11090@goofy.Apple.COM> kevina@apple.com (This space for rent) writes:
>There are a lot of subtleties having to do with caching of user-defined 
>characters (particularly if the font has a UniqueID entry.)  To be safe, I 
>always use StandardEncoding as my Encoding vector when the BuildChar 
>doesn't need one at all.  Helpful hint:  *Don't* use "256 array"... the
>characters may not get cached at all!
>
But StandardEncoding has lots of /.notdef's at positions 0..31, 127..160, etc
doesn't it? So it isn't suitable for a Type 3 font with a BuildChar routine
independant of the Encoding vector, but which does use these character 
positions. Otherwise you'll confuse the font cacheing machinery horribly.
In my DVI to PostScript converter (fairly standard in this respect, I think)
I use an array of 256 different names. Of course, I share it between all 
the fonts I define.

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk