xmlgraphics-fop-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Xmlgraphics-fop Wiki] Update of "AutoTableLayout" by GregorBerg
Date Thu, 21 May 2015 09:18:19 GMT
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: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org


Mime
View raw message