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 Mon, 25 May 2015 20:05:00 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=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: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org


Mime
View raw message