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=3&rev2=4 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. - Currently, most !LayoutManagers simply return the corresponding values of their children. Notable exceptions are + Currently, most !LayoutManagers simply return the corresponding values of their children. Notable exceptions are... - * !TableLayoutManager + * !TableLayoutManager (determination depends on whether the table uses a fixed or an automatic layout) - * !TableCellLayoutManager (adds indentations/paddings) + * !TableCellLayoutManager (adds indentations/paddings to the children's values) * !TextLayoutManager (only determines the length of the longest !KnuthBox - currently, '''hyphenation etc. 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) 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. @@ -58, +59 @@ ==== 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. - == Merged Cells == + == Cells Spanning 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. ==== 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 ==== Requires Second Run ==== ||||<tablewidth="auto"style="text-align:center">abc abc abc ||a b c || @@ -83, +86 @@ ==== Fixed Table in Auto Table ==== ==== Auto Table in Auto Table ==== - ---- = 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]
