Extension talk:Pdf Export/archive 4/Flow export

archives of this page: archive 1, archive 2, archive 3

Multiple pages, page breaks.

Hi,

The extension allows for the dumping to PDF of multiple pages at once, but does not put a page break in between pages. Any advice on this?

Cheers. 193.61.220.3 10:49, 18 April 2011 (UTC)

how do you dumping to PDF of multiple pages at once ? thank 213.140.2.6 09:18, 20 March 2013 (UTC)

file type not supported or pfd-file is corrupted

Hi, I get the above mentioned error message as soon as I would like to open the generated file with Acrobat Reader. I am using 2.4.2 version of this extension. Versions prior to that do not even generate a file. Help would be cool. Cheers [[kgh]] 08:49, 24 June 2011 (UTC)

I have the same problem. Using the following environment:

Windows XP Easy PHP 5.3.1.0

MediaWiki 1.16.4

PdfBook Version 1.0.4, 2010-01-05

HTMLDOC 1.8.27
52.129.12.51 20:00, 11 July 2011 (UTC)

Hi,guys

I have the same problem.Can anybody help us? 15.203.233.79 06:37, 15 July 2011 (UTC)

I also have the same problem. Kindly give the solution if any one have Gagansh 10:01, 19 January 2012 (UTC)

I also have the same problem. Kindly give the solution if any one have Gagansh 10:01, 19 January 2012 (UTC)

Are you all still getting this error message? If you try to open the corrupt PDF document in Notepad or some other text error, you might see the actual error message generated by HTMLDoc. Cneubauer (talk) 19:14, 9 July 2012 (UTC)

As the first poster to this thread I can confirm that I do not get this any longer. I am working with HTMLDOC 1.8.27 now. Great. I am so happy about this. [[kgh]] (talk) 21:38, 9 July 2012 (UTC)

I am using HTMLDOC 1.8.27 and still receiving this error. Dgennaro 17:47, 2 October 2012 (UTC)

subtitle in footer

in the footer on the left side there is always a subtitle of the page displayed, is there any way to remove it? I guess it must be something like "$parserOptions->setWhatever(false);"

but I have no idea which parser option it is

can someone please help tanks a lot 79.222.111.77 00:48, 27 October 2011 (UTC)

No umlauts in German wiki

Hello, the Extension works Fine.

But in the generated PDF all Letters with German Umlaut (Ü,Ö,Ä,) are left Blank.

How i can i fix this? 217.6.192.236 14:06, 6 February 2012 (UTC)

The HTMLDoc backend doesn't handle UTF-8 characters. Try the mPdf backend in the latest version of the extension. Cneubauer (talk) 19:12, 9 July 2012 (UTC)

I cannot confirm this. I just tried to print "ÄäÖöÜüà߀@°" with HTMLDoc and this worked perfect for me. Besides, it so cool to see this extension revitalised. Lots of kudos and thank you to you, Cneubauer!! [[kgh]] (talk) 21:35, 9 July 2012 (UTC)

Hmm, good to know. I wonder if they updated HTMLDoc at some point to handle that? Cneubauer (talk) 11:37, 10 July 2012 (UTC)

Probably they are not only encodable in UTF-8, since this feature is indeed due in the future HTMLDOC 1.9.x. The ones I indicated are the special characters you need in German, but I also successfully tested some French, e.g. "Ççî" and Spanish, e.g. "Ññ" special characters. However, it starts to get nasty with e.g. œ. There probably must have been another problem with the wiki of the IP which started this thread. Perhaps it has something to do with the collation used? [[kgh]] (talk) 18:42, 10 July 2012 (UTC)

Internal links

I cannot use PDF Book as I have a stand alone server and don't have the technical knowledge to install a render server. PDF_Export does the job in that I have a single page that pulls in all the pages I need to assemble into a pdf in the right order when I click Print PDF. The code in the page makes each new page title a section heading and adds a page break before this title. This makes the pdf look like it should and the contents look ok (rather than all page sections being at level 2).

It is a shame that the links to other pages in the WIKI are kept pointing to the WIKI. I would like them to point to the added section bookmarks (which I suppose could be added in my "assemble page" file).

Is anyone doing any work to cover this sort of functionality or is it too difficult? 82.110.109.212 14:53, 14 February 2012 (UTC)

Special:PdfPrint does not work

