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.

This is excellent news Simon. I was a little concerned when Manuel pointed out these problems and it became clear that the Knuth algorithm could not solve them easily. I've only glanced at your proposal, so can't comment on the details, but anything that gives us a way foward with these whitespace handling problems has got to be good :)

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.

One minor nit: could you rename is-BP to isBorderPadding? The suppress-at-linebreak property is a long self explanatory name, whilst isBP is somewhat cryptic. I initially thought it mean is Block Progression....

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.


Please, let me know what you think of it.

Good work and thanks,


Reply via email to