[ft] The fastest way to query size of a rendered bitmap

[Daniel Plakhotich]

Hello,

I writing a program that process characters in two passes: first it
queries exact sizes (bounding boxes) of all bitmaps, then, after some
manipulations, the actual rendering is performed. Since there will be
a high amount of characters (probably the whole Unicode range), no
bitmap caching is performed to minimize the memory usage.

Obviously, the step 1 doesn't actually need the bitmaps - only their
sizes, so I want to speed up it as much as possible and reduce the
memory fragmentation. According to the documentation, there are two
options:
  1. Usual FT_Render_Glyph()
  2. Use custom outline processing (FT_Outline_Render(), etc.) via
custom span functions

It seems like the custom span rendering is the best choice, since I
can use a dummy function to get the size, then use a fixed-size buffer
to render each bitmap. I don't want to rely on the undocumented
implementation details of the library and make assumptions about how
FreeType manages memory of the root glyph slot, so this solution looks
better than FT_Render_Glyph().

My question is: which is the fastest way to get size of a rendered
bitmap? Is there a better way except the mentioned two?

As I understand, there is no way to get exact size of a bitmap without
actually rendering it, because of various hinting strategies. But I'm
a bit confused by The FreeType Tutorial (II. Managing Glyphs: 4.
Simple Text Rendering: Kerning and Centering), which says:

> In general, the above function does not compute an exact bounding box of a 
> string! As soon as hinting is involved, glyph dimensions must be derived from 
> the resulting outlines. For anti-aliased pixmaps, FT_Outline_Get_BBox then 
> yields proper results. In case you need 1-bit monochrome bitmaps, it is even 
> necessary to actually render the glyphs because the rules for the conversion 
> from outline to bitmap can also be controlled by hinting instructions.

Why it says the rendering is necessary for 1-bit bitmaps, but not
8-bit? Maybe I missed something?