On 06.04.2006 20:50:18 Peter S. Housel wrote:
> > WDYT?
> >From my perspective as a user, I think it's essential to fix the problem 
> with preserving whitespace after a newline (for <pre>-style output) before 
> doing another release.
> -Peter-

Yeah, that's an annoying problem. A quick fix may not be possible,
however. The following patch is simple and does its job for most cases.
It simply makes sure that leading spaces are not ignored anymore by the
line breaker. However, this has a side-effect which breaks a few test
cases, namely:
- inline_block_nested_4
- inline_border_padding_block_nested_1
- inline_border_padding_block_nested_2

These test are about blocks nested in inlines. Here, a linefeed is
converted to a space (by the XMLWhiteSpaceHandler) which ends up as a
leading space on the line right after the nested block. Up to date, this
leading space was suppressed by the Knuth algorithm (leading glues and
penalties are ignored). I think the behaviour after applying the patch
below could actually be correct but may be unexpected from a user
perspective. But linefeed-treatment is on the default ("treat-as-space")
in these test cases.

However, if I set linefeed-treatment to "ignore", the leading space
still remains. Only if I set it to "treat-as-zero-width-space" does the
leading space vanish.

Any insight from the whitespace specialists? I'm not sure about it and
don't want to apply that "quick fix" without a second opinion.

Index: TextLayoutManager.java
--- TextLayoutManager.java      (Revision 391740)
+++ TextLayoutManager.java      (Arbeitskopie)
@@ -539,6 +539,10 @@

                 // create the elements
+                if (sequence.size() == 0) {
+                    sequence.add(new KnuthInlineBox(0, null,
+                            notifyPos(new LeafPosition(this, -1)), true));
+                }
                     (createElementsForASpace(alignment, ai, vecAreaInfo.size() 
- 1));

Jeremias Maerki

Reply via email to