On Dec 31, 2005, at 08:26, Manuel Mall wrote:
On Sat, 31 Dec 2005 02:41 am, Andreas L Delmelle wrote:
Point is: if trailing spaces in a line are correctly suppressed
during line-building, the trailing spaces in the last inline of a
given block would be removed in that step (no matter at what depth
the inline is nested).
the problem is that the Knuth algorithm doesn't deal with spaces
(glue)
at the end or beginning of a paragraph. It only discards space (glue)
when the algorithm creates a line break.
Not always: see block_white-space-collapse_2.xml
The reason why it fails is that the trailing spaces at the end of the
first line aren't discarded. Specifying text-align="justify" makes
the algorithm throw away the trailing spaces (maybe "end" or "right"
too, haven't checked that yet)
It is (messy?) FOP custom code outside the core Knuth algorithm
which deals with removing glue at the
beginning and end of a paragraph. This should IMO therefore dealt with
during refinement. I assume (haven't checked) that your whitespace
handling does remove all leading whitespace in a paragraph and
therefore it would make sense if it also removes all trailing
whitespace (nice symmetry :-)).
Yeah, it would be a very nice symmetry :-)
Well, it's definitely not impossible, but I'm wondering a bit about
Cost vs. Benefit. Currently, when the trailing spaces for any inline
are treated --in Inline.endOfNode()-- one has no way of knowing
whether any text will still follow --possible subsequent nested
inlines, text or characters will not be available yet.
In theory, we could keep a reference alive to the last FOText of the
previous inline, so that when it appears at the end of the block, we
could strip its trailing white-space too.
OTOH, if the white-space suppression in layout is made to work
properly in all cases, those trailing spaces should automatically be
removed since they are trailing in a line (whether it is the last
line in the paragraph or not shouldn't make any difference).
So, I held off FTM on trying to remove these spaces during
refinement, and wanted to see if this problem doesn't get solved by
tweaking the white-space removal during line-building.
Note that the point is that we don't need any special code to discard
whitespace around Knuth generated linebreaks as the algorithm does
that
for us (actually we need special code to prevent discards for certain
linefeed-treatment values but that is more of a matter of generating
Knuth sequences which allow breaks but don't discard and does not
require a change to the algorithms). Therefore the only special
case is
the beginning and end of a paragraph. As the beginning is handled by
whitespace handling at the FO level the end bit should be as well.
Apart from the aesthetic argument (nice symmetry): why exactly?
Again, IMO, if the right element-sequences are generated for these
white-spaces, they should be suppressed at the end of the paragraph
anyway (forced EOL).
In the end, it's all the same to me, I guess...
Cheers,
Andreas
