Re: Implementation of hyphenation-keep property

On Sep 1, 2006, at 14:45, Jeremias Maerki wrote:

>> <snip />
>> I got the idea while debugging the behavior when processing the
>> disabled testcase 'page-breaking_4.xml'.
>> Notice that the FlowLM's getNextKnuthElements() is currently only
>> called once, which triggers line-breaking for the entire page-
>> sequence given a LayoutContext with ipd equal to that of the first
>> page's region-body. The second page is only prepared after all line-
>> breaks and the first page-break have been computed.
>
> Doesn't sound like total-fit anymore, more like best-fit. Vincent and
> Simon said total-fit for page breaking is very important.

I understand and completely agree, which is why I explicitly looked  
for options that would, by default, come down roughly to the same  
thing we have now, only refined/corrected.

To me it looks like right now we have a total-fit page-breaking,  
combined with a possible non-fit line-breaking. Since line-breaking  
is unaware of available bpd, it cannot take into account any  
overflows in that direction (and implied ipd-changes for the next  
lines).
As you point out, available ipd can only change in case of forced  
breaks/span changes. But even then it seems like we cannot precisely  
determine which page we're on, unless we'd run the PageBreaker over  
the element-list up to that point. That's something I'd like to  
avoid, since this would break the total-fit page-breaking (unless the  
page-breaks are recomputed afterwards...)

If the goal is to achieve a total-fit for both line- and page-breaks,  
and we don't want to waste resources on a whole bunch of unnecessary  
break computations, then it seems like the wisest thing to do first,  
is to try and see if we can move the page-generation in such a way  
that the line-breaking algorithm is always aware of the 'current'  
page, while still no actual page-breaks are computed. The latter can  
still wait until we have collected the full list of line-breaks.

Could get quite tricky, though. Seems like the line-breaking  
algorithm would also need to take into account space-before/-after,  
in order to register correct bp-advancements... bp-advancement is not  
simply line-height, but line-height + resolved space-before +  
resolved space-after. :/

Later,

Andreas