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?

(*) 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.

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

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.

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

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.



Reply via email to