Finn Bock wrote:
>Using your description as a jumping point, here is my ideas for page
>breaking. I suppose it is even more pie-in-the-sky since I haven't yet
>written anything about it.
As I have been doing a few experiments about page breaking, I'm happy to
join in this conversation.
>The algorithm that the PageLM uses are a slightly modified knuth (no
>need to maintain fitnessclass, and with the ability to decide on a break
>when there is N pages of lookahead). The elements return from the LMs
>are boxes (for lines), spaces and penalties.
Note that using the box - penalty - glue representation does not
necessarily involve using Knuth's algorithm.
A first-fit (or best-fit) algorithm could be enough in most situations;
and if there are no adjustable elements in the fo document (for exaple,
lots of paragraphs without adjustable spaces between them) Knuth's
algorithm becomes a best-fit.
Given its higher cost, maybe it could be used only when it could really
produce a better output.
>The elements are not
>returned from the LMs but pushed from the LM into the pageLM:
>
> parent.generateElement(new Space(resolveBefore());
> parent.generateElement(new Box(lineHeigth);
>
I'm not sure it is always possible to do this: sometimes the
representation of a block depends on the properties of a higher level
block. For example:
outer block
|
---------
| |
inner inner
block block
1 2
In order to decide whether there can be a page break between the lines
generated by innerBlock1 and innerBlock2, we must know:
- if inner block 1 has keep-with-next
- if inner block 2 has keep-with-previous
- if outer block has keep-together
This can be done if the outer BlockLM calls receives the elements created
by its child, looks at them and adds / removes / corrects; could this be
done if the inner BlockLMs directly give their element to the top-level
LM?
BTW, what about your great refactoring of all the knuth code?
Regards,
Luca
