Hi, On 09/07/10 22:45, Hans Hagen wrote:
the advantage of the userdata for glyphs and the root tables is that one delays table conversion but eventually one will need much of the data but at least it can be fetched selectively; the userdata keeps the memory footprint low in the sense that less intermediate data is needed
The glyph kerning information is a good example: usually when processing a fontloader font into a metrics table, you need access to all of that data (at least per glyph). Therefore, there is not that much point in totally virtualizing the 'kerns' entry as then each access to it becomes a method call, which will slow down processing considerably, and the end result is likely to use a fair amount of memory anyway. Here is the current format of 'kerns', with punknova.kern.otf as example: <f>.glyphs[65].kerns={ { ["char"]="quotedblright.9", ["lookup"]={ "pp_l_0_g_4", "pp_l_0_g_5", ... 94 more entries ... }, ["off"]=24, }, { ["char"]="quotedblleft.9", ... There is not a lot to be gained from virtualizing this, even though the dump of each of the kerns per-glyhp tables is nearly 2 megabytes. The reason is that you typically need code like this: for _,v in pairs(<f>.glyphs[0].kerns) do local n = v.char local off = v.off for _,l in pairs(v.lookup) do ... end end So you are accessing everything (and likely will even convert it to a temporary table at some point). In punknova.kern, there tend to be 1242 top-level kern array entries, each of which has about a little under a hundred keys. That would be over 100k worth of metatable lookups, and that will definitely be slower than accessing the actual table that is returned at the moment. Best wishes, Taco