RE: [Devel] CFF fonts assume Type 2 charstrings

[Tom Kacvinsky]

Hi all,

On 2002/08/09 at 13:45, Tom Kacvinsky <address@hidden> wrote:

Oh yeah, this is very important (and it is taken care of when charstrings
are stored):  CFF fonts never use charstring encryption (basically, the
same encryption method that is used for eexec data, but with a differnt
seed and "key").  The Type 1 parser decodes the charstring before storing
the charstring, and the CFF driver does not have to do this.

If psaux is going to handle Type 2 charstrings (from CFF fonts), then it
is going to have to handle global subroutines.

> do not forget the subroutine bias number.

This can be handled by setting the bias to 0 for Type 1 charstrings.

> flex hints are handled differently.

There are more types of flex hint operators in Type 2 charstrings, and
Type 2 charstrings handles them without relying on "standard" Subrs and
OtherSubrs entries.

> and so on...

I feel like Kurt vonnegut when I write that.


> On 2002/08/09 at 09:57, George Williams <address@hidden> wrote:
> 
> At 09:51 AM 8/9/2002 +0100, you wrote:
> 
> > Now this is very interesting. I suspected that might be the case. This
> > means that the Types 1 and 2 charstring parsers could be merged and put
> > into the common PostScript-font module (psaux?). A call to the parser
> > could select type 1 or 2 by means of a new argument. That would save
> > code and make my life easier.
> 
> This is what PfaEdit does.
> 
> Essentially the parser handles the codes from both type1s and type2s. You 
> need to do a little extra set up (the subroutine table needs to include its 
> base offset (which is 0 for type1s and approximately cnt/2 for type2s).

I do not understand what you are talking about here.  Base offset in the actual
CFF wrapper?  Base offset in terms of FT internal data structures?  The Subrs
bias as documented in the Type 2 specification?

> 
> The places where I actually check the type1/2 flag are:
>     * numbers starting with 255

Yes, this is an area of concern.

>     * Needed a special check for paths containing single points when
>       doing a closepath

This should be done in Type 1 fonts, too.

>     * Special check in the first *moveto for the width argument.

There are other Type 1 path operators that have an overloaded definition in Type
2 charstrings.  For instance, vhcurveto and hvcurveto in Type 1 fonts only start
vertical (horizontal) and end horizontal (vertical, resp.), whereas in a Type 2
charstring, this operator can be used to construct several paths which alternate
between beginning with vertical and horizontal tangents.