Cellmap->get_spanned_cells: "Frame not found in cellmap" when rowspanned table spans to the next page

[GoogleCodeExporter]

What steps will reproduce the problem?

1. rowpanned table that doesn't feet to one page

What is the expected output? What do you see instead?

If I change the font size of the cells content for the table to feed in 
one page, no error occurs. If it's expected to span to the next page, the 
error occurs.

What version of the product are you using? On what operating system?

The trunk version svned on Sept 03, 2009. x86_64 GNU/Linux.

Please provide any additional information below.

This error existed in the 0.5.1 version as well.

Stack trace:
#0 /home/.../dompdf/include/table_cell_renderer.cls.php(74): Cellmap-
>get_spanned_cells(Object(Table_Cell_Frame_Decorator))
#1 /home/.../dompdf/include/renderer.cls.php(222): Table_Cell_Renderer-
>render(Object(Table_Cell_Frame_Decorator))
#2 /home/.../dompdf/include/renderer.cls.php(110): Renderer->_render_frame
('table-cell', Object(Table_Cell_Frame_Decorator))
#3 /home/.../dompdf/include/renderer.cls.php(143): Renderer->render(Object
(Table_Cell_Frame_Decorator))
#4 /home/.../dompdf/include/renderer.cls.php(143): Renderer->render(Object
(Table_Row_Frame_Decorator))
#5 /home/.../dompdf/include/renderer.cls.php(143): Renderer->render(Object
(Table_Frame_Decorator))
#6 /home/.../dompdf/include/renderer.cls.php(143): Renderer->render(Object
(Block_Frame_Decorator))
#7 /home/.../dompdf/include/page_frame_reflower.cls.php(103): Renderer-
>render(Object(Block_Frame_Decorator))
#8 /home/.../dompdf/include/frame_decorator.cls.php(388): 
Page_Frame_Reflower->reflow()
#9 /home/.../dompdf/include/dompdf.cls.php(509): Frame_Decorator->reflow()
#10 /home/.../file.php(26): DOMPDF->render()
#11 {main}
  thrown in /home/.../dompdf/include/cellmap.cls.php on line 224

Original issue reported on code.google.com by anatoli...@gmail.com on 3 Sep 2009 at 8:30

[GoogleCodeExporter]

ran across this myself. actually submitted another issue (80), with some sample 
code to reproduce it.

Original comment by wah...@gmail.com on 20 Oct 2009 at 9:40

[GoogleCodeExporter]

Original comment by eclecticgeek on 20 Oct 2009 at 5:41

• Changed state: Accepted

[GoogleCodeExporter]

Issue 80 has been merged into this issue.

Original comment by eclecticgeek on 20 Oct 2009 at 5:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This seems to be related to the table breaking on multiple pages. It breaks the 
cell map when a cell is split in two cells when it overflows a page.

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

[GoogleCodeExporter]

Is there a solution to this problem?

Original comment by andrea.b...@gmail.com on 23 Nov 2010 at 9:18

[GoogleCodeExporter]

This problem doesn't occur for me with a row-spanned table but with a normal 
simple table. As soon as the rows fill one page and I would expect the rows to 
continue on the next page, but get the exception "Frame not found in cellmap".

Any known work-arounds?

Original comment by solution...@gmail.com on 2 Dec 2010 at 2:39

[GoogleCodeExporter]

I couldn't find a solution, so I switched to mPDF.

Original comment by andrea.b...@gmail.com on 2 Dec 2010 at 7:29

[GoogleCodeExporter]

Andrea, thanks a lot for that tip. mPDF works like a charm with big tables.
Sorry to turn my back on dompdf ...

Original comment by solution...@gmail.com on 2 Dec 2010 at 6:50

[GoogleCodeExporter]

There has to be a solution other than switching to mPDF. 

Original comment by flat...@gmail.com on 13 Dec 2010 at 6:10

[GoogleCodeExporter]

I was able to create a work-around for this issue by closing the table before 
the page ended and then opening another table on the next page -- this bug is 
very annoying though so I will be looking into mpdf now too...  Question, does 
anyone else have problems with really long html files?  Does mpdf fix those 
issues too?

Original comment by imcman...@gmail.com on 14 Dec 2010 at 2:57

[GoogleCodeExporter]

In the current release DOMPDF should no longer error out in this situation. 
However, due to the fact that DOMPDF forgets table layout between pages the 
results will still not be as desired.

I believe we've addressed the specific issue here, but I won't close the issue 
until this has been verified. For the table layout problem please follow issue 
48.

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

• Changed state: Started

[GoogleCodeExporter]

I have the same issue, and determined that this got broken in the change to 
include/table_cell_frame_reflower.cls.php in r387. Reverting this change made 
the error go away.

I don't understand why though; perhaps because the page can get filled while 
calculating the flow of the cell? I'm not even sure if this is the right fix, 
but I really need to get dompdf working for my project so I needed to apply the 
patch. Without it, dompdf simply doesn't work for me.

