[ft] Slow FT_Get_Next_Char

[[Jongware]]

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.