type1z, comments, etc... [was: failing fonts]

[Tom Kacvinsky]

If you have the default build of freetype2, then when opening up an
instance of a MM font, the type1 module is used.  Looking at the
source, comments are skipped in the type1 module.  However, there is
some uncommented PS code in the instance that includes the token
/BlendAxisTypes, which forces the type1 module to quit.  Then the
type1z module is tried.

It is the type1z module that barfs because (I am convinced of this
now) the module can't load the /Blue... stuff in the Blend
dictionary's Private dictionary -- the set up is such that the
BlueScale, BlueFuzz, and BlueShift are all scalars, instead of arrays.
In the problematic fonts, the Blend dictionary's Private dictionary has
these as arrays.  Ooops!  Of course, these reside in PS comments, so
why are they getting parsed?  Which leads to the other observation you
made:

The type1z module does not skip comments.  Even if it did, we would
still have problems because of the other cruft that is not commented
out.  More or less, an instance ought not have any of the stuff that
defines makeblendedfont, etc..., and remove the othersubrs and subrs
related to MM interpolation.

Tom

On 9 Jul 2000, James H. Cloos Jr. wrote:

> >>>>> "Tom" == Tom Kacvinsky <address@hidden> writes:
> 
> Tom> [mminstance] simply comments them out.  I haven't checked
> Tom> carefully, but if those modules don't parse out the comments,
> Tom> they might be fooled into thinking the instance is an MM font
> Tom> (which it isn't anymore).
> 
> Removing (but not just commenting out) those /Blue entries in /Private
> and reassembling allows ftmulti to work.  Commenting them out does not,
> so it looks like comments are not being ignored.
> 
> (Tested to determine whether comments were being ignored, but mostly
> just to see what the fonts looked like. :)
> 
> Also, if you compare those fonts with Adobe(Sans|Serif)MM, the former
> have arrays for more /Blue stuff than the latter.  May be relevant.
> Or not.
> 
> -JimC
>