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=4&rev2=5 Comment: additional details for basics and spanned cells * maximal width: this is the total amount of width the content of any individual table cell requires if it would be rendered without any breaks (maximal width of all contained table cells) * optimal width: this width valueis used during the redistribution of space and, eventually, it is the width which FOP will use to render the column - To determine these values, FOP has to obtain the corresponding widths of the table cells which a column contains. Thus, the !TableCellLayoutManager has to recursively ask all of its contained !LayoutManagers for these values. + This process starts in !TableLayoutManager's getNextKnuthElements() which, if its table uses auto layout (or is nested in another auto layout element) calls determineAutoLayoutWidths() on its !TableContentLayoutManager. In this method, FOP determines !MinOptMax values for each column by obtaining the corresponding widths of the table cells which this column contains. Thus, each !TableCellLayoutManager has to recursively ask all of its contained !LayoutManagers for these values. - Currently, most !LayoutManagers simply return the corresponding values of their children. Notable exceptions are... + Currently, most !LayoutManagers (LMs) simply return the corresponding values of their children. Notable exceptions are... - * !TableLayoutManager (determination depends on whether the table uses a fixed or an automatic layout) + * TableLM (determination depends on whether the table uses a fixed or an automatic layout) - * !TableCellLayoutManager (adds indentations/paddings to the children's values) + * TableCellLM (adds indentations/paddings to the children's values) - * !TextLayoutManager (only determines the length of the longest !KnuthBox - currently, '''hyphenation etc. are not considered''') + * TextLM (trivial solution: only determines the length of the longest !KnuthBox - currently, '''break possibilities such as hyphenations are not considered''') - * !ExternalGraphicLayoutManager (returns the width of the graphic - currently only for !InlineViewports, the only type of figure I encountered - someone should look into the other graphics as well) + * ExternalGraphicLM (returns the width of the graphic - currently only for !InlineViewports, the only type of figure I encountered - someone should look into the other graphics as well) - In the following, simple tables are used as an example to explain the basic algorithm of determining the optimal widths of columns in an ''auto table''. Afterwards, more specific issues such as colspan and nested tables are described. + During this determination, each contained !LayoutManager has to create a list of its knuth elements which, as indicated by Jeremias, can be quite expensive - especially since they are explicitly thrown away afterwards to avoid any sideeffects from the auto-layout preprocessing. The only information left behind are !MinOptMax objects for encountered table columns (saved in the table's TableContentLM which remains intact and is reused) and refIPD values explicitly set for !LayoutContexts. + In the following, simple tables are used as an example to explain the basic algorithm of determining the optimal widths of columns in an ''auto table''. Afterwards, more specific issues such as spanned columns and nested tables are discussed. + + ''Reading convention'': + - Reading convention: w(abc) = width of the string "abc" + * w(abc) = width of the string "abc" + * LM as abbreviation for !LayoutManager == Simple Tables == ==== Without Breaks ==== @@ -31, +36 @@ The first row is checked and the width of each column is set to the width of its first table cell, thus: min/opt/max = w(character). Afterwards, the second row is inspected. * column 1: min/opt/max are identical for the second table-cell and, therefore, the column width remains the same - * column 2: since this table cell contains two '''consecutive''' letters, its minimum increases to their width. Again, the maximum width is identical and this column is set to min/opt/max = w(two letters) + * 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') + * 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. @@ -47, +52 @@ * column 2: since this table cell contains '''consecutive''' characters, its minimum increases to their width. Again, the maximum width is identical and this column is set to min/opt/max = w('abcdefghijklmn') * column 3: for this table cell, the * min ''= ''w(widest character) - * max = w('a b c d') + * max = w("a b c d") - * opt (for now) = w('a b c d') + * opt (for now) = w("a b c d") - Again, each column has a !MinOptMax instance representing its viable widths. In this case, however, the sum of max values is greater than the available space. The available space has to redistributed among the columns (cf. !ColumnSetup::redistribute()). + Again, each column has a !MinOptMax instance representing its viable widths. In this case, however, the sum of max values is greater than the available space. The available space has to redistributed among the columns (cf. !ColumnSetup's redistribute()). - Out of a list of all columns, FOP removes those which cannot be shrinked. At first, FOP excludes any columns containing only consecutive letters (i.e. min == max, in the example the first two columns) and columns which have a static width. Then, the remaining columns are set to math.max(column's min value, column's max value * shrink factor) - thus, they are either shrinked as far as possible or set to their min value. + Out of a list of all columns, FOP removes those which cannot be shrinked. At first, FOP excludes any columns containing only consecutive letters (i.e. min == max, in the example the first two columns) and columns which have a static width. Then, the remaining columns are set to math.max(column's min value, column's max value * shrink factor) - thus, they are either shrinked as far as possible or set to their min value. Opt values are assigned to these columns (iteratively) until the sum of their opt values is <= the available space. - For the example, columns a and b use their max(=min=opt) value, while column c uses its opt value which was shrinked (min = w(character), opt = w(2 characters and a space), max = ('a b c d')). As a result, column c has a linebreak. + In the example, columns a and b use their max(=min=opt) value, while column c uses its opt value which was shrinked (min = w(character), opt = w(2 characters and a space), max = ("a b c d")). As a result, column c is rendered with a linebreak. ==== Not Enough Space ==== In case the sum of all min values is greater than the available space, a warning ('columnsInAutoTableTooWide') is produced. FOP sets all columns to their respective min value and will most probably produce an overflow. - == Cells Spanning Columns == + == Cells Spanning Rows and Columns == - While tables containing table cells employing row-span values are not a problem (please see also [[https://issues.apache.org/jira/browse/FOP-2451|FOP-2451]]), col-span table cells have to be taken into account. The following three cases exist. + While tables containing table cells employing row-span values are not a problem (''please have a look at'' [[https://issues.apache.org/jira/browse/FOP-2451|FOP-2451]] ''for a related patch''), col-span table cells have to be taken into account. + + FOP produces a !PrimaryGridUnit (PGU) for each table cell. If this table cell happens to span y rows and x columns, the corresponding x*y-1 !GridUnits are created to fill the model of the table with placeholders. Since FOP inspects a table from left to right (using a !TableRowIterator) and from top to bottom (using a lot of them), the PGU is always encountered first during the FOP's column width determination. Spanned rows do not have an impact on the column's width since (after the content of the PGU was already processed) they do not carry additional content. For spanned columns, on the other hand, the following three cases exist. ==== Balanced Expansion/Reduction ==== ||<tablewidth="auto">a ||b ||c || ||||<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 + In case a table cell spans several columns, its !MinOptMax determination is different. In the above example, the first cell in.. '''TODO: continue''' ==== Requires Second Run ==== ||||<tablewidth="auto"style="text-align:center">abc abc abc ||a b c || @@ -75, +82 @@ ==== 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... ||||<tablewidth="auto"style="text-align:center">ab (rowspan=2) ||c || ||a ||||<style="text-align:center">bc (rowspan=2) || + + text --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
