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

[Tom Kacvinsky]

Hi Werner,

> 
> > But in z1driver.c, function Get_Char_index (which is assigned as the
> > callback for FTDriver_getCharIndex in the type1z driver) uses the
> > cmap which is passed to it, which is face->charmap
> > (face->charmap[0], not face->charmap[1]).  If I add code to
> > z1driver.c to use face->charmap[1], Ft_Get_Char_Index returns poper
> > values for CMEX10, etc...
> 
> I still don't see the problem.  You have to select the proper CharMap
> with FT_Set_Charmap().  If you don't do that, Unicode will be selected
> (which is of course a bit unfortunate for CMEX10 :-)

No, you understand what the problem is.  The thing is, I am just getting into
the Unicode part of ft2, so I haven't yet looked at all of functions one can use
to control cmaps.

> It is important, however, to check face->unicode_map->num_codes after a call
> to Z1_Init_Face() to see how many glyphs can be mapped at all.  Maybe we
> should move this field to FT_CharMapRec so that the user can access this
> number for all font formats in a uniform way.  Of course, only for synthesized
> mappings this value has significance; for real charmaps it should be set equal
> to -1 or something else.
> 

Lets see, a Type 1 font has a synthesized mapping, and a TT font without a
Unicode cmap has a synthesized mapping?  That is, a cmap that is built based
on what glyphs are defined in the glyf table (or CharStrings dictionary)?

If, on the other hand, the font is a OTF or TT font, the cmaps are already
predefined, so  you would return -1 in theis case to indicate the mappings
were built in?

Thanks,

Tom