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. :) _______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
