search

vikrambalye / dompdf

Automatically exported from code.google.com/p/dompdf
0 stars 0 forks source link

table cells outside a table element result in fatal error #364

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Converting this report to pdf in php code or the command line.
2.
3.

What is the expected output? What do you see instead?
Website crashes with error in summary/title. I extracted the html from the 
website page into a standalone file and it still crashes when run from the 
linux command line. That file is attached

What version of the product are you using? On what operating system?
0.5.2 I assume - it was installed weeks ago, but I didn't do the install and 
don't see how to find the version. System running Ubuntu 10.04 LTS

Please provide any additional information below.
The report is a huge group of tables, including nested tables. I did an html 
validation and found some errors. But when I corrected them in the standalone 
file, it still crashes. Most versions of this report on this website work fine 
with dompdf, but on rare occasions this happens. Since the content is tables, 
and given the function that it is crashing in, I assume there is something in 
the content that is causing this and don't know if it is something dompdf 
should catch and warn of if that is feasible.

Original issue reported on code.google.com by myersond...@gmail.com on 12 Oct 2011 at 4:15

Attachments:

GoogleCodeExporter commented 9 years ago 
You have some nested tables which are creating cells that are too large to fit 
on a single page. This causes an infinite loop in dompdf (as outlined in issue 
91). If you move the nested tables outside of their containing table your 
document should render successfully (so long as dompdf has sufficient 
resources, i.e. memory, processing time).

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

GoogleCodeExporter commented 9 years ago 
I'm replying to your post on issue 91 here since it's more relevant to your 
original issue.

I went back and looked at your original document and was unable to find any 
unopened tables. Of course, it's a big document so I might have missed 
something. Or in the process of testing I might have inadvertently fixed that 
markup error.

Then again, the W3C HTML validator didn't see any structural problems of that 
type in your sample document either. Are you testing with the same document you 
posted here (or with something generated dynamically)?

Either way, incorrectly structured tables do present a problem for dompdf. 
Generally we recommend that you ensure your documents are structurally valid 
before passing them to dompdf. That eliminates a lot of problems.

Original comment by eclecticgeek on 14 Oct 2011 at 5:06

GoogleCodeExporter commented 9 years ago 
Yes, it's a large document and hard to find small errors like this. All I know 
is that by fixing this error in our system, dompdf is working 100% of the time 
on our site. Hopefully having this response available in searches will clue 
people in that doing an html validation is a good starting place when they have 
problems with conversions. Thanks for your quick responses on this issue.

Original comment by myersond...@gmail.com on 14 Oct 2011 at 5:34

GoogleCodeExporter commented 9 years ago 
Removing duplicate status and modifying the issue summary to reflect the 
suspected cause of the error.

Example Code:
<html><body><td>table cell</td></body></html>

Resulting Error:
Fatal error: Call to a member function get_cellmap() on a non-object in 
dompdf/include/table_cell_frame_reflower.cls.php on line 64

Though the above code is structurally invalid, the same problem could result 
from the following:
<html><body><div style="display: table-cell;">table cell</div></body></html>

The CSS spec outlines rules related to the generation of missing table objects.
http://www.w3.org/TR/CSS2/tables.html#anonymous-boxes

Original comment by eclecticgeek on 14 Oct 2011 at 9:11

GoogleCodeExporter commented 9 years ago 
We recently implemented an HTML5 parser that solves this issue, see here for 
more info : http://code.google.com/p/dompdf/wiki/HTML5

Original comment by fabien.menager on 23 Oct 2011 at 2:42

GoogleCodeExporter commented 9 years ago

Original comment by eclecticgeek on 30 May 2013 at 5:16