Re: [ft] Slow FT_Get_Next_Char

[Werner LEMBERG]

> >> 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.)

I'm rather collecting broken fonts...  But admittedly, there is no
other font with more than 300000 valid code points.

> 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.

It's not clear to me why you have to completely parse the cmap to
`display' this font.  I'm quite sure that you don't display more than
1000 glyphs at the same time, right?

> 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.

Handling more encodings shouldn't make the program slower.


    Werner