[Dev-luatex] luafontloader virtual access (bug #404, #448)

Taco Hoekwater taco at elvenkind.com
Wed Sep 8 07:35:55 CEST 2010


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


More information about the dev-luatex mailing list