Open main menu

Extension talk:Pdf Export Dompdf



We had a problem with undefined variables. So we changes the file in the line 138
We altered the last line, the two lines above a new.
After this change everything works fine.

if(!isset($page)) $page = null;
$arr = array('Attachment'=>0);
$domPDF->stream(utf8_decode($page) . ".pdf", $arr);

Added: 27 January 2009

  • This works for me too! Thank you! --Aptd 22:23, 2 September 2009 (UTC)

A better solutionEdit

if(!isset($page)) $page = Title::newFromText($pagefiles[0]); // The file name becomes the title of the first page.

No ImagesEdit

We tried to implement this class, but it doesnt include any of our pictures. Is there a solution to it?

Not a bugEdit

Images are supported. This extension, just like the other PDF exporters, uses the style sheet that's served to "print" media. In short, you should have a print.css file in your theme. You will need to edit that to include background watermarks and the like. Alternatively, you can edit $IP/extensions/PdfExport/PdfExport_headfoot.php if you just want to include a logo, letterhead, copyright, info, etcetera.

Problems with nontrivial wikitextEdit

Running MediaWiki 1.13.2, PDFExport 2.0 with dompdf changes described here.

A lot of very simple pages print fine with dompdf; however, some pages give errors on display. For example, the following simple table in a MW page gives a 'File does not being with "%PDF-"...' error on Safari under Mac OS X:

# <nowiki>test</nowiki>

If you remove the nowiki, it works. (EDIT) However, the following code which does not use nowiki and does not number the table cell also doesn't work:






EDIT: I've figured out that the problem above may be related to the generation of tables of contents. If I turn off this with __NOTOC__, the PDF print works OK. However, on a very large page which is just a string of headers and pre blocks, I still get the "File does not begin with %PDF-" error when I export to PDF.

We're also getting the following written to the PDF on some pages:

exception 'DOMPDF_Exception' with message 'Box property calculation requires containing block width' in /usr/local/apache2/htdocs   /wiki/extensions/PdfExport/dompdf/include/block_frame_reflower.cls.php:111
Stack trace:
#0 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/block_frame_reflower.cls.php(368): Block_Frame_Reflower->_calculate_restricted_width()
#1 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/frame_decorator.cls.php(387): Block_Frame_Reflower->reflow()
#2 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/block_frame_reflower.cls.php(408): Frame_Decorator->reflow()
#3 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/frame_decorator.cls.php(387): Block_Frame_Reflower->reflow()
#4 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/block_frame_reflower.cls.php(408): Frame_Decorator->reflow()
#5 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/frame_decorator.cls.php(387): Block_Frame_Reflower->reflow()
#6 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/block_frame_reflower.cls.php(408): Frame_Decorator->reflow()
#7 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/frame_decorator.cls.php(387): Block_Frame_Reflower->reflow()
#8 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/table_cell_frame_reflower.cls.php(115): Frame_Decorator->reflow()
#9 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/frame_decorator.cls.php(387): Table_Cell_Frame_Reflower->reflow()
#10 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/table_row_frame_reflower.cls.php(70): Frame_Decorator->reflow()
#11 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/frame_decorator.cls.php(387): Table_Row_Frame_Reflower->reflow()
#12 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/table_frame_reflower.cls.php(468): Frame_Decorator->reflow()
#13 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/frame_decorator.cls.php(387): Table_Frame_Reflower->reflow()
#14 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/block_frame_reflower.cls.php(408): Frame_Decorator->reflow()
#15 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/frame_decorator.cls.php(387): Block_Frame_Reflower->reflow()
#16 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/page_frame_reflower.cls.php(78): Frame_Decorator->reflow()
#17 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/frame_decorator.cls.php(387): Page_Frame_Reflower->reflow()
#18 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/dompdf/include/dompdf.cls.php(417): Frame_Decorator->reflow()
#19 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/PdfExport_body.php(136): DOMPDF->render()
#20 /usr/local/apache2/htdocs/wiki/extensions/PdfExport/PdfExport_body.php(171): SpecialPdf->outputpdf(Array, ' --portrait ', 'Letter')
#21 /usr/local/apache2/htdocs/wiki/includes/SpecialPage.php(534): SpecialPdf->execute(NULL)
#22 /usr/local/apache2/htdocs/wiki/includes/Wiki.php(224): SpecialPage::executePath(Object(Title))
#23 /usr/local/apache2/htdocs/wiki/includes/Wiki.php(55): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#24 /usr/local/apache2/htdocs/wiki/index.php(93): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#25 {main} 

VIngogly 16:15, 6 February 2009 (UTC)


I have taken notice of your problem. I will look into a fix, but I must say right off the bat that it is a limitation of the DOMPDF class itself (and not the fault of this extension, per se). The class, though it works stupendously, is still quirky. The author seems to have abandoned it, but I will see about picking up where he left off.

reply from Vingogly: I've come to the same conclusion myself - DOMPDF doesn't handle anything beyond the simplest wikitext very well. I'm looking at other alternatives like HTML_ToPDF to integrate into a custom solution for my client. We really do need a solution that works here, and that will let us integrate a custom footer with a copyright disclaimer on every printed page. Thanks for your help!

