From: bkph@wheat-chex.ai.mit.edu (Berthold K.P. Horn)
Newsgroups: comp.fonts,comp.lang.postscript
Subject: Problems with Composite Fonts and Printer Resident Fonts:
Date: 26 Aug 92 20:12:05 GMT
Followup-To: comp.fonts


Problems with Composite Fonts and Printer Resident Fonts:
---------------------------------------------------------

Composite Type 1 fonts carry within their encrypted part another 
Type 1 font, which is used as a base for constructing the new font.  
There are some problems with such fonts when used on some PostScript
printers that have the base font already built in.

Composite fonts are typically used for Oblique or Narrow versions
of a font. They ASCII poart starts the same way other T1 fonts do.
The encrypted part also starts as usual with font level hints and Subrs.
The Subrs are for hints and hint replacement, and are identical to the
Subrs in the base font, which comes next.

After the Subrs, instead of the CharStrings, appears the base font,
wrapped in code that checks whether it is already defined. 
The cocoon is discarded if the base font is already defined. 

The base font and its wrapper is followed by code which basically
just copies the CharStrings from the base font into the new font.
That ends the encrypted section, which in turn is followed by the
usual eight lines 64 zeros and cleartomark. (In other words you can't
tell from the outside that a font is composite.) 

Why go to all this trouble?  Rather than say just copying the base
font and changing the FontName, UniqueID, FontMatrix and ItalicAngle.
I guess the reason must be virtual memory usage, since there is a
savings when the CharStrings are shared with the base font - if the
base font already exists.  (So why aren't the Subrs also shared?)

This all works fine, UNLESS the base font is a printer resident font.
On some PostScript printers (haven't checked too many) the CharString
dictionary for resident fonts contains keys (character names) and
NUMBERS (not strings). (The characters - oops, the glyphs - appear to
be ordered alphabetically and numbered sequentially, starting at 1
and ending at 228 for most Adobe text fonts).

Perhaps using a number instead of the CharString itself here is a
clever hack to prevent you from prying into the character outline -
The actual CharString is off in some array you can't get at.
Or it has some advantage in terms of coding or memory usage or
whatever.  In any case, you can guess what happens if you copy such a
CharString dictionary into the new font:  No characters will be
rendered.  So downloading a composite font to a printer that has the
base font wired in does not work.

If you download say Helvetica-Oblique, and the printer contains code
for Helvetica already, then your Helevtica-Oblique will not work.
Curiously, on some printers Courier-Oblique works, even though it is
based on Courier in the same way.  The reason is that the built in
Courier often has a different version number (002.003) and UniqueID
(27077) than the Courier distributed with ATM (version number 002.004
and UniqueID 36347).  And so the code checking for the base font
rejects it as a potential substitute.

Of course, printers typically have Courier-Oblique, Helvetica-Oblique
and Helvetica-Narrow etc wired on, so one can just use those directly. 
The lesson is, don't download composite fonts that are based on fonts
that are printer resident.

(Maybe someone would care to explain why the CharStrings dictionary
entries contain numbers in the case of resident fonts on some
PostScript printers?) 

Should a printer that has this `bug' be considered at odds with the
PostScript spec?  Or is this fairly general?  The ALW II NT does NOT 
have this bug.  

Berthold K.P. Horn
Cambridge, Massachusetts, USA
Newsgroups: comp.fonts