https://issues.apache.org/bugzilla/show_bug.cgi?id=45097
Andreas L. Delmelle <[EMAIL PROTECTED]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #4 from Andreas L. Delmelle <[EMAIL PROTECTED]> 2008-05-29 10:12:40 PST --- (In reply to comment #0) <snip /> Thanks for the extensive report, and the testcases! > To summarize, I see 3 questionable items: > 1. Shouldn't the whitespace_without_wrapping_block.pdf match the > whitespace_with_wrapping_block.pdf? Confirmed. Something is definitely wrong here. > 2. In whitespace_without_wrapping_block.pdf, is the behavior of Example 2 > correct where whitespace is preserved inside inline elements even when > whitespace-treatment != "preserve"? No, this is definitely a bug. The behavior seems to be wrong in both cases. The result should be identical to Example 3, only with additional borders. Example 1 is also incorrect with the wrapping block. The trailing whitespace on the last line should definitely be preserved. Technically: XMLWhiteSpaceHandler does not seem to properly remove the leading/trailing spaces in the inlines due to an implicit start-of-block/end-of-block in Example 2. On the one hand the afterLinefeed member is not correctly set when handleWhiteSpace() is entered the first time for the surrounding block. Easily fixed. On the other hand, the pendingInlines are not processed when handleWhiteSpace() is entered the second time for that block, when the block ends. Slightly more complicated, but still quite straightforward. I'll look into a fix for this soon. For now, the correct behavior in whitespace_without_wrapping_block can be simulated by adding a space character before and after the inline. In that case, white-space removal is properly triggered and you get the correct result. > 3. In whitespace_without_wrapping_block.pdf, is there a way to get Example 1 > behavior and Example 5 behavior with the same block property settings (to > prevent Example 4 behavior)? > Not sure if I'm following here... Can you clarify? Do you wish to override the behavior of the first /and/ the last line? I know the XSL-FO specification defines fo:initial-property-set to affect only the first line-area generated by an fo:block, but FOP does not implement this yet. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.