dompdf unable to split table cells between pages

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Include in the html a large amount of text, in my case within a tables
<td></td>  No other html wrappers. (File attached).

2.Run through DOMPDF as memory.

3.Times out on: _collapse_white_space, appears to be stuck in a endless loop.

What is the expected output? What do you see instead?
Expect output is the pdf, I get a timeout.  Although it is a large amount
of text I dont think it is a silly amount.

What version of the product are you using? On what operating system?
OS: Win2003 Server, DOMPDF version is 0.5.1

Please provide any additional information below.
Hopefully the attached file will provide enough to replicate the issue.

Original issue reported on code.google.com by smug...@gmail.com on 16 Nov 2009 at 6:21

Attachments:

• example.html

[GoogleCodeExporter]

Your document renders ok on my machine. It may have to do with the version of 
PHP you
are using. The other possible source may be your system resources (i.e. not 
enough
memory or processing power).

Have you tried DOMPDF 0.6.0 alpha 2? It does have some improvements related to 
tables.

Original comment by eclecticgeek on 16 Nov 2009 at 8:39

[GoogleCodeExporter]

Hi,

Many thanks for the quick response.  Thats interesting it works without issue 
for
you, i had assumed it was dompdf or somin in the html I wasn't seeing that was
causing the problem.  Could it be a problem with me converting it in memory?

I'm using PHP 5.2.  That said the server its running on is fairly powerful with
plently of resources. Quad core, 8GB Ram, big HDD.

I've not looked at 0.6.0 as yet, do you think it's stable enough to use.

The other thing I found out today is that <td>&nbps;</td> so a empty table cell
caused a cell crash.

Original comment by smug...@gmail.com on 16 Nov 2009 at 9:20

[GoogleCodeExporter]

There are lots of issues with tables, even in the upcoming release. Your 
problem, however, could be the images 
and/or CSS combined with the tables. Without all the document assets there's no 
way I could test for this. You might 
try taking out references to the CSS and images and see what happens.

DOMPDF 0.6.0 alpha 2 should be stable enough for use. I typically test every 
help request in it to see how it handles 
compared to 0.5.1. There have been very few instances where 0.6.0 had trouble 
with something 0.5.1 was able to 
render.

Even so, I've run across a few problems here and there. One in the file you 
posted, which I have already addressed in 
the subversion repository. If you want to try the next release, at least until 
we post a new download, add a space 
before your character encoding. i.e. make ...
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
read like
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Original comment by eclecticgeek on 17 Nov 2009 at 2:50

[GoogleCodeExporter]

Thanks for the <meta tip, i have adjusted it.

I've had a bit of a play and it seems that it is something in the css that is 
causing
it.  I can't think what at the moment as the same css is used on other html to 
pdf
reports almost identical to this without issue but i'm going to methodically 
remove
bit to try to track it down.

I susspect it is something to do with the <td> but we shall see.  Going to try 
to get
to the bottom of this before I try 0.6.0.  Will post the issue when/if i find 
it.

Original comment by smug...@gmail.com on 17 Nov 2009 at 10:28

[GoogleCodeExporter]

Update to the problem.  Turns out it was a CSS issue after all, as yet have been
unable to identify the troublesome CSS element as it's not one used by the HTML 
thats
being parsed but is in the CSS file that was included.

Simple fix was to seperate out the css to a pdf.css file that is stripped right 
back
to only the essentials for the html being converted.  Will post again if I suss 
it out.

Original comment by smug...@gmail.com on 18 Nov 2009 at 10:49

[GoogleCodeExporter]

Could your CSS have caused one of the cells in your table to grow beyond the 
size of a single page? A cell that 
expands beyond a single page will cause DOMPDF to enter an infinite loop

Original comment by eclecticgeek on 24 Apr 2010 at 1:06

[GoogleCodeExporter]

On second thought, I believe you are dealing with the table cell issue. DOMPDF 
appears to be attempting to keep 
the contents of each row on a single page. When one of the cells in a row 
overflows the page DOMPDF moves the 
row to the next page. If the row in question is larger than a single page it 
will continually be pushed to the next 
page. This loop continues until DOMPDF runs out of resources.

Original comment by eclecticgeek on 24 Apr 2010 at 1:59

• Changed title: table cells larger than a single page cause an infinite loop

[GoogleCodeExporter]

The following HTML sends dompdf 0.6 beta into an infinite loop:

<html>
<head></head>
<body>
<table>
    <tr><td>Foo</td><td>Bar</td></tr>
    <tr><td>Foo</td><td>Bar</td></tr>
    <tr><td>Foo</td><td>Bar</td></tr>
    <tr><td>Foo</td><td>Bar</td></tr>
    <tr><td>Foo</td><td>Bar</td></tr>
    <tr><td>Foo</td><td>Bar</td></tr>
