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.
Cheers,
Andreas
