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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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
