Re: FT_Get_Char_Index() returns 0 for char(0x020)

[Tom Kacvinsky]

I have been looking into this.  Two things:

The return value of FT_Get_Char_index is supposed to be a glyph index.  In a TT
font, this is used to get an offset from the loca a table.  In a Type 1 font,
there is no loca table, so the index is used to access the elements of the
CharStrings dictionary, which is stored in a zero-based array.  Oops!  Does 0
means not defined, or entry zero?

The other thing is that z1objs.c defines two charmaps:

  charmap->encoding    = ft_encoding_unicode;
  charmap->platform_id = 3;
  charmap->encoding_id = 1;

and one of

  charmap->encoding    = ft_encoding_adobe_standard
  charmap->platform_id = 7;
  charmap->encoding_id = 0;

  charmap->encoding    = ft_encoding_adobe_expert
  charmap->platform_id = 7;
  charmap->encoding_id = 1;

  charmap->encoding    = ft_encoding_adobe_custom
  charmap->platform_id = 7;
  charmap->encoding_id = 2;

But z1driver.c only uses the first charmap (platform_id = 3, encoding_id = 1).

So I suspect the problems stem from Unicode support for Type 1 fonts.
By the way, FT_Get_Char_Index returns 0 for *every* code point defined
in CMEX10.pfa.

Tom

On Sat, 14 Oct 2000, Leonard Rosenthol wrote:

> At 9:38 AM +0200 10/13/00, Werner LEMBERG wrote:
> >  > Leaonard, according to the PFA files I have for Adobe Palatino,
> >>  there is a valid space glyph in Palatino Roman, and it has zero
> >>  advance width.  So I guess it might be something in z1driver.c
> >>  related to the encoding array in the Type 1 font...
> >
> >Do you have the font to investigate this?
> >
>       Sure, they are all Adobe Type 1 fonts off the Adobe Type CD. 
> Some problem ones include Palatino (font #001) and Impact (#211).
> 
>       I looked at the AFM data as Tom suggested, and they DO have a 
> glyph defined for char(32), but it's 0 width.  Another interesting 
> point is that the Berkeley font (#106) also has a 0 width char(32), 
> BUT it works!
> 
> 
> Leonard
>