Heiya, whereas Special:PdfPrint&Page=Example triggered via the sidebar works perfect it is not possible to go to Special:PdfPrint via Special:SpecialPages. Intuitively I am expecting a form there that allows you to provide the name of the page(s) to be printed to together with some printing options to choose form. I think that is how the extension worked before, but I am not absolutely sure. To cut a long story short I get <pre>From MyWiki Failed to generate Pdf with HTMLDoc. Please notify the system administrators and check the logs From „https://www.mywiki.com/wiki/Special:PdfPrint“</pre> The error log, however does not log anything, not even a warning. I am working with MW 1.18.4, PHP 5.3.8 and HTMLDOC 1.8.27 Cheers [[kgh]] (talk) 22:10, 9 July 2012 (UTC)

Yeah I see that. I must have broken it at some point. I'll take a look today. Thanks for the report. Cneubauer (talk) 11:36, 10 July 2012 (UTC)

Okay, I fixed it. Note: Not all the form options are going to do something with all the backends. For example, some support margins right now and some don't. I'm going to try to fix that in the future. Cneubauer (talk) 13:11, 10 July 2012 (UTC)

I just successfully tested it, however without getting into all the option details. Thank you for looking into this. [[kgh]] (talk) 18:26, 10 July 2012 (UTC)

Printed pages are always displayed in the same tab or window

This might already be a feature suggestion. I think it is better to do the printouts in a separate tab or window since people intuitively close the window after the print is done an thus also close the website. [[kgh]] (talk) 19:55, 10 July 2012 (UTC)

There is a global variable you can set to make the PDFs pop up as a downloadable attachment instead of in the same browser window. Its:

$wgPdfExportAttach = true;

Does that work for you? Cneubauer (talk) 12:09, 11 July 2012 (UTC)

Affirmative, this works. This is a good solution. :) Thus providing a different filename on Special:PdfPrint works too now. Before it has not. [[kgh]] (talk) 14:05, 11 July 2012 (UTC)

Additional parameters to control the bahaviour of this extension

I think it would be good to have some parameters to further control the standard behaviour of this extension.

1. A parameter to set the text to be shown in the header
2. A parameter to set the text to be shown in the footer
3. A parameter to set the standard paper format, e.g. letter or A4
4. A parameter to snow the advanced options i. e. document restrictions (password protection, allow modification etc.) to users on Special:Pdfexport or not [[kgh]] (talk) 20:29, 10 July 2012 (UTC)

The default paper size is controlled by the MediaWiki:Pdf_size_default system message so you can change that to A4 instead of Letter if you like. I'll add the others to the todo list. Thanks for the requirements. Cneubauer (talk) 12:14, 11 July 2012 (UTC)

I knew that there must already have been a possibility to control the paper format. I documented this on the extension's page. Thank you for considering the other suggestions. Cheers [[kgh]] (talk) 14:25, 11 July 2012 (UTC)

Controlling the header and footer text is an absolute must before we can deploy this tool, otherwise awesome work!

Also wanted to add to the request list: ability to mark page breaks so you can control exactly what goes on which page when you print the pdf. 173.167.102.97 18:56, 18 October 2012 (UTC)

I added it to the list. I really need to get some other developers working on this. I don't really have the time these days to add large new features. Cneubauer (talk) 10:39, 19 October 2012 (UTC)

I'd really like to see all the options in htmldoc exposed in the Special Page, but in particular --book. Also, though I guess this is more a question for htmldoc, I would like loseless reduction of oversize images so that I can zoom into the image on the.pdf. Teskeyn (talk) 14:00, 18 July 2013 (UTC)

It would be nice if you could control the page size/margins. When printing from some skins, they will overprint page titles on top of standard print web pages headers and footers. I'd like to keep the standard headers and footers and use the headings and titles produced by skins.

A simple solution might be simply to reduce the top and bottom margins of the pdfexport output so that it doesn't overwrite web page headers and footers produced by apache or browser settings. Loonybomber (talk) 01:30, 14 June 2015 (UTC)

MWlib and none-viewable mediawiki for anonymous users

I had a hard time figure out the installation instructions to use PdfExport with MWlib on Ubuntu 12.04 (LTS) for my wiki which is just readable for logged in users. I would like to share my experience so that others might spend less time for using PdfExport with MWlib:

1. go to your extensions directory, e.g. /var/www/wiki/extensions, and type

   git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/PdfExport.git

