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> </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 -- Simon Pepping home page: http://www.leverkruid.nl