On Aug 2, 2007, at 12:13, Vincent Hennebert wrote:

Hi Vincent

Hope you still remember this one. Sorry about the late reply. Still catching up on some missed posts during the holidays.

I’ve been thinking about the handling of keeps and breaks in tables for
a while, and it seems to me that improvements could be done in that
whole area. I’ll use break-before as an example but what I’ll be saying
applies to break-after and keeps as well.

While I've also been looking into that direction myself, I'm not sure I agree with all of your suggestions (more inline below).

Currently, for every object to which the break-before property applies,
the value of the property is checked at the beginning of the
getNextKnuthElements method and, if it corresponds to a hard-break,
a Knuth penalty with -inf value is produced. This has several
- this leads to much code duplication;
- if, say, an fo:block has another fo:block as a child and both have
break-before, two penalties will be generated instead of one (although
  I’m suddenly not so sure of that, more later)
- this makes it difficult to improve breaks to distinguish columns from
  pages, and keeps to take integer values into account.

Very right about the above, and note that this is not only true for block-level breaks and keeps (= page- or column-breaks), but also inline-level, where at the moment, the situation is worse. keep- together.within-line="always" only works for text-descendants of the same FObj. Forcing a keep-with-previous on a graphic or an fo:inline to have it always kept on the same line as the last line generated by preceding PCDATA is currently impossible with FOP.

In fact, we don’t so much care about the penalty element itself as
whether there /should/ be a break between elements or not. I mean, the
LMs which actually care are those which concatenate the elements:
fo:flow, fo:block, fo:block-container, fo:table-cell, etc. And they all
do it the same way:
    iterate over the children LMs
    for each LM:
        if there is a following LM, then:
            if the current LM has break-after or the following LM has
            break-before, then
                generate a Knuth forced break

So the main question is to know whether there is a break before a LM.
And here that’s quite simple, there are only a few shared behaviours:
indeed there is a break-before on an element if:
- the break-before property is set on the element itself or the first of
  its children:
  fo:block, fo:block-container, fo:list-block
- it is set on the element itself or any of its children:
  fo:table-row, fo:list-item
- it is set on the first of its children:
  fo:table-caption, fo:table-cell, fo:list-item-body,
  fo:list-item-label, fo:wrapper
- special:
  - fo:table: on itself or first table-body
- fo:table-body: on the first fo:table-row child if any; otherwise on
    any of fo:table-cell children making the first row
- not applicable:
  fo:table-column, fo:table-header/footer, fo:float, fo:footnote-body

I think I see another way of simplifying the necessary code in the LMs, but I'm not a 100% sure...

Currently, a break is not propagated upwards or normalized in any way in the fo-tree.

If you would have:

  <fo:block break-before="page">
    <fo:block break-before="page">

Then we would get three nested Block instances, and the corresponding BlockLM for the first outer Block always needs to check its first childLM for the break-condition.

OTOH, the above is semantically equivalent to (I think we had already established that there should not be a double page-break here)

<fo:block break-before="page">

If the LMs would be guaranteed to receive the 'normalized' form, the break-condition can be tested for internally by the outer LM itself. No need to look forward or back... The first descendants wouldn't even need to check for breaks anymore.

So there would just be a couple of methods to write, for each behaviour. We could (for the moment) define a dedicated class with static methods,
which would be called by each LM (some methods are imaginary, but you
get the idea):
<snip />

Interesting idea, too, but...

The benefit would be that the whole handling of breaks can be found in
just one place, instead of being spread among all the LMs. This is
easier to correct bugs; this is easier to implement new features (column
vs page break, integer keeps...); this simplifies the
getNextKnuthElements methods of the LMs. And so on...

Agreed with the concerns, but I'm wondering if these portions of code, instead of extracting them into a separate class, could be centralized in, say, BlockStackingLM and InlineStackingLM...?



Reply via email to