Re: Open issue: table-columns from first row?
On Jan 3, 2007, at 10:17, Vincent Hennebert wrote: Hi Vincent, ... In this case, two implicit columns are created, but the cell's width is not yet distributed over the two columns. I'll add a testcase demonstrating what still goes wrong, but the issue probably needs to put in a slightly different wording, indicating that it works apart from the above reservation. I'm curious about your testcase, actually, because after quick testing I haven't been able to reproduce it (attached fo file, first table, works fine). I see two possibilities: Either the layoutengine fully compensates for this, or it just happens to go unnoticed since you have a specified absolute width of 7.5cm for the whole table. I think I'll put my money on the latter. Explanation: By the time layout starts, we'll actually have three table-columns, all with a default width of 'proportional-column-width(1)' (= FOP's proprietary default, as this is not mandated by the XSL-FO Rec; the Rec says the initial value is 'auto' which comes down to the same thing). Try setting the table's width to 10cm. If all would go as expected, we'd have to end up with two columns of 2.5cm and one of 5cm. FOP currently makes them all about 3.33cm, I think... In the meantime, I've locally patched FOP to correctly deal with this. Patch consists of a few changes in TableBody, TableRow and PercentLength. The latter only because I needed to have some way to be able to get the percentage value of the cell-width, divide it by the number of columns spanned, and construct a new PercentLength with the percentage distributed over the number of columns. Full patch below. No objection, some code was obviously lacking at that place, anyway (nothing done when colspan != 1). For absolute widths, it is not so much of a hassle to distribute the widths. When it came to the percentages, however, I began to slow down... It seems a pesky job to create correct relative-numerics: the percentages themselves are actually rather simple --percentage value of the original cell divided by the column-span. It's creating the LengthBase to go with it that I'm still struggling with (a percentage of what?) Not unsolvable, but a bit more work than that tiny patch I proposed at first. That made me think of the testcase showed in the second table in the attached file. There is a colspan on the first row, which sets the width of the first two columns. But we might want to refine that on the second row, by specifying a different width for each column individually. That testcase fails... WDYT? Interesting idea, BUT... One of the key intentions of the fixed table-layout algorithm is precisely that a formatter is able to determine the column-widths for the whole table based on the first row. Strictly speaking, the behaviour you describe --to take into account the second row as well-- would even violate the rules prescribed by CSS. In 17.5.2, it says: "In the fixed table layout algorithm, the width of each column is determined as follows: 1) A column element with a value other than 'auto' for the 'width' property sets the width for that column. 2) Otherwise, a cell in the first row with a value other than 'auto' for the 'width' property sets the width for that column. If the cell spans more than one column, the width is divided over the columns. 3) Any remaining columns equally divide the remaining horizontal table space (minus borders or cell spacing)." In your example, I'd say that following the Rec means ignoring any width attributes on cells that are not in the first row. The widths in the second row are not supposed to have any effect. Cheers, Andreas
Re: Open issue: table-columns from first row?
Hi Andreas, Andreas L Delmelle a écrit : > On Dec 24, 2006, at 09:53, Andreas L Delmelle wrote: > > >> Just had another look, and it currently only works correctly in case >> there is no column-spanning going on in any of the cells in the first >> row. >> >> >> >> >> ... >> >> In this case, two implicit columns are created, but the cell's width >> is not yet distributed over the two columns. >> >> I'll add a testcase demonstrating what still goes wrong, but the issue >> probably needs to put in a slightly different wording, indicating that >> it works apart from the above reservation. I'm curious about your testcase, actually, because after quick testing I haven't been able to reproduce it (attached fo file, first table, works fine). > In the meantime, I've locally patched FOP to correctly deal with this. > > Patch consists of a few changes in TableBody, TableRow and > PercentLength. The latter only because I needed to have some way to be > able to get the percentage value of the cell-width, divide it by the > number of columns spanned, and construct a new PercentLength with the > percentage distributed over the number of columns. > > Full patch below. No objection, some code was obviously lacking at that place, anyway (nothing done when colspan != 1). That made me think of the testcase showed in the second table in the attached file. There is a colspan on the first row, which sets the width of the first two columns. But we might want to refine that on the second row, by specifying a different width for each column individually. That testcase fails... WDYT? Vincent http://www.w3.org/1999/XSL/Format";> Cell 1 Cell 2 Cell 3 Cell 4 Cell 5 Cell 1 Cell 2 Cell 3 Cell 4 Cell 5
Re: Open issue: table-columns from first row?
On Dec 24, 2006, at 09:53, Andreas L Delmelle wrote:
Just had another look, and it currently only works correctly in
case there is no column-spanning going on in any of the cells in
the first row.
...
In this case, two implicit columns are created, but the cell's
width is not yet distributed over the two columns.
I'll add a testcase demonstrating what still goes wrong, but the
issue probably needs to put in a slightly different wording,
indicating that it works apart from the above reservation.
In the meantime, I've locally patched FOP to correctly deal with this.
Patch consists of a few changes in TableBody, TableRow and
PercentLength. The latter only because I needed to have some way to
be able to get the percentage value of the cell-width, divide it by
the number of columns spanned, and construct a new PercentLength with
the percentage distributed over the number of columns.
Full patch below.
If no one objects, I'll commit this to the trunk and the release
branch, so this issue is out of the way.
Cheers,
Andreas
Index: src/java/org/apache/fop/fo/flow/TableBody.java
===
--- src/java/org/apache/fop/fo/flow/TableBody.java (revision
489884)
+++ src/java/org/apache/fop/fo/flow/TableBody.java (working copy)
@@ -40,6 +40,9 @@
import org.apache.fop.fo.properties.CommonAural;
import org.apache.fop.fo.properties.CommonBorderPaddingBackground;
import org.apache.fop.fo.properties.CommonRelativePosition;
+import org.apache.fop.fo.properties.FixedLength;
+import org.apache.fop.fo.properties.LengthProperty;
+import org.apache.fop.fo.properties.PercentLength;
/**
* Class modelling the fo:table-body object.
@@ -80,7 +83,7 @@
/**
* @see FObj#bind(PropertyList)
*/
-public void bind(PropertyList pList) throws FOPException {
+protected void bind(PropertyList pList) throws FOPException {
commonBorderPaddingBackground =
pList.getBorderPaddingBackgroundProps();
super.bind(pList);
//Used by convertCellsToRows()
@@ -201,9 +204,16 @@
int colSpan = cell.getNumberColumnsSpanned();
Length colWidth = null;
-if (cell.getWidth().getEnum() != EN_AUTO
-&& colSpan == 1) {
-colWidth = cell.getWidth();
+if (cell.getWidth().getEnum() != EN_AUTO) {
+LengthProperty p = (LengthProperty)
cell.getWidth();
+if (p instanceof FixedLength) {
+colWidth = new FixedLength(p.getValue
() / colSpan);
+} else if (p instanceof PercentLength) {
+PercentLength pctLength =
(PercentLength) p;
+double factor = pctLength.getPercentage
() / 100;
+colWidth = new PercentLength(factor /
colSpan,
+pctLength.getBaseLength());
+}
}
for (int i = colNr; i < colNr + colSpan; ++i) {
Index: src/java/org/apache/fop/fo/flow/TableRow.java
===
--- src/java/org/apache/fop/fo/flow/TableRow.java (revision
489884)
+++ src/java/org/apache/fop/fo/flow/TableRow.java (working copy)
@@ -34,8 +34,11 @@
import org.apache.fop.fo.properties.CommonAural;
import org.apache.fop.fo.properties.CommonBorderPaddingBackground;
import org.apache.fop.fo.properties.CommonRelativePosition;
+import org.apache.fop.fo.properties.FixedLength;
import org.apache.fop.fo.properties.KeepProperty;
+import org.apache.fop.fo.properties.LengthProperty;
import org.apache.fop.fo.properties.LengthRangeProperty;
+import org.apache.fop.fo.properties.PercentLength;
/**
* Class modelling the fo:table-row object.
@@ -74,7 +77,7 @@
/**
* @see org.apache.fop.fo.FObj#bind(PropertyList)
*/
-public void bind(PropertyList pList) throws FOPException {
+protected void bind(PropertyList pList) throws FOPException {
blockProgressionDimension
= pList.get
(PR_BLOCK_PROGRESSION_DIMENSION).getLengthRange();
commonBorderPaddingBackground =
pList.getBorderPaddingBackgroundProps();
@@ -133,9 +136,16 @@
int colSpan = cell.getNumberColumnsSpanned();
Length colWidth = null;
-if (cell.getWidth().getEnum() != EN_AUTO
-&& colSpan == 1) {
-colWidth = cell.getWidth();
+if (cell.getWidth().getEnum() != EN_AUTO) {
+LengthProperty p = (LengthProperty) cell.getWidth
();
+if (p instanceof FixedLength) {
+colWidth = new FixedLength(p.getValue() /
colSpan);
+} else if (p instanceof PercentLength) {
+
Open issue: table-columns from first row?
Hi all, Since two replies I sent to Simon's posts seemed to end up in oblivion, I'll post it as a new message. Concerns the following issue: [Simon:] Uncertain status. The linked bug is resolved, but the description does not match the description of the bug: Omitting fo:table-column or having fo:table-column without a column-width and attempting to create columns implicitly from the first table row is not implemented, yet (Bugzilla #35656). Just had another look, and it currently only works correctly in case there is no column-spanning going on in any of the cells in the first row. ... In this case, two implicit columns are created, but the cell's width is not yet distributed over the two columns. I'll add a testcase demonstrating what still goes wrong, but the issue probably needs to put in a slightly different wording, indicating that it works apart from the above reservation. Cheers, Andreas
