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. _______________________________________________ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
