Re: Disabled testcase: block_white-space-collapse_2.xml
On Nov 29, 2005, at 00:27, Manuel Mall wrote: On Tue, 29 Nov 2005 03:21 am, Andreas L Delmelle wrote: Be warned that if you run this test off the trunk, you may receive ugly errors. Not really - if you use fop trunk to produce a PDF from that test it does it without a single error. Only the result is incorrect with repsect to the white-space handling. Good, then it only becomes a matter of tweaking the test to check for the 15 spaces instead of 5. The trailing spaces on line-breaks are indeed not yet removed, apart from those at the end of the block... Thanks for the FB, Andreas
Re: Disabled testcase: block_white-space-collapse_2.xml
On Tue, 29 Nov 2005 03:21 am, Andreas L Delmelle wrote: > On Nov 28, 2005, at 19:56, Andreas L Delmelle wrote: > > > > Hmm... forgot to mention that running this test without an Exception > may require one of my most recent adaptations in the treatment of > fo:characters. AFAICT, remove() came down to changing the character > value to CHAR_EOT, whereas my local version actually removes excess > Characters from the parent's childNodes list, so no LM gets created > for them. Same in the current trunk version. No LM is generated for fo:characters containing the EOT char. > > Be warned that if you run this test off the trunk, you may receive > ugly errors. Not really - if you use fop trunk to produce a PDF from that test it does it without a single error. Only the result is incorrect with repsect to the white-space handling. > > Cheers, > > Andreas Manuel
Re: Disabled testcase: block_white-space-collapse_2.xml
On Tue, 29 Nov 2005 02:56 am, Andreas L Delmelle wrote: > 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... Andreas, you read far too much into the tests. This is simply a copy of block_white-space-collapse_1.xml with white-space-collapse set to false. And the tests are just there to make it fail because FOP does not (yet) handle whitespace around formatter generated linebreaks correctly. The tests don't make any semantic sense! May be the comment above the tests could have been a bit clearer in that respect. > > Cheers, > > Andreas Manuel
Re: Disabled testcase: block_white-space-collapse_2.xml
On Nov 28, 2005, at 19:56, Andreas L Delmelle wrote: Hmm... forgot to mention that running this test without an Exception may require one of my most recent adaptations in the treatment of fo:characters. AFAICT, remove() came down to changing the character value to CHAR_EOT, whereas my local version actually removes excess Characters from the parent's childNodes list, so no LM gets created for them. Be warned that if you run this test off the trunk, you may receive ugly errors. Cheers, Andreas
Disabled testcase: block_white-space-collapse_2.xml
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) spaces 15 spaces(*) before 15 spaces(*) and ... (*) 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: __ __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
