Sean Griffin <[EMAIL PROTECTED]> changed:

           What    |Removed                     |Added
             Status|ASSIGNED                    |NEEDINFO

--- Comment #5 from Sean Griffin <[EMAIL PROTECTED]>  2008-05-29 11:47:27 PST 
(In reply to comment #4)
> (In reply to comment #0)
> Thanks for the extensive report, and the testcases!

Glad I could help!

> > 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.

Sorry, I probably wasn't very clear. White-space-preserve is set on both
Example 1 and Example 4.  The behavior of Example 1 was expected but the
behavior of Example 4 was *not* first.  The preservation of the
space after each formatter-generated line feed looks funny and I thought it was
a bug.  But after thinking about it and reading the white-space handling
portion of the specification I began to see why it's being done...after all, we
are saying to preserve all white space and I saw no mention in the spec that
formatter-generated line feeds should replace surrounding space characters.  So
I removed white-space-preserve to make Example 4 look like Example 5 (what I
want), but of course that made Example 1 look like Example 3 (what I didn't

Technically this "worked" in FOP 0.20.5, but that's not saying much since it
had other problems related to white-space handling.  Basically, I don't see
anyone wanting the behavior shown in Example 4 (unless they actually put in a
text-indent), so I'm questioning if it's truly working as expected.

To explain a little about what I'm doing, I'm wrapping user-entered text in a
block, and I want to ensure I keep their formatting.  But I appear to be in a
catch-22 because if I do that then I also get this "handing indent" problem for
blocks that have more than 1 line area.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to