[Dev-luatex] The hpack_filter callback

Taco Hoekwater taco at elvenkind.com
Tue Apr 29 12:20:26 CEST 2008

Jonathan Sauer wrote:
>> \directlua0{
>>    callback.register('post_linebreak_filter', function(head)
>>       % head is the alternating list of hboxes and glues etc.
>>       for i in node.traverse_id('hlist',head) do
>>            if i.next == nil then % last line has no next
>>               v = node.hpack(i.list,'natural')
> "v" should be local, of course. 

Yes, sure. I was rather sloppy in the lua, I only tried what
worked instead of verifying the actual code.

> The two-parameter form of node.hpack
> is a bit strange (since not explained in the manual). Is above line
> different from "v = node.hpack(i.list)"?

No. In fact, my code was wrong, there is no two-argument call
possible (but in this case, that was silently ignored).

> (Incidentally, the manual also does not note that node.traverse_id
> can take a string as its first parameter.)

Same kind of error here. The code only works because
tonumber("hlist") == 0, and that is the same as the type id
of node type hlist. Coincidence.

>>               print (v.width / 65535)
>>               % next two lines prevent memory leaks
>>               v.list = nil
> I don't quite understand why this is necessary. Since node.hpack
> creates a new node list, why should this list not be freed by
> node.free?

Because it is also still present in the paragraph. If you do
not clear the list item, you will get a double-free error later
on in the best case scenario. In the worst case the nodes have
been reallocated already, and the paragraph contains garbage,
potentially resulting in a crash.

A cleaner solution here would have been to hpack a copy, but
that is a lot less efficient.

>> Using the function above, you can calculate the position within a 
>> paragraph by adding up the various widths and heights and depths.
> Umm ... in the case of a glyph node, I then would access the font
> using font.fonts[glyph.font] and then retrieve the character's
> dimensions from the appropriate table? Since as far as I can see,
> not all nodes store their dimension directly.

Either that, or you can hpack() the line-so-far. But in both cases,
you also have to compensate for the glue setting, so the solution
with \pdfsavepos c.s. is much easier in practice.

Best wishes,

More information about the dev-luatex mailing list