On Dec 31, 2005, at 17:02, Andreas L Delmelle wrote:

(been pondering a bit more over this, and...)

Et voilĂ , that seems to be where the real *flaw* is located, if you ask me. It should care about glues at the beginning of a line -- which it seems to handle perfectly ATM--

In fact, this may currently be handled 'too perfectly'. One of the testcases --block_white-space_2.xml-- fails because a leading non- breaking space is removed, contrary to the expectation.

Don't get me wrong. I still think that it is unnecessary to remove the mentioned trailing white-space for trailing nested inlines in a paragraph in the FOTree.

Only, I think I'm beginning to see what is meant by this paradox:

Besides that, I get the impression you're somewhat contradicting yourself here: - in the comment on the failing testcase you noted that 'These tests fail because the Knuth element sequences for consecutive whitespace are not correct.' - and now you're saying that it's not a matter of generating the correct element sequences

The flaw here is that, IIC, the element sequences generated for nbsp are basically the same as for a common space, leading to the exact same type of area being (or not being) added to the Area Tree (= <space .../>)

Somewhere the decision has to be made: do we or do we not add an area for this box/element? It's precisely there that the algorithm should make the evaluation, taking into consideration the white-space related properties and the underlying character's suppress-at-line- break property.

Would this be a correct assessment?



Reply via email to