</table>
</body>
</html>

... What's the workaround there?

Original comment by joris.witteman@gmail.com on 12 Jul 2010 at 1:52

[GoogleCodeExporter]

@joris.witteman: I don't think you're running into an infinite loop problem as 
described here. The code you provided works fine when I render it:
http://eclecticgeek.com/dompdf/index.php?input_file=issue91c8.htm&dompdf_ver=0.6
.0_beta1

Please post additional information on the support forum so we can help you work 
out your issue:
http://groups.google.com/group/dompdf

Original comment by eclecticgeek on 12 Jul 2010 at 3:36

[GoogleCodeExporter]

Issue 164 has been merged into this issue.

Original comment by eclecticgeek on 21 Jul 2010 at 6:14

[GoogleCodeExporter]

Original comment by fabien.menager on 27 Jul 2010 at 8:56

• Changed state: Accepted
• Added labels: Milestone-Release0.6

[GoogleCodeExporter]

Issue 169 has been merged into this issue.

Original comment by fabien.menager on 20 Oct 2010 at 8:57

[GoogleCodeExporter]

Issue 282 has been merged into this issue.

Original comment by eclecticgeek on 18 May 2011 at 6:27

[GoogleCodeExporter]

Issue 297 has been merged into this issue.

Original comment by eclecticgeek on 2 Jun 2011 at 2:54

[GoogleCodeExporter]

Issue 301 has been merged into this issue.

Original comment by eclecticgeek on 9 Jun 2011 at 5:14

[GoogleCodeExporter]

Issue 310 has been merged into this issue.

Original comment by eclecticgeek on 23 Jun 2011 at 9:01

[GoogleCodeExporter]

Issue 34 has been merged into this issue.

Original comment by fabien.menager on 19 Jul 2011 at 8:45

[GoogleCodeExporter]

Issue 10 has been merged into this issue.

Original comment by fabien.menager on 19 Jul 2011 at 8:45

[GoogleCodeExporter]

Original comment by fabien.menager on 19 Jul 2011 at 8:51

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

On a legacy system.
PHP v5.1.6
DomPDF v0.5.2
Modified dompdf.php to put the line at the start:

#!/usr/bin/pdf

Execute command on my server as:

/home/user/dompdf/dompdf.php -p a4 -f ztesting.pdf ztesting.html

