Re: [ft] Slow FT_Get_Next_Char

[[Jongware]]

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.