On Sun, 18 Dec 2005 08:21 pm, Simon Pepping wrote:
> On Sun, Dec 18, 2005 at 11:10:37AM +0100, Andreas L Delmelle wrote:
> > On Dec 18, 2005, at 06:16, Manuel Mall wrote:
> > >Does it mean because the Knuth algorithm removes all glues after a
> > >linebreak (and we also remove all glues at the end of a paragraph)
> > > a nbsp should not be modelled not like this:
> > >
> > > pen p=INF
> > > glue w=...
> > >
> > >but like this:
> > >
> > > box w=0 aux=true
> > > pen p=INF
> > > glue w=...
> > > box w=0 aux=true
> > >
> > >with the leading box preventing removal at the beginning of a
> > > line, the
> > >trailing box prevents removal at the end of a paragraph, and the
> > >penalty prevents a line break.
> >
> > As far as my understanding of the Knuth algorithm goes, that might
> > be a way to solve it. Even better would be to make the creation of
> > the auxiliary zero-width boxes conditional --depending on whether
> > there are already other boxes surrounding the nbsp (if at all
> > possible). It's really only in the cases where there are no
> > preceding/following boxes that we need special treatment, no? In
> > case of surrounding non- whitespace, the first model would seem to
> > be sufficient.
>
> That is indeed the way to solve it.
>
> The more I think about this, the more complicated it becomes.
>
> Maybe the Knuth algorithm requires that when there are multiple
> characters which are suppressed at linebreak, they are considered
> together, much like we do in space resolution in page breaking. One
> should avoid the situation glue - glue, if the first glue is to be
> suppressed when the second glue is a chosen line break. It should be
> a single glue, or a sequence like glue #1 - penalty - glue #2 - box -
> PENALTY - glue #3 if glue #1 and glue #3, i.e. the glues that remain
> around a line break, are not zero.
>
The simple glue - glue is not a problem as only glue elements directly
following a box are legal break points. But the other scenarios above
are tricky and yes I agree that consecutive whitespace should be
accumulated into a single glue element even if they cross inline
boundaries. Which is an interesting problem in itself especially as
this may involve a change in font(-size) and the individual spaces we
accumulate may have different widths. A particularly interesting
scenario is an inline with a border:
...<fo:inline border="..."> text1 </fo:inline> text2
Here we don't want to break at the space after text1 because that would
push a solitary border to the next line but if we break at the space
before text2 the space after text1 must also be removed (assuming the
default whitespace related property settings). Currently we generate
something like (simplified):
box for text1
glue
box for border
glue
but what is needed is more like:
box for text1
box for border
glue for both spaces
This reorders / merges elements across inline boundaries and makes the
mapping of the Knuth elements back to the inline text fragments for
area tree generation very interesting (or shall we say challenging?).
You are probably aware of my discussions with Luca on this topic
(redesigning the Knuth element generation for paragraphs). Its these
messy situations which so far have eluded my attempts to come up with a
clean solution.
> Simon
Manuel
