TrueType fonts contain several tables that vary in a linear way with the size of the font. Some of these, for example hmtx (horizontal metrics) are not loaded into the heap, but are accessed using the stream interface. Others, like cmap (which maps character codes to glyph indexes) and loca (which maps glyph indexes to glyph data) are loaded in their entirety into the heap.
The fact that some of these tables are loaded into the heap means that for devices with a small amount of RAM there is always a font big enough to cause an out-of-memory error; the amount of heap used is O(N) where N is the number of glyphs. The font itself can be kept 'somewhere else' - in ROM, for instance - so the size of the font data itself is not at issue. On small devices RAM is typically in much shorter supply than ROM. An ideal solution to the problem is to make it a configurable option for all tables to be accessed via the stream interface and not loaded into the heap. I have already experimentally done this for the cmap table and it works perfectly, saving over 80K when loading a Japanese font. The technique is this: 1. Allow the cmap table to be loaded as normal. 2. Note its location in the file, and any other information needed to access it. 3. Unload the cmap table from the heap. 4. Replace FT_Get_Char_Index with a new function that reads the cmap via a stream interface. For the 'loca' table the only good way to prevent it from being loaded is to unload it then override the normal way of getting glyph data, using the incremental interface; however, it would be much nicer if there was a compile-time or perhaps run-time option that forced stream access to all variable-sized tables. I have had time to do this only with rather platform-specific code which unfortunately I can't show here because it is proprietary, but I just wanted to give my opinion that this would be a useful new feature for FreeType. I shall very probably not have time to do it myself, but someone more familiar with FreeType internals might be able to code it up very quickly in a way that fitted in with the existing architecture. Best regards, Graham Asher _______________________________________________ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