2. install MWlib to /tmp/pp (not nice, but it works, since I couldn't solve the access permission errors and incompatibilities between the public distributed python libraries with MWlib):

   sudo apt-get install -y gcc g++ make python python-dev python-virtualenv libjpeg-dev libz-dev libfreetype6-dev liblcms-dev libxml2-dev libxslt-dev ocaml-nox git-core python-imaging python-lxml texlive-latex-recommended ploticus dvipng imagemagick pdftk
   
   virtualenv --distribute --no-site-packages /tmp/pp
   export PATH=/tmp/pp/bin:$PATH
   hash -r
   export PIP_INDEX_URL=http://pypi.pediapress.com/simple/
   pip install pil
   pip install pyfribidi mwlib mwlib.r
   

3. create a user, e.g. PdfExport, for PdfExport who has read permission for the wiki
4. add to the file LocalSettings.php, e.g. in /var/www/wiki/, the following lines:

   # PdfExport
   # http://www.mediawiki.org/wiki/Extension:Pdf_Export
   require_once("$IP/extensions/PdfExport/PdfExport.php");
   $wgPdfExportMwLibPath = '/tmp/pp/bin/mw-render --user=PdfExport --password=...';

   Christophjahn (talk) 15:01, 24 August 2012 (UTC)

Syntax error: "unexpected token" and "unexpected EOF"

I noticed two errors when generating PDF files when title page (article) in the MediaWiki have "'" or "(", ")" characters:

• Syntax error: "unexpected token"
• "unexpected EOF"

For example, if the page title is "Foo_(bar)" then I get the following error message:

sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `/usr/bin/mw-render --config http://mywiki/w/ --output /tmp/mw-pdf-lJVlIa --writer rl Foo_(bar)'

Second example, if page title is "Foo_BAR's", then I get the following error message:

sh: -c: line 0: unexpected EOF while looking for matching `
sh: -c: line 1: syntax error: unexpected end of file

Note This is also huge security issue, because users that can create new articles and render them via that extension, may be able to run certain shell commands on MediaWiki server. (source: mwlib mailing list)

I've using the following environment:

• MediaWiki: 1.19.0
• PdfExport: 3.0.1
• CentOS: 6.3 (final)
• * PHP: 5.3.3 Scottie33 (talk) 09:52, 5 September 2012 (UTC)

Yep, it's not escaping the shell argument properly. I'll commit a fix. Thanks for the report. Cneubauer (talk) 12:03, 5 September 2012 (UTC)

SLES 11 SP2 - Special:PdfPrint does not work

i installed MediaWiki 1.19.2, PdfExport (Version 3.0.1), PHP 5.2.14 (apache2handler). PdfExport show the point "Als PDF-Datei ausgeben". But it doesn't work. No Error message, no entry in logfile. 193.97.177.2 09:07, 20 September 2012 (UTC)

it was a problem with the browser configuration. 193.97.177.2 12:42, 20 September 2012 (UTC)

Added Croatian translation

https://bugzilla.wikimedia.org/show_bug.cgi?id=41525 109.60.105.125 02:18, 30 October 2012 (UTC)

Error after upgrade to MediaWiki 1.21.0

After uploading to MediaWiki 1.21.0 I get following error (due to API changes, I think):

PHP Fatal error:  Call to undefined function wfLoadExtensionMessages() in /srv/www/htdocs/wiki/extensions/PdfExport/PdfExport.php on line 83

Any quick fix available? Ralfk (talk) 06:30, 28 May 2013 (UTC)

Well, wfLoadExtensionMessages() has just been removed from GlobalFunctions.php. It has been replaced by wfMsgExt() which has been replaced by wfMessage(). See Manual:Messages_API#Old_wfMsgExt. After replacing wfLoadExtensionMessages() by wfMessage() this extension works again. However, don't know the purpose of the original wfLoadExtensionMessages() call at all, since I am not familiar with the MW API. Ralfk (talk) 07:45, 29 May 2013 (UTC)

From what I have learned this line containing wfLoadExtensionMessages() may be removed entirely, so no need for replacements. [[kgh]] (talk) 16:33, 7 January 2014 (UTC)

It does not appear in the Sidebar

Hello,

Thanks for creating this extension, it must be very helpful. But I'm having trouble installing it: it does not appear in the sidebar.

I've created the 4 files in the right folder and completed the localsettings (I've installed other extensions before, but obviously, I'm not doing things right here) but nothing appears.

It's the same when I want to go to Special:PdfPrint , it says that it doesn't exist...

Where could this problem come from?

I've got another question, that might be related, but I don't think so. Your code is pasted without the closing '?>' each time. Is it normal?

I've tried anyway with and without it but it doesn't work.

Thanks a lot for your help and your module =)

