--- Comment #16 from Vincent Hennebert <>  2009-06-02 
02:49:14 PST ---
(In reply to comment #15)
> (In reply to comment #12)
> > Still two hyphenation testcases to look at...
> Spent quite some time today trying to figure out what was causing those to
> fail. Turned out to have nothing to do with the patch, but with other 
> unrelated
> changes I had made locally... :/
> I have addressed the change mentioned in comment #10 by adding a check for a
> break-class of -1 to the condition, so such penalties are no more considered 
> as
> a legal break.
> Now that all tests pass, all that's left is to start some improvements and add
> the testcases. For the moment, the improvements can be kept down to a minimum,
> since with some minor modifications, it seems to be working nicely already. 
> The
> only case that is still not correctly processed is the one mentioned in the
> beginning (see description mentioned by Vincent): if we have a block with
> keep-together.within-column="5" and a nested block with
> keep-together.within-page="10", the inner block is still split over multiple
> pages. Maybe, this situation is solvable by adding 'hinting' penalties (with
> negative values) before the inner block, which would make a page-break before
> or after better than a break inside that block. Remains to be seen whether 
> this
> will work as expected, as I remember a test Luca Furini did once, where he
> demonstrated that the effect of the penalties' values is marginal on the total
> demerits, unless the difference is big enough (?)

This won't work. If keep-together.within-column="1" and
keep-together.within-page="always" then a break must be completely forbidden at
a page. Hinting penalties won't prevent that in every case, for example if the
only feasible page break is at such a place. In that situation the node
recovery mechanism must be launched, and an earlier too-short/long node


Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to