My last programming problem was about printing a report from a web application. In the past I solved it using Internet Explorer’s print templates, but that solution had 2 drawbacks: the first was that it required IE 5.5 or later, the second was that the page customizations (margins, orientation, header and footers) required downloading an ActiveX. This was an easy requirement at the time due to the intranet use of the application.
Now that I have moved to Linux and Open Source software that is no more feasible. I had to find another solution.
The IT market is full of reporting tools for the web but most of them are expensive and require some kind of plug-in, since the browser alone is not capable of giving a precise rendering of the printed page. Yes, CSS has something to say about print media but these properties are mostly ignored by the current bunch of browsers.
And then there is my main requirement: all the software used must be Open Source.
After some thoughts I decided to produce a PDF print for my reports. A quick google search gave me a number of products to try. I could divide them in 3 categories:
- raw PDF libraries
- XSL-FO
- conversion tool from other format (i.e. HTML)
I didn’t even think to take into consideration the first solution. XSL-FO looked appealing in beginning, but when I looked more deeply to what was it about, I gave up. BTW just reading the word XML was enough to make me shiver.
The third approach seemed much simpler. Write the report in HTML, give it to the converter program and send the result to the user. Too good to be true: I didn’t have to learn another language and could even reuse the old reports written for IE print templates. The best known of such tools is htmldoc but unfortunately this is a very crude product. It interprets only HTML 3.2 and no CSS. Not very useful. Other products that I downloaded did not look better that htmldoc. I was somewhat amazed by the fact that such a simple and useful concept, an HTML to PDF converter, did not found a supporter in the Open Source that could produce a decent utility. Until I discovered dompdf. It is an impressive library. It supports most of the CSS directives (the notably exceptions being absolute positioning and floating). The first report that I tried worked like a charm. I took my HTML, passed through this utility and my PDF was there. Ok, I have been too enthusiastic. I found a couple of problems when I tried to bend it to some special needs that I had but nothing that some search in the documentation and in the forum couldn’t solve.
So, to help others that might encounter the same problems I thought to add a few points here to the dompdf FAQ:
1. how can I make it faster?
Up to version 0.5.1, there is a line in the library that uses a call to the uniqid() php function. Since this call is slow and it is done once for each dom node in the document, it slows down the translation in a sensible way. The workaround consists in changing the line 171 in file frame.cls.class:
$this->set_id(uniqid(rand()));
with :
global $dompdf_unique_id;
if (isset($dompdf_unique_id)){
$dompdf_unique_id++;
}else{
$dompdf_unique_id = 1;
}
$this->set_id( $dompdf_unique_id );
Alternatively, change the same line with this:
uniqid ('', true)
2. how can I put some data coming from the DB into the header/footer?
See Q.4 in the official FAQ. In the script, declare the variable you want to use as global, like this:
global $my_var;
3. how can I put a background on every page?
if ($draft) // if TRUE print "DRAFT" across every page
{
$obj_draft = $pdf->open_object();
$pdf->text(200, $h - 300, "DRAFT",
Font_Metrics::get_font("verdana", "bold"),
110, array(0.8, 0.8, 0.8), 0, -52, "Darken", 1);
$pdf->close_object();
$pdf->add_object ($obj_draft, "all");
}
4. I followed the instructions in Q.4 but it doesn’t work?
Check that the tag
<script type="text/php">
is INSIDE the body tag.
5. how do I print a page generated from PHP?
All the examples in the official FAQ use the
$dompdf->load_html($html);
function, where $html is a string containing the document to print. But what if the document is the result of the current PHP page. Here the trick consists in buffering the PHP output and then using the load_html() on the content of the buffer. Like this:
<?php
ob_start(); // start buffering
...
// whatever
...
$dompdf = new DOMPDF();
$out = ob_get_clean(); // get the content of the buffer and clear it
$dompdf->load_html($out);
$dompdf->render();
$dompdf->stream ("Filename.pdf");
?>
6. ERROR: Unable to stream pdf: headers already sent
I came across this error few times. The reason was always due to 3 non visible characters at the beginning of the file, as a consequence of using an editor set with a different character encoding (e.g UTF-8, Latin 1, …).
Try to run the command
hexdump -C filename | less
and see what the initial characters are.
Beware that few editors allow to remove them. Emacs is one of these.
7. ERROR: Nesting level too deep - recursive dependency? in (…)/dompdf/include/table_frame_decorator.cls.php on line 143
This error often occurs when a table spans 2 or more pages. DOMPDF tries to split it and repeat the THEAD on the following page. In doing so, it calls the PHP in_array() function, which gives this error. There are 2 workarounds: one is deleting the TBODY tag, the other is patching the split() function found in table_frame_decorator.cls.php, and adding a 3rd argument (true) to the 3 in_array function calls found there. More or less like the following code:
// If $child is a header or if it is the first non-header row, do
// not duplicate headers, simply move the table to the next page.
if ( count($this->_headers) && !in_array($child, $this->_headers, true) &&
!in_array($child->get_prev_sibling(), $this->_headers, true) ) {
...
} else if ( in_array($child->get_style()->display, self::$ROW_GROUPS, true) ) {
8. ERROR: Frame not found in cellmap
I encountered it when using the CSS attribute ‘page-break-inside: avoid’. A possible workaround is reported in the DOMPDF forum and consists in replacing all occurrences of
throw new DOMPDF_Internal_Exception("Frame not found in cellmap");
with
return false;
I don’t know any possible side effects, but it worked for me till now.
Another fix that worked for me in one occasion was replacing the markup used with the ‘page-break-inside: avoid’, in that case from DIV to P.
