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=9&rev2=10 This page contains information about the implementation of the "auto table layout" in Apache FOP. = Handling of Tables in FOP-2469 = + As soon as a table with table-layout="auto" is encountered, FOP has to determine the width of each of its columns. Patch 2469 introduces this capability using a preprocessing run (''!AutoLayoutDeterminationMode'') over each such table and its content during FOP's rendering process. + - As soon as a table with table-layout="auto" is encountered, FOP has to determine the width of each of its columns. Each column has a minimal width and a maximal width. It is up to FOP to determine these widths and (if the maximal width cannot be used) to find the optimal width (minimal<=optimal<=maximal). + Each column has a minimal width and a maximal width. It is up to FOP to determine these widths and (if the maximal width cannot be used) to find the optimal width (minimal<=optimal<=maximal). * minimal width: if this width cannot be granted, FOP will most likely encounter an overflow (maximal miminmal width of all contained table 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 - 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. + This process starts in !TableLayoutManager's getNextKnuthElements(), which calls determineAutoLayoutWidths() on its !TableContentLayoutManager if its table uses auto layout (or is nested in another auto layout element). 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 (LMs) for these values. - Currently, most !LayoutManagers (LMs) simply return the corresponding values of their children. Notable exceptions are... + Currently, most LMs simply return the corresponding values of their children. Notable exceptions are... * TableLM (determination depends on whether the table uses a fixed or an automatic layout) * TableCellLM (adds indentations/paddings to the children's values) * TextLM (trivial solution: only determines the length of the longest !KnuthBox - currently, '''break possibilities such as hyphenations are not considered''') * 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) - 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. + 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/recreated during the actual rendering of the table 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. @@ -131, +133 @@ * 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) '' + As max value, !ColumnSetup's ''computeOptimalColumnWidthsForAutoLayout()'' returns the maximal width value of the table to inform the surrounding table of the possible dimensions of the auto table. Thus, FOP knows both possible width values to find the optimal column widths. === 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()''): --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
