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

[Tom Kacvinsky]

I should have made myself clearer on this:

The Unicode stuff is working as intended.  There are no bugs that I can see.
The problem is that Adobe Garamond (haven't checked Palatino, that is at work, I
am at home) has /space as the first glyph defined in the CharStrings dictionary,
so the glyph index for that is 0.  I am making a guess that the reason why
Berkeley works is that space is not the first glyph defined in the CharStrings
dictionary, but rather the second (or later) defined glyph.

The other point I was trying to make is that one should check to see if the
charmap with platform_id = 7 and encoding_id = 2 is defined for the font.  If it
is, it is better to use that than platform_id = 3, encoding_id = 1, because Type
1 fonts with custom encodings don't always use glyph names that made it into
Adobe's Unicode glyph name list.  This was the problem with CMEX10

Regards,

Tom

glyph, one should check to see if 


On Sat, 14 Oct 2000, Tom Kacvinsky wrote:

> 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
> > 
>