Gérald 77.193.227.25 09:32, 30 May 2013 (UTC)

Hello,

I've installed htmldoc on the server and it might solve the problem. I say this because a bigger problem has occured :D

I've got an error message that says that wfLoadExtensionMessages() is undefined. I've read that this error is common with extensions, because this function was used and was part of the trunk and apparently is no longer.

Am I right? I can't figure out if it's MW that is outdated or the extension :/

Thanks a lot

Gerald 77.193.227.25 14:42, 30 May 2013 (UTC)

MWlib issues

I had different issues using this extension with MWlib:

• function wfLoadExtensionMessages seems to be no longer supported by mediawiki 1.21, changed to wfMessage
• mw-render of an URL fails to connect for some reason, however mw-zip works correctly. So I changed the MwLibPdfConverter.php to first fetch the URL with mw-zip and then mw-render the resulting zip-file.
• wiki authentication not supported by extension.

I added authentication support to MwLibPdfConverter.php by adding support for $wgPdfExportUsername, $wgPdfExportPassword and $wgPdfExportDomain variables

• Could not generate PDFs for pages with spaces in their name.

This is because $skintemplate->thispage is used, which returns the page title with underscores instead of spaces. Replacing this by $skintemplate->titletxt solved the problem, as mw-zip seems to need the actual page title and not the page url.

My changes:

Extended content

