Werner LEMBERG wrote: > >> This font must be useful in stress-testing FreeType -- it is a real >> border case of what *should* be possible. > > I consider it as nothing special. :-)
You must be used to weird fonts... (Do you have other examples of this class of unusual ones, with mapping trickery? That might help me find a (better) way to cope with'em. Borderline cases preferred.) Werner LEMBERG wrote: > >>[..] how can I foresee >> this for any given font? > > Foresee what exactly? The unusually long preprocessing time. So far, my routine that does the preprocessing is not multi-threaded in any way. The proggie loads a font file, goes over the encoding extracting useful stuff, and displays the font. It's fast enough for live font folder browsing -- hit Page Down and see the next font. This one font mucks it up! And I was inordinately proud of it so far. Oh well, I've already written a console program to 'manually' parse cmaps (not using any FT), so I can use this, falling back to FT's way only if I cannot find the cmap. That should do, since so far I'm only interested in glyphs and glyph-to-unicode -- I didn't delve into FT to find side effects (i.e., additional advantages) of using FT_Get_Next_Char. I'm guessing FT has to consider all kinds of encoding, and thus may take a longer route, whereas I only read the MS/Unicode table. In this case, the needs (= requirements) of the many clearly go before the needs of the one :-) Case closed as far as I'm concerned, with thanks for the prompted round of introspection. -- View this message in context: http://www.nabble.com/Slow-FT_Get_Next_Char-tp20880907p20923571.html Sent from the Freetype - User mailing list archive at Nabble.com. _______________________________________________ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
