Re: [ft-devel] FT_Get_Char, FT_Get_Next_Char

[Nicolas Rougier]

Thanks for the explanation.
I've transmitted your answer on the freetype-py issue page.


Nicolas


On Sep 26, 2011, at 9:29 , Werner LEMBERG wrote:

>>>> I'm getting the following output:
>>>> 
>>>> Num glyphs: 3
>>>> char: 32 (index = 1)
>>>> char: 160 (index = 1)
>>>> How do I get the last char ? (or did I do something wrong ?)
>>> 
>>> Without seeing the font this can't be answered.  For example,
>>> character code 160 might map to the `space' glyph, having glyph
>>> index 1 also.
>> 
>> The actual question was related to the number of glyphs (3) and the
>> use of first/next char.  Am I not supposed to be able to get all
>> glyphs using them?  Obviously I only get 2 of them while I would
>> have expect 3.
> 
> I think this is a bug in FreeType.
> 
> This font has three glyphs:
> 
>  0  .notdef
>  1  space
>  2  a77
> 
> If you use `ftdump -v' (from a recent FreeType version), you can see
> this:
> 
>  charmaps
>     0: platform 3, encoding 1, language 0 (active)
>        0x0020 => 1
>        0x00a0 => 1
> 
>     1: platform 7, encoding 2, language 0
>        0x0020 => 1
>        0x0074 => 2
> 
> Platform/encoding pair (3,1) is Unicode, (7,2) is Adobe custom
> encoding.  Only the latter is contained within the font, the Unicode
> charmap gets synthesized by FreeType.  And here is the problem: The
> glyph with name `a77' has a canonical mapping to Unicode character
> U+25BC (as can be seen in file `zapfdingbats.txt' from the Adobe Glyph
> List), but FreeType doesn't handle zapfdingbats.txt; this is an
> oversight.
> 
> Note, however, that in subsetted CFFs (as part of PDF files) you
> normally have a lot of glyphs which can't be accessed by Unicode
> character codes.  If you are going to handle PDF files, you *must*
> work with glyph names.
> 
> 
>    Werner