DO NOT REPLY [Bug 28021] New: - Block.handleWhiteSpace() does not replace '/t' characters

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=28021>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28021

Block.handleWhiteSpace() does not replace '/t' characters

           Summary: Block.handleWhiteSpace() does not replace '/t'
                    characters
           Product: Fop
           Version: 1.0dev
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: page-master/layout
        AssignedTo: fop-dev@xml.apache.org
        ReportedBy: lfurini@cs.unibo.it


Hi all.

Another (little) bug concerning whitespace.
According to the XSL Recommendation 7.15.8, if the value of the 
property "white-space-treatment" is "preserve" all white space characters 
(except linefeed) should be converted into spaces; if the value is "ignore-if-
before-linefeed", "ignore-if-after-linefeed" or "ignore-if-surrounding-
linefeed" the recommendation says nothing about what to do with the characters 
which are not discarded, but I suppose they should be converted into spaces.

This replacement is not actually done, so in the pdf output there can be 
some '/t' character, rendered with a sharp (#).

To fix this, it is enough to provide an "else" branch in the two "if" 
statements testing (bWScollapse) and (!bSeenNonWSYet), calling 
charIter.replaceChar('\u0020').
To avoid losing time with replacements of a space with an identical space, 
another "if" is needed, testing whether the current character is already a 
space, but this involves storing the current character in a char variable 
instead of calling charIter.nextChar() in the "switch" statement.

This is not a critical bug, and using XML + XSLT input it is likely that xml's 
white space default treatment avoids these problems, but they could arise 
using FO input files.

Bye
    Luca