[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ft] Slow FT_Get_Next_Char
From: |
[Jongware] |
Subject: |
[ft] Slow FT_Get_Next_Char |
Date: |
Sun, 7 Dec 2008 05:09:58 -0800 (PST) |
FT is *extremely slow* with FT_Get_Next_Char for the font "lastresort.ttf".
For those who do not know the font, it is a 'catch-all', with some 6207
glyphs displaying main Unicode block IDs. The number of glyphs is not
important; the number of Unicode points in the cmap is. The font defines a
glyph for every code point between 00000 and 10FFFF -- that's right, some
400,000 codes!
The encoding is defined in cmap as Segmented coverage, although it doesn't
seem to use 'segmenting' very efficiently: virtually every single code point
has a segment of its own. I gather it is because it is a many-to-one mapping
-- lots of successive code points map to the same glyph, and the segmenting
assumes consecutive code points for *consecutive glyphs*.
It appears FreeType doesn't like this at all!
Is this a bug, implementation defined, or is it something that could be
improved?
--
View this message in context:
http://www.nabble.com/Slow-FT_Get_Next_Char-tp20880907p20880907.html
Sent from the Freetype - User mailing list archive at Nabble.com.
- [ft] Slow FT_Get_Next_Char,
[Jongware] <=