On Sat, Dec 17, 2005 at 11:43:36AM +0800, Manuel Mall wrote:
> It is not a special situation at all. Simply having a   in your 
> text is enough to trigger this regression. And yes, it is an regression 
> caused by the "fix" for the disappearing empty line problem: 
> <fo:block>&#160;</fo:block>
> After some debugging it is obvious to me what is happening. However, it 
> is much less obvious how to fix it. In brief:
> The fix added a zero width Knuth box to the element list created for a 
> nbsp. This was done for two reasons:
> a) to avoid it being removed by the removeElementsForTrailingSpaces() 
> method. That method is wrong in the first place as it knowingly tries 
> to remove non breaking spaces which IMO should never be removed. 

In Knuth's situation spaces were always suppressed at a
linebreak. Therefore suppressing glues around a linebreak is built
into the algorithm. For FO, we need glues that are not suppressed
around a linebreak. Perhaps a boolean member 'suppress-at-line-break'
of KnuthGlue?

> b) However, changing that method to not remove nbsp would give us Knuth 
> paragraphs containing only Glue and Penalty elements. This then causes 
> our implementation of the Knuth algorithm to 'spit the dummy'. Luca, 
> why does our line breaking algorithm insist on having at least one Box 
> in a paragraph? Is that inherent in the Knuth algorithm, i.e. can't it 
> deal with empty paragraphs, that is paragraphs containing only Glue/Pen 
> elements?

The above proposed member would not solve this problem.

The case is contradictory in itself, and quite unique. A nbsp will
never occur at the end of a line by its very definition, except in
this case!


Simon Pepping
home page: http://www.leverkruid.nl

Reply via email to