Simon Pepping wrote:
Hello,
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.
See http://www.leverkruid.nl/GKPLinebreaking/index.html.
Please, let me know what you think of it.
Good work and thanks,
Chris
