Taco Hoekwater
David Kastrup wrote:
Taco Hoekwater
writes: Taco Hoekwater wrote:
Hi,
I have just uploaded the archives for a new luatex release, 0.51.0.
New features:
Actually, there is another feature but it is experimental enough that it is not documented in the manual yet.
local <node> nodelist, <sp> founddepth = tex.linebreak(<node> listhead, <table> parameters)
The understood parameters are as follows (with example code):
A few notes: badness/demerits output?
I'll see what can be done about that.
And I think it would be beneficial to have incremental line breaking, where you have as an input (and output) the list of current best breakpoints. That would make it possible to have text flow around shapes without requiring everything to fit a fixed base line distance.
Here I am not sure what you have in mind exactly. Can you create a mock up of the requested input/output?
Not exactly easy. The line break algorithm maintains a list of best active breakpoints in the "current line" under consideration, and each breakpoint is associated with a previous list of breakpoints. (Some sort of shortest path traversal). My first thought was that the "incremental line" breaking would add another line, but that's not actually a useful unit. Perhaps it would be able to do the paragraph breaking until a certain height is certainly exceeded. Then one has the list of possible breakpoints for the current line, each with a score and a list of preceding breakpoints.
I will also say that -- before you spend a lot of time on this -- there are plans for a pure lua version of the whole line break algorithm. We did some experiments with that, and it is not noticeably slower on an average (context) document.
Whether or not one has a C primitive for doing one step of the algorithm is probably not so important then.
You can already re-break the paragraph with the current tex.linebreak: just create a copy of the node list before feeding it in, and loop over the output boxes. tex.linebreak does not remove or reallocate those existing nodes, at most it hides them in discretionaries inside hlists. Probably this is not quite what you had in mind, though.
Fiddle and reiterate might do the trick most of the time, but it feels artificial in contrast to doing it in one pass "as intended" rather than brute-forcing an efficient algorithm iteratively. -- David Kastrup