Re: [ft] How to use FreeType with FontConfig?

[Lawrence D'Oliveiro]

On Thu, 19 Feb 2015 17:56:03 +0200, John Found wrote:

> Actually, I already tried your approach and it works pretty good,
> even in this draft implementation: 
> 
> http://fresh.flatassembler.net/fossil/repo/fresh/artifact/9c43c2?ln=21-58

I’m not familiar with the assembler syntax in question, but it looks a
little worrying not to see any error checking.

Have a look at the load_sub_face routine I pointed you to earlier
<https://github.com/ldo/dvdauthor/blob/master/src/subfont.c>. I accept
it can be a little hard to follow with the ifdefs to handle being built
without Fontconfig. I can post the relevant section with those parts
stripped out, if it will help.

> If not, please, give me with some explanation of how this subsystem
> works? I can't understand the general ideas, reading only the API
> reference.

OK, I haven’t actually used the cache mechanism, but based on my
reading of the docs
<http://www.freetype.org/freetype2/docs/reference/ft2-cache_subsystem.html>,
most of it seems pretty straightforward.

First, you have to decide what a FTC_FaceID will point to. That is
interpreted by your own callback routines, not by FreeType. You can
stick to their suggestion of having it point to a structure containing a
pathname string and an integer face_index. The cache manager will
maintain a table of correspondences between these and FT_Face objects,
to avoid repeatedly reloading the latter.

The cache manager can also maintain caches of FT_Glyph objects (the
misleadingly-named “ImageCache”—does that mean the Glyphs are always
BitmapGlyphs?), small bitmaps (the “SBitCache”) and character maps (the
“CMapCache”). These are all kept in their own separate caches hanging
off of the overall FTC_Manager cache; presumably this is to allow you
to maintain multiple caches of these types. I imagine the point of
separate caches is to avoid contention between them, but it’s hard to
see how this would work, since the only options for controlling the
space used apply to the FTC_Manager as a whole.

Notice how all the cache lookup routines reference faces via FTC_FaceID
values, not direct FT_Face objects. This way you don’t have to keep
track of whether you have the relevant FT_Face already loaded or not;
the cache manager will handle that for you.

It looks like the lookup routines automatically take care of generating
objects that are not already in the cache (and, where necessary,
flushing out older objects to make room). Note that the glyph and SBit
lookup routines also optionally return “node” references. You can use
these to selectively lock objects into the cache.

Then there is this whole extra mechanism of “scalers” on top of the
SBit cache--not sure what that’s about, on a quick reading. :)