https://issues.apache.org/bugzilla/show_bug.cgi?id=45097





--- Comment #12 from Sean Griffin <[EMAIL PROTECTED]>  2008-10-26 20:26:01 PST 
---
I've dusted off the investigation of this issue in an effort to possibly fix
it.  I've done some research into the Knuth related concepts and read some old
mailing list entries from Simon and Manuele around 2006 trying to get my head
around the layout manager behavior.  I'm still not sure I have it, but I'll
take a crack at it.

Given markup like this:

<fo:block><fo:inline>aaaaaaaaaaaaaaaaaa 
bbbbbbbbbbbbbbbbbbb</fo:inline></fo:block>

* Note, there are 2 spaces (0x20) between the a and b.

The BreakingAlgorithm is given a KnuthSequence constructed with these elements:

[box w=120096, glue w=0 stretch=10008 shrink=0, aux. penalty p=0 w=0, glue
w=3336 stretch=-10008 shrink=0, box w=126768, penalty p=INFINITE w=0, glue w=0
stretch=216000 shrink=0, penalty p=-INFINITE w=0 (forced break)]

Based on my novice analysis, it appears the various KnuthElements provide the
following purposes:

box w=120096 --> string of 'a' characters
glue w=0 stretch=10008 shrink=0 --> handles alignment in case the following
possible break is honored?
aux. penalty p=0 w=0 --> possible break
glue w=3336 stretch=-10008 shrink=0 --> 1 character of whitespace
box w=126768 --> string of 'b' characters

Now, if I add white-space-collapse="false" and white-space-treatment="preserve"
to the block in the markup above I get this KnuthSequence in the
BreakingAlgorithm:

[box w=120096, glue w=0 stretch=10008 shrink=0, aux. penalty p=0 w=0, glue w=0
stretch=-10008 shrink=0, aux. box w=0, aux. penalty p=INFINITE w=0, glue w=3336
stretch=0 shrink=0, glue w=0 stretch=10008 shrink=0, aux. penalty p=0 w=0, glue
w=0 stretch=-10008 shrink=0, aux. box w=0, aux. penalty p=INFINITE w=0, glue
w=3336 stretch=0 shrink=0, box w=126768, penalty p=INFINITE w=0, glue w=0
stretch=216000 shrink=0, penalty p=-INFINITE w=0 (forced break)]

Which I analyze to provide the following purposes:

box w=120096 --> string of 'a' characters

glue w=0 stretch=10008 shrink=0 --> handles alignment in case the following
possible break is honored?
aux. penalty p=0 w=0 + glue w=0 stretch=-10008 shrink=0--> possible break
aux. box w=0 --> prevents whitespace removal
aux. penalty p=INFINITE w=0 --> disables next glue from being break possibility
glue w=3336 stretch=0 shrink=0 --> 1 character of whitespace on line 1

glue w=0 stretch=10008 shrink=0 --> handles alignment in case the following
possible break is honored?
aux. penalty p=0 w=0 + glue w=0 stretch=-10008 shrink=0--> possible break
aux. box w=0 --> prevents whitespace removal
aux. penalty p=INFINITE w=0 --> disables next glue from being break possibility
glue w=3336 stretch=0 shrink=0 --> 1 character of whitespace on line 2

box w=126768 --> string of 'b' characters

This matches what Andreas shows as the sequence for a preserved space (glue,
penalty=0, glue, aux. box w=0, penalty=inf, glue).  Is my analysis of each
KnuthElement and the purpose it serves correct?  I still don't understand how
it gets the stretch values that it does, but ignoring that for now, it seems
that a possible fix to this undesirable behavior is to move the break
possibility from the beginning to the end of the boilerplate sequence. 
Something like this...

aux. penalty p=INFINITE w=0 --> disables next glue from being break possibility
glue w=3336 stretch=0 shrink=0 --> 1st character of whitespace on line 1
glue w=0 stretch=? shrink=0 --> in case the following possible break is
honored?
aux. penalty p=0 w=0 + glue w=0 stretch=? shrink=0--> possible break

It seems this would move the possible break /after/ the glue with w=3336,
thereby keeping the preserved spaces all on the first line and ensuring the
next line after the break starts at the left margin.

This is complicated stuff, so I apologize if I have it all wrong, but I know
it's just a matter of time before my clients complain about this behavior, and
I'd like to help fix the issue if possible before it blows up.


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