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