🚀 go-pugleaf

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?

Yes, definefont looks at it during error-checking.

It's true that there is an occasional situation where you don't really
need the Encoding vector (such as your case, when all the characters
are the same).  However, most fonts contain different characters, and
benefit from the possibility of being reencoded.

The overhead for including an Encoding vector is extremely low, and for
essentially all PS implementations existing today is 20 bytes (the cost
of the dictionary entry for "Encoding").  The StandardEncoding vector
is already in memory, and you just get another pointer to it when you
say "/Encoding StandardEncoding def".  Since the overhead is so low, it
is not unreasonable to make it a required item in a font, since 10 times
out of 9 it is a good thing.

Now whether or not you actually vector through the Encoding in your
BuildChar is up to you, of course.

>it?  As far as I can tell, it's only used by the font-supplied BuildChar
>routine.

Well, there is an occasional program that looks at the Encoding vector
to see whether or not the font has a standard character set.  For example,
if you're writing a program to print out a sample of all the fonts on
your printer, it is a nice enhancement to check the Encoding vector, and
if it is not StandardEncoding, you print out the name of the font in,
say, Helvetica, so you can read it (think of Sonata or Symbol), then print
a short sample of the font itself.

/Glenn

-- 
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		PostScript/NeXT developers
 ..{adobe,next}!heaven!glenn		415-851-1785