For other people who are desperate to get dompdf working here's a patch for 
trunk that undoes the change.

Original comment by peter....@solide-ict.nl on 15 Jun 2011 at 10:12

Attachments:

• cell-reflower-page-error.patch

[GoogleCodeExporter]

Hey Peter !
Sure, we'll commit this change, it was my mistake ! I'll try to understand why 
this happens.

Original comment by fabien.menager on 15 Jun 2011 at 5:17

[GoogleCodeExporter]

The fix isn't perfect; there's a layout issue (which wasn't there in r387), but 
this might be caused by a different change altogether. Not sure yet. I'll try 
to figure out what caused it.

Original comment by peter....@solide-ict.nl on 16 Jun 2011 at 7:51

[GoogleCodeExporter]

Nevermind; it's another patch I applied that caused the issue (#77). The 
current trunk code is fine

Original comment by peter....@solide-ict.nl on 16 Jun 2011 at 8:01

[GoogleCodeExporter]

Issue 335 has been merged into this issue.

Original comment by eclecticgeek on 11 Aug 2011 at 6:18

[GoogleCodeExporter]

Issue 342 has been merged into this issue.

Original comment by eclecticgeek on 22 Aug 2011 at 5:02

[GoogleCodeExporter]

Issue 361 has been merged into this issue.

Original comment by eclecticgeek on 12 Oct 2011 at 2:13

[GoogleCodeExporter]

How do I install the patch mentioned above? I really need to get this working 
ASAP and upgrading did not work (raised a new issue 432)

Original comment by leon.br...@gmail.com on 21 Feb 2012 at 10:31

[GoogleCodeExporter]

Hello,

My fix (2 steps):

Step 1.
There is a file "include/table_row_group_frame_decorator.cls.php"
In it there is a function: split()
In the function, there is a line that reads: $cellmap =
$this->get_parent()->get_cellmap();

After that line, I've added the lines:

// ------------- my fix: (ydb1976@gmail.com)
 while($child->get_node()->getAttribute("dontbreak")){ //
DOMPDF::dbg("remgc: ".$child->get_id()); $child =
$child->get_prev_sibling(); }
// ------------- end of my fix

Step 2.
In the HTML that is provided to the class,
In a row that contains cells that started before it
I set the attribute "dontbreak" to true
example:

<tr>
<td>foo</td>
 <td *rowspan=3*>bar</td>
<td>baz</td>
</tr>
<tr *dontbreak="true*">
 <td>bar2</td>
<td>baz2</td>
</tr>
<tr *dontbreak="true"*>
 <td>bar3</td>
<td>baz3</td>
</tr>
<tr>
 <td>this row</td>
<td>can start</td>
 <td>in new page</td>
</tr>

That's it

What it does is to go all the way to the row that starts the row span, and
break the page from there.

WARNING:
if you have rowspan that will exceed the entire height of a page, this
while will loop infinitely (i didn't need a solution for that, but it can
be fixed too).

Enjoy,
Yariv

Original comment by ydb1...@gmail.com on 21 Feb 2012 at 11:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Same problem here,

"Fatal error: Call to a member function get_cellmap() on a non-object in 
/home/mugg/sub/t.profebox.com/script/dompdf/include/table_cell_frame_reflower.cl
s.php on line 31"

Original comment by jonasfon...@mugnetic.com on 8 Mar 2012 at 8:44

[GoogleCodeExporter]

Issue 452 has been merged into this issue.

Original comment by fabien.menager on 25 Mar 2012 at 5:11

[GoogleCodeExporter]

When will this issue be fixed? I'm waiting for this at least 2 months.

Original comment by huynhca...@gmail.com on 4 Jul 2012 at 10:10

[GoogleCodeExporter]

Fix it please!:)

Original comment by nkos...@gmail.com on 17 Jul 2012 at 3:50

[GoogleCodeExporter]

mpdf is easier too! three lines of code and bam! mpdf does it all!

Original comment by code.p...@googlemail.com on 18 Jul 2012 at 12:41

[GoogleCodeExporter]

mpdf is easier too! three lines of code and bam! mpdf does it all!

Original comment by code.p...@googlemail.com on 18 Jul 2012 at 12:41

[GoogleCodeExporter]

My 2 cents worth:
1. The patch DOESNT work

2. Yariv's "dontbreak" solution DOES WORK.

Thanks!

Original comment by zen...@gmail.com on 26 Sep 2012 at 3:57

[GoogleCodeExporter]

Oh yeah... Yariv's fix has a slightly hard-to-see commented line. You only need 
to add:

while($child->get_node()->getAttribute("dontbreak"))
{ 
$child =$child->get_prev_sibling();
}

Original comment by zen...@gmail.com on 26 Sep 2012 at 3:59

[GoogleCodeExporter]

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

• Added labels: Restrict-AddIssueComment-Commit