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

BTW, what about your great refactoring of all the knuth code?


Reply via email to