Hi all,

I guess this one is for Manuel, since the above mentioned testcase was submitted by him, but if anyone can offer further feedback (or confirm/refute my suspicions :-)), feel free to share your thoughts...


Most importantly, I was having a bit of difficulty in seeing where the 8 comes from in the first test. While running this test, the nearest I got, there was only room for five of the nine words in the first block.

The expected end-result, if I count correctly, should be (for the first block)

<word>spaces</word>
15 spaces(*)
<word>before</word>
15 spaces(*)
<word>and</word>
...

(*) Strictly speaking, if you follow the XSL-FO 1.0 Rec's definition of white-space-treatment, this should be 13, since the two spaces surrounding the non-treated linefeed should be dropped... Our current algorithm seems more in line with the 1.1 definition, which refers to line-breaks, so those spaces should only be dropped iff the linefeed is preserved. This was already the case before I started modifying it.

Anyway, if you have 15 spaces between each word, there is no way you can fit 8 words on 5 inches IIC (not counting possible merging/ shrinking of space-sequences).

This also influences the second test: 8 words would mean at least 105 spaces should appear in the first line. The test seems to be counting on 5 spaces in between each word, the error being that:

<fo:block white-space-collapse="false">__
__word1___
__word2___
...

(underscores for spaces)

indeed would produce 5 spaces between word1 and word2, but if this block is nested and indented, then *all* white-space characters count (= MUST be reported by an XML 1.0 compliant parser), hence why I believe this should be 15 in our testcase.

Apart from that, maybe it would make more sense to restrict the tests here to the counting of space glyph-areas between the words (= check the number of space characters which survived handleWhiteSpace()).


Make sense?

Cheers,

Andreas

Reply via email to