search

bernattorras / dompdf

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

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

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago

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

GoogleCodeExporter commented 8 years ago 
Issue 80 has been merged into this issue.

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

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
Is there a solution to this problem?

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

GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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:

GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago 
Issue 335 has been merged into this issue.

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

GoogleCodeExporter commented 8 years ago 
Issue 342 has been merged into this issue.

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

GoogleCodeExporter commented 8 years ago 
Issue 361 has been merged into this issue.

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

GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
Issue 452 has been merged into this issue.

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

GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
Fix it please!:)

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

GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago 
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 commented 8 years ago

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