Tables column widths are not consistent across pages about dompdf

[GoogleCodeExporter]

I found a temporary solution for this. If its a small document and if you are 
able to
find out the rows that come in other pages, set the width % of columns for 
those rows
too down the table. This is a temporary fix though. I think this might happen 
if % is
used. I am not sure what happens if px is used. 

Original comment by [email protected] on 12 Feb 2010 at 6:09

[GoogleCodeExporter]

I don't know if it is related but I have a very strange issue with table.
As you can see, on the second page, the images in the table are bigger than in 
the 
first page. The size on the first page is correct, I don't see why it is scaled 
up in 
the the second page.
I'm running the 0.6.0beta posted yesterday.

Original comment by pvledoux on 12 Mar 2010 at 1:58

Attachments:

• [document (23).pdf](https://storage.googleapis.com/google-code-attachments/dompdf/issue-48/comment-2/document %2823%29.pdf)

[GoogleCodeExporter]

HI i have a problem to convert the HTML to PDF . in this process if i have more 
text fields mean . the letter are split to next page how can i solve  this 
problem 

Original comment by [email protected] on 16 Apr 2010 at 12:55

[GoogleCodeExporter]

Please notify me when this issue is fixed.  I have the same problem with nested 
tables.

Original comment by [email protected] on 4 Oct 2010 at 1:06

[GoogleCodeExporter]

The error isn't specific to nested tables. In general DOMPDF is currently 
unable to track table calculations across pages. Updating the summary statement 
to reflect this.

Original comment by eclecticgeek on 1 Mar 2011 at 6:40

• Changed title: tables column widths are not consistent across pages
• Changed state: Accepted

[GoogleCodeExporter]

Issue 226 has been merged into this issue.

Original comment by eclecticgeek on 1 Mar 2011 at 6:42

[GoogleCodeExporter]

quote:
In general DOMPDF is currently unable to track table calculations across pages.

Is there any chance that the next release of DOMPDF is able to handle that 
problem?

Original comment by [email protected] on 2 Mar 2011 at 6:28

[GoogleCodeExporter]

We would like to address a few table issues, so there is a chance. I can't say 
right now if it will be addressed, though.

Original comment by eclecticgeek on 3 Mar 2011 at 6:52

[GoogleCodeExporter]

Don't know if it is important, but there is still one more error that might be 
related to this posted issue.

When having a table that is split up by DOMPDF the graphics and rows are 
converted correctly for the first page.
Right after the page break, the row and cell sizes are converted correctly, 
however, the graphics are converted differently in comparison to the first page 
grahpics.
Where the graphics in the first page show larger white borders to the right and 
left and small borders to the top and bottom, the graphics in the second page 
only show small borders to the left, right, up and down.
All graphics are of identical size in the original.
After the conversion, both grahpics before and after the pagebreak are 
converted - just in different ways, resulting in different sizes.
All graphics on the first page are of the same size (both before and after the 
conversion) and so are all graphics after the pagebreak of the same size (both 
before and after the conversion, too). 

Original comment by [email protected] on 11 Mar 2011 at 7:33

[GoogleCodeExporter]

Issue 312 has been merged into this issue.

Original comment by eclecticgeek on 26 Jun 2011 at 1:37

[GoogleCodeExporter]

Issue 84 has been merged into this issue.

Original comment by eclecticgeek on 22 Dec 2011 at 7:19

[GoogleCodeExporter]

The original issue report doesn't really correspond to what I just fixed, but 
now when tables are split across pages, the column widths are kept (since r462).

Original comment by fabien.menager on 29 Jan 2012 at 10:46

• Changed title: Tables column widths are not consistent across pages

[GoogleCodeExporter]

Original comment by eclecticgeek on 24 May 2013 at 3:00

• Added labels: Restrict-AddIssueComment-Commit