|
From: | David Turner |
Subject: | Re: [ft-devel] limiting the heap memory used by a TrueType font |
Date: | Fri, 14 Dec 2007 15:17:13 +0100 |
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
address@hidden
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[Prev in Thread] | Current Thread | [Next in Thread] |