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=8&rev2=9 Comment: additional details for nested tables ''Reading convention'': - * w("abc") = width of the string "abc" + * ''w("abc")'' = width of the string "abc" - * LM as abbreviation for !LayoutManager + * ''LM'' as abbreviation for !LayoutManager - * PGU as abbreviation for !PrimaryGridUnit + * ''PGU'' as abbreviation for !PrimaryGridUnit + * ''auto table'' as abbreviation a table with table-layout='auto' and a width based on the surrounding container's IPD (e.g., width='50%' instead of width='5cm') + * ''fixed table'' as abbreviation a table with table-layout='fixed' and a width based on the surrounding container's IPD == Simple Tables == === Without Breaks === @@ -94, +96 @@ An example illustrating a complex case can be found in issue [[https://issues.apache.org/jira/browse/FOP-2450|FOP-2450]] (resize-all-but-static-spanned-columns.xml/pdf). === Special Case: requiresSecondRun === - There is a special case for the distribution approach described above (at least in the current implementation of the patch - it may and should be fixed for increased performance). The approach described above extends columns which already have a !MinOptMax instance assigned to them. This is not possible if the very first row of a table contains a table cell spanning multiple rows (see table in this section) - at this point, the necessary data structures are not initialized. Therefore, the current implementation explicitly checks for this case (TableContentLM's iterateOverTableRows(): ''is there PGU which spans multiple columns in the first row?''), skips this PGU, and sets a flag (''requiresSecondDeterminationRun = true;'') informing the table's TableLM to start the determination again (twice the effort for this case!). '''Potential improvement:''' ''instead of revisiting the whole table, simply go back to the first row (if it fulfills the special case) and recalculate this row only before finishing the determination. '' + There is a special case for the distribution approach described above (at least in the current implementation of the patch - it may and should be fixed for increased performance). The approach described above extends columns which already have a !MinOptMax instance assigned to them. This is not possible if the very first row of a table contains a table cell spanning multiple rows (see table in this section) - at this point, the necessary data structures are not initialized. Therefore, the current implementation explicitly checks for this case (TableContentLM's iterateOverTableRows(): ''is there PGU which spans multiple columns in the first row?''), skips this PGU, and sets a flag (''requiresSecondDeterminationRun = true;'') informing the table's TableLM to start the determination again (twice the effort for this case!). + + '''Potential improvement:''' ''instead of revisiting the whole table, simply go back to the first row (if it fulfills the special case) and recalculate this row only before finishing the determination. '' ||||<tablewidth="auto"style="text-align:center">abc abc abc ||a b c || ||a ||b ||c || @@ -115, +119 @@ In this case, FOP has to cope with a column (''b'') for which no !PrimaryGridUnit can be found. Since the width determination of table cells is based on PGUs, no exact determination is possible. In its current implementation, the patch seems to favor such columns over any other column if spanned columns have to be widened, which can lead to imbalanced expansions. == 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. + So far, all scenarios only described the handling of isolated tables. However, since tables may be nested in other tables, FOP also has to cope with fixed tables in auto tables, auto tables in fixed tables and auto tables in auto tables (the fourth combination is already handled correctly). === 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 or requires exactly one table-column unit) and, thus, can determine the optimal widths for the nested table's columns based on the available space. + This case is quite trivial: FOP knows the exact dimensions of the surrounding table cell (which either has a static width or requires one or more table-column units). Thus, the !LayoutContext used to determine the dimensions of the nested table specifies the maximal width (its ''refIPD'') which the contained table is allowed to use. This value is taken for granted, as long as the surrounding fixed table is not contained in another element which itself requires a width determination of its content (i.e., if the fixed table is contained in another auto table in which case the LM’s ''hasAutoLayoutParent()'' would return true). === Fixed Table in Auto Table === If an auto table's table cell contains a fixed table, things get a little bit more 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()): + The surrounding auto table needs to know the min and max widths of its columns, i.e. of each individual table cell. Only then it will 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) + * sum of all static column widths + 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 space will be available. In this case, the minimal required width for the contained auto table is the following (cf. ''getMinimumIPDforAutoLayout()''): - 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 + + During the inspection of the contained table, its LM’s ''hasAutoLayoutParent()'' would return true (since the surrounding table uses table-layout=auto). In this special case, the contained table's !ColumnSetup, which is responsible of computing the optimal column width (cf. ''computeOptimalColumnWidthsForAutoLayout()''), returns the maximal width value of the table to inform the surrounding table of the possible dimensions of the table. Thus, FOP knows both possible width values to find the optimal column widths. + + To inform the contained table about the computed optimal column width, the contained table will later on, during FOP's actual rendering run, be called with a !LayoutContext which knows the final refIPD of the column. ---- = Some Random Ideas = --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
