Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification. The following page has been changed by VincentHennebert: http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnownProblems The comment on the change is: Documenting a problem with the merging algorithm for tables New page: At the end of TableLayout/KnuthElementsForTables there is a notice about inaccurate steps when the table is broken over more than 2 pages. In this document another flaw is described which does not involve penalties at all. = Sample FO File = We will take the following FO file as an example: {{{ Before the table Cell 1 Line 1 Cell 1 Line 2 Cell 1 Line 3 Cell 1 Line 4 Cell 1 Line 5 Cell 1 Line 6 Cell 1 Line 7 Cell 1 Line 8 Cell 1 Line 9 Cell 1 Line 10 Cell 1 Line 11 Cell 1 Line 12 Cell 2 Line 1 Cell 2 Line 2 Cell 2 Line 3 Cell 2 Line 4 Cell 2 Line 5 Cell 2 Line 6 Cell 2 Line 7 Cell 2 Line 8 Cell 2 Line 9 Cell 2 Line 10 Cell 2 Line 11 Cell 2 Line 12 Cell 2 Line 13 Cell 2 Line 14 Cell 2 Line 15 After the table }}} The [http://people.apache.org/~vhennebert/wiki/TableLayout/KnownProblems/mergeAlgoPb.pdf resulting pdf] is interesting to see as well. Colours are used to illustrate unbreakable blocks of text. On the second page the line 9 of the first cell is laying inside the margin, and lines 10 and 11 are outside the page. The list of Knuth elements for each column is as follows (the unit is a line): {{{ box(2) box(2) penalty(0) penalty(0) box(4) box(3) penalty(0) penalty(0) box(2) box(3) penalty(0) penalty(0) box(3) box(3) penalty(0) penalty(0) box(1) box(4) penalty(0) penalty(0) }}} The merging algorithm gives the following sequence: {{{ box(2) penalty(0) box(3) penalty(0) <-- box(0) penalty(1) box(3) penalty(0) box(3) penalty(0) <-- box(0) penalty(1) box(4) penalty(0) }}} The two chosen breakpoints are marked with arrows. What’s going on? Let’s use some pictures to ease the explanations. = Illustrating the Process = We will use the following graphical notation to represent chunks of text: http://people.apache.org/~vhennebert/wiki/TableLayout/KnownProblems/notations.png According to that notation we have the following graphics for the two columns of the table and the Knuth sequence that results from the merge: http://people.apache.org/~vhennebert/wiki/TableLayout/KnownProblems/mergedKnuthSequence.png The merging algorithm works well when the table is broken over only 2 pages. In such a case, each time a break is considered, the reasoning is done in terms of what can be put on the current page and what will be left over to the next page. And this reasoning is the same for ''every'' break in the table. So in our case, the first chosen break corresponds to the following expected situation: http://people.apache.org/~vhennebert/wiki/TableLayout/KnownProblems/firstBreak.png whereas the second chosen break corresponds to the following: http://people.apache.org/~vhennebert/wiki/TableLayout/KnownProblems/secondBreak.png But the actual situation does not correspond to the expected one, since the second break is chosen to break the table ''a second time'', and not for the first time like is ‘coded’ in the merged Knuth sequence. So at the chosen breakpoint, the algorithm believes that all the blocks but the last can fit on the page. That gives the following result: http://people.apache.org/~vhennebert/wiki/TableLayout/KnownProblems/result.png What’s worrying here is that the algorithm really believes that everything is normal, and won’t even complain about some content overflowing the page. That can lead to lost text without the user being warned. This is all the more frustrating than a much more desirable result is perfectly achievable: http://people.apache.org/~vhennebert/wiki/TableLayout/KnownProblems/desirableResult.png --------------------------------------------------------------------- To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org