Extension talk:Pdf Export Dompdf

PDFExport_body.php

Latest comment: 15 years ago1 comment1 person in discussion

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)Reply

A better solution

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

No Images

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

Not a bug

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 wikitext

Latest comment: 15 years ago3 comments2 people in discussion

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:

{|border="1"
|
# <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:

{|border="1"
|
test
|}

=test=

==test1==

==test2==

==test3==

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)Reply

Noted

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)Reply

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

Code has been updated

Latest comment: 16 years ago9 comments6 people in discussion

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.

Problems resolved with new version

Invalid argument supplied for foreach

i've got another problem with the extension, getting this warning: (I'm using MediaWiki 1.12.)

Warning: Invalid argument supplied for foreach() in D:\server\htdocs\Wiki\extensions\pdfExport\pdfExport.php on line 157

any ideas? 19:13, 26 November 2008 (UTC)

I have the same problem with MediaWiki 1.13.2 Msauter 14:15, 1 December 2008 (UTC)Reply

Class 'DOMPDF' not found

I've got dompdf and the extension both installed, but it looks like it's not picking up an include file somewhere. The configuration is right nearest I can tell also. I'm using MediaWiki 1.12. --N0ctrnl 21:01, 28 March 2008 (UTC)Reply

[Fri Mar 28 15:55:08 2008] [error] [client 10.1.1.1] PHP Fatal error:  Class 'DOMPDF' not found in /var/www/html/wiki/extensions/PdfExport/PdfExport.php on line 142, referer: http://server/wiki/index.php/Main_Page

From looking at the output (and experimenting with some includes), it looks like the dompdf/include/*.cls.php files aren't being loaded properly. If I manually include "$IP/dompdf/include/dompdf.cls.php", the DOMPDF class error goes away and another pops up. If I continue doing that with the cls.php files that hold each missing class, it continues to knock out class errors. The problem with that is that you'd have to include a ton of them in order to get it to work.

Now, the line in the dompdf_config.inc.php file has this line in it

function DOMPDF_autoload($class) {
  $filename = mb_strtolower($class) . ".cls.php";
  require_once(DOMPDF_INC_DIR . "/$filename");
}

That should pick up the right files that hold the class info unless I'm missing something. It just isn't. Then, after it has included all of them, the PdfExport.php file includes the dompdf_config.inc.php on line 183 with the following:

require_once("$IP/extensions/dompdf/dompdf_config.inc.php");

Anybody else seeing errors like this or can point me in the right direction to debug it? --168.166.124.100 21:25, 8 April 2008 (UTC)Reply

I have the exact same :

Fatal error: Class 'DOMPDF' not found in C:\wamp\mediawiki-1.10.0\extensions\PdfExport\PdfExport.php on line 142

but since php isn't my mother tong, I have a hard time debugging it. I dumbly used the code provided on the extension's page.

brice 05:56, 11 April 2008 (UTC)

==> ok, I got it from dompdf\dompdf_config.inc.php :

 /**
  * DOMPDF autoload function
  *
  * If you have an existing autoload function, add a call to this function
  * from your existing __autoload() implementation.
  *
  * @param string $class
  */

So I might try to add it to the mediawiki/include/AutoLoader.php file. but i sounds quite odd... I'll try

brice 213.30.139.168 08:03, 11 April 2008 (UTC)Reply

okay okay !! last but not least : http://sourceforge.net/forum/message.php?msg_id=4819436

so

if ( !function_exists("__autoload") ) {
  /**
   * Default __autoload() function
   *
   * @param string $class
   */
  function __autoload($class) {
    DOMPDF_autoload($class);
  }
}

becomes

if ( !function_exists("__autoload") ) {
  /**
   * Default __autoload() function
   *
   * @param string $class
   */
  function __autoload($class) {
    DOMPDF_autoload($class);
  }
} else {
	spl_autoload_register("DOMPDF_autoload");
}

and it now works like a charm.

brice 213.30.139.168 08:48, 11 April 2008 (UTC)Reply

Excellent work. I looked at the same thread on SF, but just couldn't get it working right away so I let it sit on the back burner. Kudos to you for getting it done. I like dompdf much better than the alternatives. N0ctrnl 16:01, 25 April 2008 (UTC)Reply

Excellent work indeed!!! But should this tip/hint not be put on the main page under install?!? I think this is not only a hint, it more an advice to fulfill the install instructions... I was searching around for about an hour until I found it here... --DrTrigon 20:12, 9 July 2008 (UTC)Reply

Okay - the above doesn't work for me. I edited dompdf_config.inc.php, replaced the autoloader with the code above and -it. I am still getting the same errors.

 The Class DOMPDF is not found in Pdfexport.php on line 142

My "helloworld.php" script for dompdf works, so I know its something the mediawiki environment is doing that is causing it to fail. Aside from editing dompdf_config.php is there anything else I can do?? --99.232.79.240 09:13, 17 December 2008 (UTC)Reply

class dompdf

add

require_once("extensions/PdfExport/PdfExport.php");

to your LocalSettings.php

Did that already. The extension wouldn't be loading up at all without it :) I've checked and double checked, and just can't figure out what's up. --N0ctrnl 18:47, 6 April 2008 (UTC)Reply

Keine Installation möglich / NO Installation possible

PHP sagt / PHP says: The Class DOMPDF is not found in Pdfexport.php on line 142

Fail to render a pdf if restricted access

Latest comment: 15 years ago1 comment1 person in discussion

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)Reply

Problem with images

Latest comment: 13 years ago1 comment1 person in discussion

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 : http://code.google.com/p/dompdf/wiki/FAQ

-- 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)Reply

Setup problems

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 dompdf_config.inc.php 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 files

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-'

Latest comment: 13 years ago2 comments2 people in discussion

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)Reply

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? 94.217.47.164 15:33, 11 May 2011 (UTC)Reply

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 images

Latest comment: 13 years ago3 comments3 people in discussion

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)Reply

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

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

http://www.yoursite.com/path/to/images/image.jpg

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 http://www.yoursite.com/w/images/a/a1/picture.jpg 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)Reply

Hope that helps:

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

Issue with Firefox 4

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