It can work a few times in a row (best I've done it 16 times).
But otherwise it can randomly freeze when processing.
It uses zero cpu when it freezes (idle process).
Memory never goes up while it's stuck processing.
I can manually break out of it easy enough (Ctrl + C).
But otherwise it never finishes procesing.

Original comment by terry...@alliancesoftware.com.au on 5 Oct 2011 at 7:40

Attachments:

• ztesting.html

[GoogleCodeExporter]

@terry... post this to the support group, doesn't sound like what you're 
experiencing is directly related to this issue.

Original comment by eclecticgeek on 8 Oct 2011 at 1:25

[GoogleCodeExporter]

Issue 364 has been merged into this issue.

Original comment by eclecticgeek on 12 Oct 2011 at 6:39

[GoogleCodeExporter]

So you merged by issue 364 into this one, but in fact after restructuring the 
content to not have the nested tables, it still crashed. I eventually 
determined that within content, there was a missing <table> tag, so we 
basically had:

<tr><td>stuff</td></tr></table>

When this was fixed, the conversion no longer crashed.

Original comment by myersond...@gmail.com on 14 Oct 2011 at 4:38

[GoogleCodeExporter]

Issue 129 has been merged into this issue.

Original comment by eclecticgeek on 25 Oct 2011 at 12:30

[GoogleCodeExporter]

Issue 372 has been merged into this issue.

Original comment by eclecticgeek on 25 Oct 2011 at 12:36

[GoogleCodeExporter]

Modifying summary to highlight the actual issue. In the worst case this results 
in an infinite loop. The other typical result is lots of empty space where 
content could be placed if the cell could be split.

Original comment by eclecticgeek on 25 Oct 2011 at 12:45

• Changed title: dompdf unable to split table cells between pages

[GoogleCodeExporter]

Issue 382 has been merged into this issue.

Original comment by eclecticgeek on 29 Nov 2011 at 6:39

[GoogleCodeExporter]

Issue 433 has been merged into this issue.

Original comment by eclecticgeek on 24 Feb 2012 at 5:21

[GoogleCodeExporter]

I had the same problem either memory exception (1024 MB) or script time out 
(3000 Sec).
In my html, 
<table><tr><td>
<table>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
......29set of "<tr><td></td><td></td></tr>"
</table>
</td></tr></table>

I used latest beta version(0-6-0_beta3) to test!!!!.

I managed to simulate the issue in my case, if I reduced 29 (inner td/tr) to 
24, it working fine, If more than 25 then its freezes.

When I replaced outer table to <div> then it is allowing me to add 29 td/tr 
content.

Strange behavior, looks like not the issue with CSS or table seems to be, not 
able to manage more then 25 td/td content in inner table.

Hope this might help somebody if any similar issue.

Original comment by gurukml...@gmail.com on 18 Mar 2012 at 9:23

[GoogleCodeExporter]

Hello Guys,

I also had the same problem. But in my HTML code, i dont have more <td>s as 
Guru told. But my content is very big and it'll come around 6 pages. The 
content was created using the FCKeditor and stored in the mysql database. Am 
using the stored mysql content and making that as a simple HTML and generating 
pdf. Here is my code below,

$buffer         = "<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 
Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
<html xmlns='http://www.w3.org/1999/xhtml'>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
<title></title>
</head>
<body>
<table width=\"100%\" border=\"0\" cellspacing=\"0\" cellpadding=\"0\" 
style=\"border:1px solid #000000\">
<tr>
 <td align=\"left\" valign=\"top\" width=\"300\" style=\"padding-top:3px; padding-left:3px; padding-bottom:3px; border-bottom:1px solid #000000;\"><img src=\"http://www.toptechdepot.com/admin/images/VentDepot_Logo_PDF.jpg\" width=\"200\" height=\"100\" /></td>
    <td align=\"right\" valign=\"middle\" style=\"padding-right:10px; color:#000000; font-family:Arial, Helvetica, sans-serif; border-bottom:1px solid #000000;\">".$row_data['title']."<br>".$date."</td>
      </tr>
  <tr>
    <td colspan=\"2\" align=\"left\" valign=\"top\" style=\"font-family:Arial, Helvetica, sans-serif;font-size:12px; padding-left:3px;\">
    <table width=\"100%\" border=\"0\" cellspacing=\"0\" cellpadding=\"0\">
    <tr>
    <td align=\"left\" valign=\"top\">
    ".$row_data['description']."
    </td>
  </tr>
</table>
  </td>
  </tr>
</table>
</body>
</html>";
echo $buffer;
require_once("dompdf_config.inc.php");
$dompdf = new DOMPDF();
$dompdf->load_html($buffer);
$dompdf->render();
$dompdf->stream("sample.pdf", array('Attachment'=>'0'));

This is my content $row_data['description'] which am retrieving from the 
database.

Please help me to solve the issue. 

Advance thanks.

Original comment by muthuraj...@gmail.com on 20 Mar 2012 at 1:41

[GoogleCodeExporter]

@muthurajmanikandan there is currently no way to work around this issue. You 
can only avoid the problem by restructuring your document. Star this issue to 
receive updates on its status.

FYI, If you're using v0.6.0 you can get away without using a table, though 
until we work out a few kinds it does require a bit of manual formatting. See 
the following non-table version:
http://eclecticgeek.com/dompdf/debug.php?identifier=b47eab69ab4ec658ecb632b40015
32d6

Original comment by eclecticgeek on 22 Mar 2012 at 3:22

[GoogleCodeExporter]

Issue 475 has been merged into this issue.

Original comment by fabien.menager on 28 Apr 2012 at 10:56

[GoogleCodeExporter]

@eclecticgeek Would this issue also be related to simply long tables, ie many 
rows but short rows, not over a page long? I am having similar memory/timeout 
issues but my table has 30 rows per page but several hundred rows total. If 
none of the rows are over a page should I open a separate ticket?

Original comment by mattl...@gmail.com on 24 Jul 2012 at 6:33

[GoogleCodeExporter]

@mattleff a long table with short rows shouldn't result in this issue. Start a 
new issue or thread on the discussion forum. Remember to post a sample document 
if you can.

Original comment by eclecticgeek on 24 Jul 2012 at 6:54

[GoogleCodeExporter]

I'd like to share my experience on this problem. When trying to generate a PDF 
containing a table of 13 columns and about 80 rows, I believe I encountered 
this issue.

Removing whitespace between HTML tags in the markup prior to dompdf rendering 
allowed it to work.

I used the following code to do this:

$html = preg_replace('/>\s+</', "><", $html);
$dompdf->load_html($html);

Original comment by craig.rodway on 26 Jul 2012 at 9:55

[GoogleCodeExporter]

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

• Added labels: Restrict-AddIssueComment-Commit