Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!usc!apple!apple.com!kevina
From: kevina@apple.com (This space for rent)
Newsgroups: comp.lang.postscript
Subject: Re: Why does a font need an Encoding vector?
Message-ID: <11090@goofy.Apple.COM>
Date: 2 Nov 90 17:03:23 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 58
References:<1990Oct31.225607.10364@phri.nyu.edu> <ttazromgua@visix.com> <1990Nov2.012303.9487@phri.nyu.edu>

I tried to post this yesterday but our mailer failed... it looks like 
Amanda came to the same conclusion.  Look at the end for a follow-up.

In article <1990Oct31.225607.10364@phri.nyu.edu> roy@alanine.phri.nyu.edu 
(Roy Smith) writes:
>         The Red Book says that the Encoding vector is a required item for
> all fonts.  Why?  Is there some bit of internal PS font machinery that 
uses
> it?  As far as I can tell, it's only used by the font-supplied BuildChar
> routine.  What if I wanted to write a font in which there really wasn't 
any
> reason to use the Encoding vector at all?  Maybe what I wanted to do was
> have a font in which each character was simply a circle of thickness 30 
and
> radius c, centered in a 1000 unit square space, where c is the ascii code
> for the character?  No reason for an Encoding vector, just:
  ...
 
(I'm assuming that you're talking about Type 3 fonts only... the internal 
BuildChar routine for Adobe built-in fonts definitely depends on 
Encoding!)  The font that you described does not need an Encoding vector 
for its BuildChar.  But how is the PostScript font machinery going to 
access the bitmap which you just built?  It can't use the character code 
-- e.g. if your BuildChar did depend on an Encoding vector, it would be 
trivial to swap the 'a' and 'b' glyphs' encodings.  Therefore, even in a 
Type 3 font, it uses the associated name, which it gets from the font's 
Encoding vector.  Level 2 PostScript is more forthcoming about all this 
(including new BuildGlyph and glyphshow routines which explicitly access a 
glyph by name.)

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!

In article <1990Nov2.012303.9487@phri.nyu.edu> roy@phri.nyu.edu (Roy 
Smith) writes:
>         But what if I'm using a font that doesn't get cached?  Notice in 
my
> example I used setcharwidth not setcachedevice in BuildChar.  The reason 
I
> did that is because in the real font that I'm building, I need greyscale,
> which according to the Red Book can't be cached.

When the font machinery decides, "this character isn't cached already; I'm 
going to have to call BuildChar", it doesn't know whether you are going to 
invoke setcachedevice or setcharwidth within the BuildChar procedure, so 
I'm sure that it assumes the character will be cached (and therefore needs 
a name from the Encoding vector) for efficiency.  In the case which you 
presented, there is no *necessary* reason for an Encoding vector.  
(Although Glenn's right... the overhead using StandardEncoding is 
negligible.) 

Disclaimer:  No official Adobe or Apple information here...

--Kevin Andresen [kevina@apple.com]
"This is my investigation... it's not a public inquiry"