On Tue, Apr 04, 2006 at 10:15:26PM +0200, Jeremias Maerki wrote:
> I agree with Chris' comment about "isBP". BP could easily be
> misunderstood as "block progression", for example. Furthermore, you talk

I can do that.

> 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

I will add the margin. My boxes can have stretch and shrink, so that
is no problem

> 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

Space resolution occurs before linebreaking. It is one of FOP's
components that building sequences of Knuth elements. It will have to
build a sequence of the new elements, which should not be a problem.

> 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.

As I said above, the two problems should be unrelated. Space
resolution has its own logic, but the outcome is an amount of space
that should be presented to the line breaker. The Knuth element system
provides the elements that can be used, and I expect that my modified
elements are sufficient for letter and word spacing. In fact it would
even be possible to have a single box for a word, its letter spacing
and its following word space (apart from hyphenation).


Simon Pepping
home page: http://www.leverkruid.nl

Reply via email to