Re: Issue 17 in freetype-py: characters inaccessible with face.get_next_char
freet...@googlecode.com
Status: Started
Comment #1 on issue 17 by Nicolas.Rougier: characters inaccessible with
face.get_next_char
http://code.google.com/p/freetype-py/issues/detail?id=17
I get same output.
I will check with C freetype API to check if I get same result.
freet...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 17 by yarosla...@gmail.com: characters inaccessible with
face.get_next_char
http://code.google.com/p/freetype-py/issues/detail?id=17
In the font attached, there's a black-down arrow character which can be
accessed with face.load_glyph(2), but not possible by iterating with
get_next_char
In [65]: face=Face('zapf.cff')
In [66]: face.num_glyphs
Out[66]: 3
In [67]: face.get_first_char()
Out[67]: (32, 1L)
In [68]: face.get_next_char(32,1L)
Out[68]: (160, 1L)
In [69]: face.get_next_char(160,1L)
Out[69]: (0, 0L)
Attachments:
zapf.cff 329 bytes
freet...@googlecode.com
Comment #2 on issue 17 by Nicolas.Rougier: characters inaccessible with
face.get_next_char
http://code.google.com/p/freetype-py/issues/detail?id=17
Ok, with the following code:
#include <stdio.h>
#include <ft2build.h>
#include FT_FREETYPE_H
int main(int argc, char **argv)
{
FT_Face face;
FT_UInt gindex;
FT_ULong charcode;
FT_Library library;
FT_Init_FreeType( &library );
FT_New_Face( library, "./zapf.cff", 0, &face );
fprintf( stderr, "Num glyphs: %ld\n", face->num_glyphs );
charcode = FT_Get_First_Char( face, &gindex );
while ( gindex != 0 )
{
fprintf( stderr, "char: %ld (index = %d)\n", charcode, gindex );
charcode = FT_Get_Next_Char( face, charcode, &gindex );
};
FT_Done_Face( face );
FT_Done_FreeType( library );
}
I get following output:
Num glyphs: 3
char: 32 (index = 1)
char: 160 (index = 1)
which is quite consistent with your test.
I will ask on the freetype mailing list.
freet...@googlecode.com
Status: WontFix
Comment #3 on issue 17 by Nicolas.Rougier: characters inaccessible with
face.get_next_char
http://code.google.com/p/freetype-py/issues/detail?id=17
Here is the answer from Werner Lemberg:
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.
If I understand things well, we have to wait for a bug fix in FreeType and
I cannot fix it right now in freetype-py.
Nicolas
freet...@googlecode.com
Comment #4 on issue 17 by yarosla...@gmail.com: characters inaccessible
with face.get_next_char
http://code.google.com/p/freetype-py/issues/detail?id=17
I see, thanks for the info
Is there support in freetype-py to work with glyph names?
IE, to get list of all names in the font, and retrieve glyph by name?
freet...@googlecode.com
Comment #5 on issue 17 by Nicolas.Rougier: characters inaccessible with
face.get_next_char
http://code.google.com/p/freetype-py/issues/detail?id=17
I'm not sure in fact. If you know how to do it with free type then it
should be possible to do it with freetype-py.
freet...@googlecode.com
Comment #6 on issue 17 by Nicolas.Rougier: characters inaccessible with
face.get_next_char
http://code.google.com/p/freetype-py/issues/detail?id=17
Bug has been fixed in freetype.
Should work now with free type-py.