VIngogly 17:40, 17 February 2009 (UTC)

What was your solution, i am getting the same problem. 15:33, 11 June 2009 (UTC)

Code has been updatedEdit

I took the liberty of updating the code to be compatible with the latest versions of Pdf Export, DOMPDF, and MediaWiki. It should work flawlessly. No problems with autoload functionality if you're running PHP 5.1.2 or higher (See: spl_autoload_register()). Temp directory has been changed to use system temp directory. Change that back to $wgTmpDirectory (don't forget to globalize it) if you have any issues. All modifications have been noted in the source code. Feel free to modify as needed.

Fail to render a pdf if restricted accessEdit

Hi, the extension works fine. Also the version with htmldoc. One small problem occurs if you restrict the access e.g. $wgGroupPermissions['*']['read'] = false;

In this case the extension fails, because she dont use the rights of the actual user. If i use the restricted access as above, i got access denied error.... you have to sign in first.

it would by great, if you can enhance it.

--Ozz 17:25, 20 October 2009 (UTC)

Problem with imagesEdit

Hi, the extension works fine for me too. I'm with PdfExport Version 2.3 modified, DOMPDF 0.6.0 alpha 2, MediaWiki 1.15.1.

The only problem I have is with the images, instead of my pictures I just get a box with a red cross. Maybe the problem comes from DOMPDF but the - dompdf 0.5.1 Featured - just gives me errors. If somebody had this problem and solved It, I would love to know the solution :)

-- Francois, 23 Feb 2010

Finally I've found how to solve my problem, it was because My wiki was in a protected password directory. Dompdf couldn't access to the images. If you need help about dompdf, you'll find a nice team of developper here :

-- Francois, 4 Mar 2010

Then how did you solve this problem?? As i am having the same problem with picture?? --Adilch 00:18, 17 January 2011 (UTC)

Setup problemsEdit

I've problems with the installation. I did like described but the server returns a Error 500. I think i have to configure Dompdf, but dont know how. They say: 2.Edit to fit your installation. Of course i have no, no, no knowledge of php or thelike, so i not understand really much. Can anybody help me? The server is Windows2003, IIS.... Ralf, 11. August 2010

Extensions gives Zero-length filesEdit

Hi, I installed the extension as instructed, but when I click on the export button, I just get a zero-length file "index.php" and no error message. What should I do? PHP version is 5.4.2

I had the same problem, I fixed it adding to my installation the mbstring extension mbstring installation. This extension (php_mbstring.dll) is not installed through the msi windows installer of php, you can get it from the zip distribution at php main site. Of course you have to enable the extension in the php.ini.
--Alberto 10:16, 15 November 2010 (UTC)

File does not beginn with '%PDF-'Edit

Hello I tried to run Dompdf on my wiki, because the instalation of htmldoc failed all to the time.. I get the Error-Message "File does not beginn with '%PDF-'". Is it because I run it with Xampp?

I am receiving the same error. (XAMPP, PHP 5.3.0, MW 1.16.0, PDF Export 2.4, Dompdf 0.60b) -- Jan 7, 2011

I am getting this error on some pages but not others. On the pages that print, images are not appearing... any suggestions?? Prodoom 22:27, 16 March 2011 (UTC)

Over here, the same too :-( I also have no rights to install HTMLDOC. That's why I was glad to find this extension. Can anyone help out? 15:33, 11 May 2011 (UTC)

I'm getting the same error in mediawiki 1.18. i figured out that this happens only on pages with a contents box. in fact it seems to be the contents box that causes this. is there any way that we can filter out the contents box from the page before they are converted to PDF ? Sven 6 January 2012

Working but no imagesEdit

This extension works perfectly on my wiki but does not show images, instead boxes with red cross... please help me how can i solve this.. thanks --Adilch 00:33, 17 January 2011 (UTC)

I'm having this error as well. Looking for a solution. Prodoom 22:27, 16 March 2011 (UTC)

You have to specify full path to your image, not just relative, e.g.:

Hope that helps.

Could you please elaborate on this? I am having the same issue with a big box with a red cross. The hyperlink is there, but not to actual file location. Click it and the file page appears, but not the actual path to the actual file itself. Example: in wiki code - Image:picture.jpg or File:picture.jpg. Where the actual location of the file maybe which of course when used gives you a hyperlink on the page instead of an image. I understand you are saying to specify the full path to the image, but how in wiki code on your pages? Thanks - Hutchy68 15:05, 16 October 2011 (UTC)

Hope that helps:

En el archivo de configuración del dompdf activa define("DOMPDF_ENABLE_REMOTE", true);

Issue with Firefox 4Edit

We have noticed that when using the PDF Export dompdf extension that the "section edit" links that are normally on the right side of the wiki page are instead on the left side and in the font size of the section header (large) when viewed by a Firefox 4 browser. The problem was not caused by the extension itself but by a suggested modification noted on the PDF Export page to make the TOC work in the PDF output by modifying the includes/Linker.php code. If you have made that modification all pages which have been saved will have this problem when the page is viewed with Firefox 4. To repair the page for Firefox 4 viewing simply edit and save the page. -Jim - Apr 22, 2011

Return to "Pdf Export Dompdf" page.