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.

Reply via email to