Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The "AutoTableLayout" page has been changed by GregorBerg: https://wiki.apache.org/xmlgraphics-fop/AutoTableLayout?action=diff&rev1=6&rev2=7 Comment: initial details about nested tables and explicit TODOs ''Reading convention'': - * w(abc) = width of the string "abc" + * w("abc") = width of the string "abc" * LM as abbreviation for !LayoutManager == Simple Tables == @@ -39, +39 @@ * column 2: since this table cell contains two '''consecutive''' characters, its minimum increases to their width. Again, the maximum width is identical and this column is set to min/opt/max = w(two characters) * column 3: for this table cell, the ''minimum ''value is the width of the widest letter since FOP can insert a linebreak after each individual letter. The ''maximum ''and ''optimal'' value, however, are w("a b c") - After the table was inspected, each column has a !MinOptMax instance representing its viable widths. Since the sum of all max values is less than the available space, the opt value (initialized as ''max'') does not need to be changed. All columns are rendered using their respective opt/max value. + After the table was inspected, each column has a !MinOptMax instance representing its viable widths. Since the sum of all max values is less than the available space, the opt value (initialized as ''max'') does not need to be changed. All columns are rendered using their respective opt/max value === With Breaks === ||<tablewidth="200px">a ||b ||c || @@ -76, +76 @@ ||||<style="text-align:center">abc abc abc ||a b c || - In case a table cell spans several columns, its !MinOptMax determination is different. In the above example, the first cell in.. '''TODO: continue''' + In case a table cell spans several columns, its !MinOptMax determination is different. In the above example, the first row leads to columns with !MinOptMax values of w(a), w(b), and w(c), respectively. In the second row, FOP encounters a cell which has a min of w("abc") and a max of w("abc abc abc"), all of which are greater than the max widths of the spanned columns (=w(a) + w(b) + indentations between these spanned columns). Since the spanned columns are supposed to display the content of the spanning table cell as well, their potential widths need to be adapted. This is done when the corresponding PGU is processed in !TableContentLM's setBaseLength(). - === Requires Second Run === + * calculate sum of the min and max + * TODO: algorithm for expanding columns until their combined width suffices for cells spanning these columns (+ reduction) + + === Special Case: requiresSecondRun === + '''TODO:''' special case if the very first row contains a table cell spanning multiple columns. + ||||<tablewidth="auto"style="text-align:center">abc abc abc ||a b c || ||a ||b ||c || + + '''Potential improvement:''' instead of starting over, simply go back to the first row and recalculate *only this row* before finishing the determination. === Worst Case === In this case, FOP encounters a column for which no !PrimaryGridUnit can be found, except for the one in the first row. This case is ignored in HTML tables - column b is simply ignored... @@ -96, +103 @@ == Nested Tables == So far, all scenarios only described the handling of isolated tables. However, nested tables are also quite common and, depending on their kind, require a specific treatment. + === Auto Table in Fixed Table === + This case is quite trivial: FOP knows the exact dimensions of the surrounding table cell (which either has a static width of is exactly one table-column unit) and, thus, can determine the optimal column widths for the available space. + === Fixed Table in Auto Table === + If an auto table's table cell contains a fixed table, things get a little bit complicated. + + The surrounding auto table needs to know the min and max widths of its columns, i.e. of each individual table cell. Only then will it be able to determine its optimal column width which, in turn, is required to inform the nested table how much space is has available. Luckily, the determination of the minimal the nested table's TableLM can determine the minimal width independently. So, when the nested TableLM's getMinimumIPD() is invoked, it returns the following result as its minimal required width for a complete table (cf. getMinimumIPDforFixedLayout()): + + * sum of all static columns + number of dynamic columns * (highest minimal value of all dynamic columns) + + '''TODO''''': max width via ''getNextKnuthElements ''in !TableCellLM -- table cell demands more space when its childLMs request more space than it allocated for them (#226) '' + === Auto Table in Auto Table === + Again, the surrounding table needs to know the required space for the contained one while the contained table needs to know how much is available. + + In this case, the minimal required width for a complete table with table-layout="auto" is (cf. getMinimumIPDforAutoLayout: ()): + + * sum of each column's minimal width value + ---- = Some Random Ideas = Today, FOP works with the Knuth element model in both inline- and block-progression-directions. For the auto table layout, we can make use of the inline Knuth element lists generated for content in table-cells. Before the line-breaking is done all the elements are gathered. By finding the largest/widest non-breakable sequence in an element list we can determine the minimal width of a column. By determining the full (unbroken) length of each element list involved we know how wide a column would have to be to accomodate the content without breaking it. Ideally, that latter value is used for the column width but if all the columns together would make the table wider than it can be, the column widths have to be reduced, in an extreme situation, down to the minimum established by the former value. I don't want to suggest any details on how to determine what effective width a column should get. The only purpose of the above is to give an idea for an approach to implement auto table layout. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
