On Wed, 4 Jan 2006 03:51 am, Andreas L Delmelle wrote:
> On Jan 2, 2006, at 06:27, Manuel Mall wrote:
> > On Mon, 2 Jan 2006 12:56 am, Andreas L Delmelle wrote:
> >> Would it not be a much easier and much
> >> more straightforward solution to have every paragraph end with an
> >> infinitely low penalty, so that the algorithm eventually treats
> >> trailing spaces in the last line-area just the same as it would
> >> for 'normal' line-breaks?
> >
> > No, leading and trailing paragraph spaces must be removed BEFORE
> > linebreaking, that is before we get into the Knuth stuff otherwise
> > they
> > may be incorrectly considered as part of the linebreaking line
> > length and adjustment calculations. Therefore when this was done
> > during refinement at the block level it was just the right place
> > IMO. Obviously spaces around formatter generated linebreaks must be
> > dealt with during linebreaking.
>
> Hmm... Yes, yes. We are growing closer. I think I like you. Well,
> actually, I'm growing a bit tired of this debate, but that's a Very
> Good Sign, if you catch the drift. :-)
>
> To sum it up:
> Our implementation of Donald Knuth's algorithm first creates the
> element lists for the FOs, and then from those lists it calculates
> the most favorable break-positions. Subsequently, it adds the areas
> based on those breaks to the block-area, right?
> Now, what I mean:
> If the element-lists for the trailing spaces(*) are modeled
> appropriately, and we add a forced break (infinite penalty) for the
> end-of-block, then the algorithm will always create one final pseudo-
> line-break(**) where those spaces are dissolved if present, just as
> they would be when it were the first line. The generated pseudo-line
> (s) will have no content at all. Maybe a minor tweak needed in
> LineArea to return zero BPD when it has no child-areas, and there we
> go... In Block.addChildArea, we can then test for zero-BPD line-areas
> to keep them from effectively being added to the block.
>
> Something like that? Or am I still missing important implications?
>

The point you are missing is that the Knuth algorithm only deletes 
leading spaces in a line because it always breaks at the first of a 
sequence of spaces. Therefore adding an infinite penalty at the end of 
the paragraph doesn't achieve anything with respect to space removal. 
And BTW we do add an infinite penalty at the end of a paragraph 
already.

> (*) this made me wonder BTW in how many percent of the cases an
> fo:inline with a trailing space would actually end an fo:block.
> Anyone care to make an educated guess?
>
> (**) more than one in the very exceptional case where the trailing
> spaces would cause a line-break themselves, i.e. if there is just
> enough IPD left for one space, and we have more than one... but that
> would mean nested-nested-...-nested trailing fo:inlines, or one
> fo:inline with lots of non-collapsed spaces.
>

Not sure if this consideration is relevant.

> <snip />
>
> > That is not the point at all. The previous algorithm was defective
> > in the sense of not dealing with whitespace around markers and
> > possibly other fo's with text content.
>
> OK, so it is an improvement after all.
> Phew, <wipes forehead />, I almost thought I had become utterly
> useless... :-)
>
> > The task at hand was to extend the whitespace handling to other
> > fo's which were previously omitted, e.g. markers. Your change does
> > that however, it does not preserve the existing functionality.
> > Therefore its
> > progress in one sense and regression in another. What I am asking
> > you to do is to look for a solution were we don't have any
> > regressions and still get the whitespace handling applied to other
> > fos.
>
> See my above description: it can be done with much less effort IIC,
> both efficiency- and code-wise, if this particular step is left to
> the layout algorithm.

That's were we disagree - we had a simple working solution before your 
patch - I like to have that back. Putting it into layout is a non 
trivial exercise because it requires "cross fo/lm border" processing. 
This is something layout currently doesn't do but the whitespace 
routine at fo level before your patch did do. That's why I like it so 
much :-).

>
> BTW: there is another gap that isn't completely covered by my
> alterations. Markers are always white-space-treated as inlines, which
> would lead to incorrect results if a marker is retrieved in a context
> like
>
> <fo:block><fo:retrieve-marker .../></fo:block>
>
> As I see it, this means that something like what I described above
> will need to be considered for this case as well. If the marker is
> retrieved as a child of an fo:inline, the currently produced result
> will be correct.
>
> Since authors are allowed to have static-contents that retrieve the
> same marker twice, once as child of a block and another as a child of
> an inline, we can't possibly decide at FOTree stage if these spaces
> may be removed.
>

This is a very interesting point you are making here. I need to look 
into that a bit more.

> > BTW, if you had mentioned the regression in your patch description
> > I would have raised my objections at that time. You only mentioned
> > it after you applied the patch.
>
> True enough, I hadn't considered that. No harm intended and none
> taken, I hope...

Of course not.

>
> Anyway, up to here, this has yet again been a very stimulating
> discussion. Thanks for insisting on my reconsidering and rephrasing
> of ideas. At the start, I only *sensed* it was possible and desirable
> to move this to layout. Now I'm certain that it is not only possible,
> but also mandatory to do so, if we want to cover virtually all cases.
>
>
> Cheers,
>
> Andreas

Regards

Manuel

Reply via email to