Hi,
I found jet another problem with automatic table layout ...
This time it's the width calculation of the columns when colspans are used.
For testcase see:
http://eric.nitrate.nl/prince/colspan.html
and
http://eric.nitrate.nl/prince/colspan.pdf
The table-cells in the testcase have a background images which makes it easy to see how many pixels width of the tables are (each red/black block is 10 pixels wide and is constructed of alternating white and red/black so you can count the individual pixels if needed).
The problem occurs when the content of a cell, with a colspan >1, grows bigger than the total width of the number of columns spanned minus 1
The testcase contains 3 examples.
The first is with 2 columns. If the content (green div) grows larger than the width of the first column the second column will grow bigger.
The second is with 3 columns. If the content (green div) grows larger than the combined width of the first and second column the second and third column will grow larger.
The third is with 4 columns. If the content (green div) grows larger than the combined width of the first 3 column, the second, third and fourth column will grow bigger.
I think the picture is clear now .. it looks like a simple off-by-one error since the width of the last column spanned is not taken into account.
Is there any chance this bug can be fixed before the planned 6.0r6 release? (it seems easy to fix, and it is a really annoying bug for us since many layouts of our surveys in pdf (new feature in our last release) are affected)
Kind Regards,
Eric de Ruiter
Amplixs Interaction Management
I found jet another problem with automatic table layout ...
This time it's the width calculation of the columns when colspans are used.
For testcase see:
http://eric.nitrate.nl/prince/colspan.html
and
http://eric.nitrate.nl/prince/colspan.pdf
The table-cells in the testcase have a background images which makes it easy to see how many pixels width of the tables are (each red/black block is 10 pixels wide and is constructed of alternating white and red/black so you can count the individual pixels if needed).
The problem occurs when the content of a cell, with a colspan >1, grows bigger than the total width of the number of columns spanned minus 1
The testcase contains 3 examples.
The first is with 2 columns. If the content (green div) grows larger than the width of the first column the second column will grow bigger.
The second is with 3 columns. If the content (green div) grows larger than the combined width of the first and second column the second and third column will grow larger.
The third is with 4 columns. If the content (green div) grows larger than the combined width of the first 3 column, the second, third and fourth column will grow bigger.
I think the picture is clear now .. it looks like a simple off-by-one error since the width of the last column spanned is not taken into account.
Is there any chance this bug can be fixed before the planned 6.0r6 release? (it seems easy to fix, and it is a really annoying bug for us since many layouts of our surveys in pdf (new feature in our last release) are affected)
Kind Regards,
Eric de Ruiter
Amplixs Interaction Management