to file converters/MwLibPdfConverter.php --- MwLibPdfConverter.php 2013-03-11 21:33:19.000000000 +0100 +++ MwLibPdfConverter.php 2013-06-06 10:40:14.000000000 +0200 @@ -24,6 +24,9 @@ */ function outputPdf($pages, $options) { global $wgPdfExportMwLibPath; + global $wgPdfExportUsername; + global $wgPdfExportPassword; + global $wgPdfExportDomain; global $wgPdfExportAttach; global $wgOut, $wgServer, $wgScriptPath; @@ -42,10 +45,27 @@ // TODO gather output $tmpFile = tempnam(sys_get_temp_dir(), 'mw-pdf-'); $output = array(); - exec($wgPdfExportMwLibPath.' --config '.$wgServer.$wgScriptPath.'/ --output '.$tmpFile.' --writer rl '.escapeshellarg($page), $output); + $auth = ""; + + if ($wgPdfExportUsername && $wgPdfExportPassword) { + $auth = "--username='$wgPdfExportUsername' --password='$wgPdfExportPassword'"; + if ($wgPdfExportDomain) { + $auth .= " --domain='$wgPdfExportDomain'"; + } + } + + error_log($wgPdfExportMwLibPath.'/mw-zip --config '.$wgServer.$wgScriptPath.'/ '.$auth.' --output '.$tmpFile.'.zip '.escapeshellarg($page)); + exec($wgPdfExportMwLibPath.'/mw-zip --config '.$wgServer.$wgScriptPath.'/ '.$auth.' --output '.$tmpFile.'.zip '.escapeshellarg($page), $output); + error_log($wgPdfExportMwLibPath.'/mw-render --config '.$tmpFile.'.zip --output '.$tmpFile.' --writer rl '.escapeshellarg($page)); + exec($wgPdfExportMwLibPath.'/mw-render --config '.$tmpFile.'.zip --output '.$tmpFile.' --writer rl '.escapeshellarg($page), $output); readfile( $tmpFile ); + unlink( $tmpFile.'.zip' ); unlink( $tmpFile ); + + foreach ($output as $line) { + error_log($line); + } } /** to file: PdfExport.php --- PdfExport.php 2013-03-11 21:33:19.000000000 +0100 +++ PdfExport.php 2013-06-06 10:54:23.000000000 +0200 @@ -80,17 +80,17 @@ $img_page = strpos($skintemplate->titletxt, "File:"); // only display for an article, not an image if ($img_page > 0 || $img_page === false) { - wfLoadExtensionMessages('PdfPrint'); + wfMessage('PdfPrint'); $nav_urls['pdfprint'] = array( 'text' => wfMsg('pdf_print_link'), - 'href' => $skintemplate->makeSpecialUrl('PdfPrint', "page=".wfUrlencode("{$skintemplate->thispage}" )) + 'href' => $skintemplate->makeSpecialUrl('PdfPrint', "page=".wfUrlencode("{$skintemplate->titletxt}" )) ); } return true; } function wfSpecialPdfToolbox (&$monobook) { - wfLoadExtensionMessages('PdfPrint'); + wfMessage('PdfPrint'); if (isset($monobook->data['nav_urls']['pdfprint'])) if ($monobook->data['nav_urls']['pdfprint']['href'] == '') {  ?><li id="t-ispdf"><?php echo $monobook->msg('pdf_print_link'); ?></li><?php

Hope it can help someone.. or help improve this extension. 193.190.131.67 10:26, 6 June 2013 (UTC)

Unable to generate PDF when using the Toolbar on side

I noticed a problem with thew ExportPdf extension, If I try to generate the page I'm viewing, ie: http://WIKI_SITE/w/index.php?title=Special:PdfPrint&page=My_Document_Page

It fails and generates a dummy PDF with nothing really in it. If I go to the Special page manually then in the 'Enter the title of the page you want to export to PDF' put the *actual* document title 'My Document Page' it works, is this a known issue? If so, is there any workarounds?

Thanks 70.52.198.236 13:39, 22 July 2013 (UTC)

This seems to be related to the underscore‒space equivalence/conversion in Mediawiki. A workaround that does the job in my case is to add, between the following two lines in extensions/PdfExport/PdfExport_body.php,

if ($dopdf) {

$wgOut->setPrintable();

(approx. line 111) the new line

array_walk($pages, function(&$val, $key) {$val = strtr($val, '_', ' ');});

which converts underscores to spaces.

This requires PHP ≥ 5.3 because of the anonymous function (a. k. a. closure) created by the function keyword, but it could easily be rewritten using create_function(). 216.165.126.125 22:56, 13 September 2013 (UTC)

I have a similar problem in our Wiki. (It's german btw) The spaces are not a big deal in our Wiki, but when I'm trying to export a PDF with umlauts (äöü) in the title, I get the same empty document as the thread opener. Do you have an idea how to fix this? 178.15.192.35 07:45, 8 May 2014 (UTC)

Today I found a solution for this. If you're using the MwLibPdfConverter.php you can add

setlocale(LC_CTYPE, "en_US.UTF-8");

at line 5. After this the PDF were created correctly. 178.15.192.35 13:40, 9 May 2014 (UTC)

I had the same issue with MwLibPdfConverter.php but the setlocale did not fix my issue.

Instead I modified it on line 45 to include this:

$page = strtr($page, '_', ' '); Sorvis (talk) 19:34, 28 June 2016 (UTC)

Cannot install extonsion on mediawiki 1.21

Hi all, when I downloaded and install this extension, I cannot run my wiki because of HTTP 500 internal error. When I removed it (#in LocalSettings.php) it works again. I tried with htmldoc and with DomPdf, and nothing. I'm running on Centos 6.4 and I have installed theese extensions: ApprovedRevs, FlaggedRevs

Do you have some idea where should be problem? Thank you

Ivo 89.24.108.68 12:59, 23 July 2013 (UTC)

I'm having the same issue with version 1.21.1. It appears that any page that has the sidebar link for this extension cannot be rendered. 173.29.96.180 04:08, 26 July 2013 (UTC)

FIXED: Once I found the switch to turn on display of PHP errors I discovered that I was running into this problem with a removed function call. After updating PdfExport.php and PdfExport_body.php the extension seems to be working fine with DomPdf. 12.206.93.194 16:03, 26 July 2013 (UTC)

Custom PDF template

I would like to export articles to PDF using a custom template (including a cover page with the article title, custom headers/footers, watermarks...).

Do you have an estimation when this feature could be available? Thanks in advance. 84.233.177.18 08:56, 26 July 2013 (UTC)

Whenever you write it. 207.228.113.178 19:17, 14 August 2013 (UTC)

Bug in PdfConverterFactory

Hi there,

Today I installed this plugin, but not without some hassle! I found a bug in converters/PdfConverterFactory.php:

                if ($wgPdfExportHtmlDocPath) {
                        $output = array();
                        $return_val = null;
                        exec($wgPdfExportHtmlDocPath.' --version', $output, $return_val);

                        if ($return_val === 0) {
                                return new HtmlDocPdfConverter();
                        }
                }

should be:

                if ($wgPdfExportHtmlDocPath) {
                        $output = array();
                        $return_val = null;
                        exec($wgPdfExportHtmlDocPath.' --version', $output, $return_val);

                        if ($return_val !== 0) {
                                return new HtmlDocPdfConverter();
                        }
                }

note the === and !==. Now the code works like a charm, thanks! 212.123.142.155 13:56, 17 September 2013 (UTC)

Any non zero return value is an error. The code should not be changed as above. 59.99.217.217 (talk) 10:58, 20 October 2015 (UTC)

Where and how to install MWLib?

Where should the MWLib folder be installed? Does the usr/bin/mw-render folder need to be created and then have the mwlib-0.15.12 dropped in there? Sorry for the rookie question; I know enough of how to edit the php files, but not always where the files need to be saved if not in the extensions folder. 70.168.60.66 17:03, 15 November 2013 (UTC)

Crash for customized TOC

Sometimes if we specify something like this:

<div class="fright">__TOC__</div>

Because the getPageHtml() function will add a magic word __NOTOC__ to eliminate the TOC before parsing it to the converter, the customized TOC will not be eliminated. Therefore, custom TOC will be printed and floating TOC will crash the export. I am looking for a possible fix. Joshua.yathin.yu (talk) 09:49, 20 November 2013 (UTC)

Solution found:

Go to your PdfExport\converters\xxxxxConverter.php (I am using DomPdfConverter.php here), make some changes:

	function getPageHtml($page, $options) {
		...
		//$parserOutput = $wgParser->parse( $article->preSaveTransform( "__NOTOC__\n\n".$article->getContent() ) ."\n\n", $title, $parserOptions ); <- This is the original code. The next line is the modified code.
		$parserOutput = $wgParser->parse( $article->preSaveTransform( "__TOC__\n\n".str_replace('__TOC__', '', $article->getContent()) ."\n\n"), $title, $parserOptions );

Then, the custom TOC will be removed before printing.

Besides, you may also want to customize the printing so that the TOC will always be in a certain style. It you want to do so, change the __NOTOC__ into __TOC__ to force a TOC to display at the beginning of the page.

e.g.

	function getPageHtml($page, $options) {
		...
		//$parserOutput = $wgParser->parse( $article->preSaveTransform( "__NOTOC__\n\n".$article->getContent() ) ."\n\n", $title, $parserOptions ); <- This is the original code. The next line is the modified code.
		$parserOutput = $wgParser->parse( $article->preSaveTransform( "__TOC__\n\n".str_replace('__TOC__', '', $article->getContent()) ."\n\n"), $title, $parserOptions );

Because the magic word __TOC__<nowiki> will render a <nowiki><div class="toc" id="toc">, the style and id cannot be customized unless overwriting the original styles. And achieving this isn't really brute-force.

Go to your xxxxConverter.php,

	function getPageCss($page, $options) {
		global $wgServer, $wgScriptPath;
		
		return '<link rel="stylesheet" href="'.$wgServer.$wgScriptPath.'/extensions/PdfExport/converters/PdfExport.css?207" type="text/css" media="screen" />'. // Just add this line here.
		'<link rel="stylesheet" href="'.$wgServer.$wgScriptPath.'/skins/vector/main-ltr.css?207" type="text/css" media="screen" />'.
		'<link rel="stylesheet" href="'.$wgServer.$wgScriptPath.'/skins/common/shared.css?207" type="text/css" media="screen" />'.
		'<link rel="stylesheet" href="'.$wgServer.$wgScriptPath.'/index.php?title=MediaWiki:Common.css&amp;usemsgcache=yes&amp;ctype=text%2Fcss&amp;smaxage=18000&amp;action=raw&amp;maxage=18000" type="text/css" media="all" />';
	}

And then, go to the directory /extensions/PdfExport/converters/ and open a new file called PdfExport.css. Within it, define your stuff, like this:

#toc a {
	color: black;
	text-decoration: none;
}

The above code will render a table of contents without the underlining and blue colour. You are free to customize it this way.

Also, while you are at it, you may also want to enable printing the title of the page.

Go back to the xxxxConverter.php, change the modified line further to include something like this:

$parserOutput = $wgParser->parse( $article->preSaveTransform( "<p style=\"text-align: center; font-size:xx-large;\"> '''{{PAGENAME}}'''</p>\n\n__TOC__\n\n".str_replace('__TOC__', '', $article->getContent()) ."\n\n"), $title, $parserOptions );

This will display an xx-large, bold and centred title on top of the Pdf. Joshua.yathin.yu (talk) 03:25, 21 November 2013 (UTC)

How to export a group of wiki pages ?

The Overview paragraph suggests that it is possible to output a group of wiki pages to a single PDF file by using the “PDF Export” special page. What syntax is to be used to enter a list of pages in this special page?

I didn't find a documentation on this.

Thanks for any help/pointer on this

Thierry 88.137.115.134 22:58, 27 January 2014 (UTC)

Use Collection extension 186.59.110.211 00:42, 19 March 2015 (UTC)

Score extension

Pdf export should consider the new Extension:Score. At the moment only source code is printed, but actually the notes should be rendered.--Sinuhe20 (talk) 21:24, 4 April 2014 (UTC)

Syntaxhighlight

Using GeSHi syntaxhighlighter, I want the rendered PDF to have the same colored output.

Was this attempted by others? Where should I begin? Pestaa (talk) 07:23, 15 July 2014 (UTC)

MW 1.23 -> MW 1.24

After updating from MW 1.23 to 1.24 the extension stopped working (using the htmldoc converter) due to method userCanRead() not existing any more. In order to work under MW 1.24 I had to change file PdfExport/converters/HtmlDocPdfConverter.php from

if (is_null($title) || !$title->userCanRead()) {

to

if (is_null($title) || !$title->userCan('read')) { Ralfk (talk) 08:05, 15 December 2014 (UTC)

In MW 1.19 in the file /usr/share/mediawiki/includes/Title.php the following method is available:

public function userCanRead() {

        wfDeprecated( __METHOD__, '1.19' );

        return $this->userCan( 'read' );

    }

This can be used in later versions to allow such legacy extensions to work. 59.99.217.217 (talk) 12:10, 20 October 2015 (UTC)

noprint

I have an Infobox (e.g. DIN) and I don't want it to be displayed in the PDF document. Is there a possibility do to declare a part of a page as no printable? If possible how can I do this?

Thank you in advance

Michael 80.152.167.153 13:57, 25 February 2015 (UTC)

Htmldoc - permissions incorrectly set

Using MW 1.24.1 with htmldoc it seems that the 'permissions' option is incorrectly set in the converter.

The code initially sets the permissions option to null, It then adds the permissions prefixing them with '--permissions' (e.g. '--permissions no-modify'). However, when it comes to execute the htmldoc process it uses "'--permissions '.$permissions". this produces a command-line containing (for example) '--permissions --permissions no-modify').

In our case we didn't set any permissions, but did set the paper size (which follows permissions) to A4. This failed and always produced a Letter sized PDF. Dumping the command-line out showed that the permissions option was still being used - e.g. '--permissions --size A4'. I assume that htmldoc barfed on this and ignored the A4 size option. So a default needed to be set.

I used the following patch to correct the problems:

--- HtmlDocPdfConverter.php.orig        2014-12-01 23:15:27.000000000 +0000
+++ HtmlDocPdfConverter.php     2015-03-03 14:21:21.455341787 +0000
@@ -43,9 +43,9 @@
                                $perms[] = 'no-annotate';
                        }
                        if( count( $perms ) == 0 ) {
-                               $options['permissions'] .= '--permissions all --encryption';
+                               $options['permissions'] = 'all --encryption';
                        } else {
-                               $options['permissions'] .= '--permissions ' . implode( ',', $perms ) . ' --encryption';
+                               $options['permissions'] = implode( ',', $perms ) . ' --encryption';
                       }

                       if( $options['owner_pass'] !=  ) {
@@ -54,6 +54,8 @@
                       if( $options['user_pass'] !=  ) {
                               $options['permissions'] .= ' --user-password ' . $options['user_pass'];
                       }
+               } else {
+                       $options['permissions'] = 'all';
               }
       } 141.163.60.243 14:33, 3 March 2015 (UTC)

This has since been correcetd by initialising the said variable before the start of the if construct:

$options['permissions'] = ''; 59.99.217.217 (talk) 12:04, 20 October 2015 (UTC)

MW 1.26 PHP7 PrinceXML PdfExport 3.2.0 - ParseError / preg_replace

Due to security issues the modifier /e of the method preg_replace is not supported in PHP7 anymore.

I use a Windows Server 2012 R2 with PrinceXML.

The error occures in the PrincePdfConverter.php and suggest to use the new method preg_replace_callback.

This is the old code:

// set upper limit for width
   $bhtml = preg_place('/width="(\d+)"/e', "width=\"".($1 > $wgPdfExportMaxImageWidth ? $wgPdfExportMaxImageWidth : $1). "\"", $bhtml);

I got a ParseError while changing the code to:

//set upper limit for width
   $bhtml = preg_replace_callback ('/width="\d+"/', 'replaceCallback', $bhtml);
       
   function replaceCallback() {
           
        return "width=\"".($1> $wgPdfExportMaxImageWidth ? $wgPdfExportMaxImageWidth : $1)."\"";
           
   }

The $wgPdfExportMaxImageWidth variable is a global one. Does anyone know a bit PHP and can help me ?

PHP Manual - preg_replace

PHP Manual - preg_replace_callback Lanthanis (talk) 14:13, 5 July 2016 (UTC)

Extension:PdfExport not working with 1.28.0: Call to undefined method Article::preSaveTransform() in HtmlDocPdfConverter.php

Extension:PdfExport not working with 1.28.0 Call to undefined method Article::preSaveTransform() in HtmlDocPdfConverter.php 145.253.133.146 (talk) 08:13, 30 March 2017 (UTC)

Call to undefined method Article::preSaveTransform()  Backtrace: mediawiki 1.27 115.113.69.206 (talk) 06:11, 10 July 2017 (UTC)

please anybody have solution ? 115.113.69.206 (talk) 06:12, 10 July 2017 (UTC)

Fatal error: Call to undefined method Article::preSaveTransform() in /home/toor/www/extensions/PdfExport/converters/PrincePdfConverter.php on line 114 212.76.228.147 (talk) 13:28, 3 October 2017 (UTC)

Cant find the PDF Export Directory

I've installed htmldoc as instructed, but I get the following message: Warning: require_once(/opt/bitnami/apps/mediawiki/htdocs/extensions/PdfExport/PdfExport.php): failed to open stream: No such file or directory in /opt/bitnami/apps/mediawiki/htdocs/LocalSettings.php on line 179.

If I go to my extensions folder, I only see a PdfHandler, but not Export. Pointing it to handler does nothing and I also created the PdfExport folder myself, but of course nothing occurs. 63.85.203.102 (talk) 20:13, 19 April 2017 (UTC)

HELP PDF

the first case(Extension:PdfExport) gives me the link print as formate PDF, but when i click on, gives me an error that export as format pdf- error, means doesnt find any convertion pdf and explain that i need to install PrinceXML, DomPdf o HTMLDoc. but i install DomPDF and Html doc and PrinceXML and doesnt work

and the second case with Extension:ElectronPdfService

gives me the link print PDF but when i click on , told me that the service doesnt find the page Mariana duarte100 (talk) 18:40, 28 April 2017 (UTC)

Blank page when exporting

I installed PdfExport and htmldoc. I can see the link on the panel menu to export a page, but I have a blank page as a result.

When I use the Pdf Export special page and try to export after selecting the pages I want, I have a blank page too.

Does someone have any idea please ? 192.196.142.91 (talk) 13:35, 18 September 2017 (UTC)

The following worked for me. I commenting out the following line:

$bhtml = preg_replace('/width="(\d+)"/e', '"width=\"".($1> $wgPdfExportMaxImageWidth ? $wgPdfExportMaxImageWidth : $1)."\""', $bhtml);

In the file \wiki\extensions\PdfExport\converters\MPdfConverter.php Nischayn22 (talk) 08:32, 11 December 2017 (UTC)

Using Template as Header / Footer

Hello!

Has anyone an Idea how to use a template as Header/Footer? Or is there a possibilty to use variables set with Extension:Variables in Header/Footer?

Thank you in advance for yopur ideas or solutions.

Michael MZipperer70 (talk) 09:50, 12 October 2017 (UTC)

blank pdf when exporting pages with titles with spaces in them

I found a bug in PdfExport: REL1_30 (2017-09-21T22:16:05) where the pages only export to pdf if the page name is one word. For example:

   /MediaWiki/index.php?title=Special:Pdfprint&page=Page

exports fine, but

   /MediaWiki/index.php?title=Special:Pdfprint&page=Main_Page

exports an almost empty pdf.

The fix was to merely replace the underscores in the URL with spaces. To do this, I changed the following lines in PdfExport.php (in the extensions folder) from this:

       $nav_urls['pdfprint'] = array(
           'text' => $skintemplate->msg('pdf_print_link')->text(),
           'href' => $skintemplate->makeSpecialUrl('PdfPrint', "page=".wfUrlencode("{$skintemplate->thispage}"))

to this:

       $page_name=wfUrlencode("{$skintemplate->thispage}");
       $page_name_with_spaces=str_replace('_','%20',$page_name);
       $nav_urls['pdfprint'] = array(
           'text' => $skintemplate->msg('pdf_print_link')->text(),
           'href' => $skintemplate->makeSpecialUrl('PdfPrint', "page=".$page_name_with_spaces)

then run update.php 1.128.108.145 (talk) 05:24, 30 January 2018 (UTC)