xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Mall ...@arcus.com.au>
Subject Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/
Date Sat, 31 Dec 2005 07:26:10 GMT
On Sat, 31 Dec 2005 02:41 am, Andreas L Delmelle wrote:
> On Dec 30, 2005, at 16:50, Manuel Mall wrote:
> > On Fri, 30 Dec 2005 11:25 pm, Andreas L Delmelle wrote:
> >> Not really. Just had to draw a line somewhere... If you do it for
> >> the last inline in a block, then you would also have to do it for
> >> the last inline of the last inline of a block etc. Besides, you
> >> get a second pass anyway, when the line is built. All the trailing
> >> space- glyph-areas could be removed there (but they currently
> >> aren't anyway, depending on text-alignment).
> >
> > I am still not sure if this is not a step backwards.  Before the
> > model was: All whitespace handling apart from dealing with
> > whitespace around FOP generated linebreaks is done during the
> > initial refinement.
> >
> > Now this is not really the case any more and the line breaking
> > stuff would have to deal with treating whitespace in other places
> > than around
> > its own generated linebreaks as well. I was hoping we could get rid
> > of the trailing paragraph space removal code in the line breaking
> > algorithm as it is one of those areas causing trouble again and
> > again.
> Trailing spaces in a paragraph: yes, absolutely, which is why the
> trailing whitespace in any block is removed there (albeit only
> whitespace characters that are direct descendants of the block).
> Trailing spaces in a line: now *this* is where currently most of the
> tests fail. Trailing spaces are discarded only when you force text-
> align to justify (for example).
> 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. 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 :-)).

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.

> Cheers,
> Andreas



View raw message