Very interesting! I will probably need some more time to fully digest
everything, but so far it feels quite good and would certainly simplify
a few things. Thank you for this work. It will be very valuable.
I agree with Chris' comment about "isBP". BP could easily be
misunderstood as "block progression", for example. Furthermore, you talk
about border and padding, but as Manuel notes there's also space (the
margin-kind, not whitespace). Note that spaces have stretch and shrink
while border and padding do not. You don't have any reference to it in
your essay, but I assume that space resolution would still be possible
with the current SpaceResolver. It would simply have to be adjusted to
the new model, right? While I was digging into letter and word spaces I
realized that it will be worthwhile (even necessary) to look at the
FO-specifics for these two properties if any bigger refactoring of the
current inline progression handling is to be done. Both properties
create (potentially conditional) spaces which would all need to be
processed by the space resolver. So, I'm not sure, yet, if we already
have the full picture here. I've got to find some quiet time to reflect
on that some more.
On 03.04.2006 21:38:13 Simon Pepping wrote:
> Some time ago Manuel Mall pointed out a number of problems with
> linebreaking in FOP. Specifically, there are some hard to solve
> problems with suppression of whitespace before a linebreak.
> I propose that the problems can be solved using a generalized set of
> building blocks (a.k.a. Knuth elements):
> 1. Box, with elastic width. A box has two boolean properties:
> 1. suppress-at-linebreak, default value false. According to
> the FO specification, in the default case in an FO text
> it is true for the space character U+0020. The user may
> deviate from the default and set it to false for the
> space character, and to true for other characters.
> 2. is-BP, default value false. This property indicates
> whether a box corresponds to a border and/or a padding
> width. It is true for boxes which are generated by
> padding widths and borders.
> 2. Penalty, with a penalty value and two elastic widths. When the
> penalty element is the chosen linebreak, it contributes the
> first elastic width before the linebreak and the second elastic
> width after the linebreak.
> Penalties are legal breakpoints. Boxes are not.
> On my website I have published a detailed account of my proposal in
> the essay 'Generalized Knuth-Plass Linebreaking Algorithm'. In order
> to test my ideas in practice, I have written a simple implementation
> in Java of this approach.
> See http://www.leverkruid.nl/GKPLinebreaking/index.html.
> Please, let me know what you think of it.
> Regards, Simon
> Simon Pepping
> home page: http://www.leverkruid.nl