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.
