Extension talk:Pdf Export/archive 4

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

Previous page history was archived for backup purposes at Extension talk:Pdf Export/LQT Archive 1 on 2015-07-10.

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

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 ?

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

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

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

Call to undefined method Article::preSaveTransform()  Backtrace: mediawiki 1.27

please anybody have solution ?

Fatal error: Call to undefined method Article::preSaveTransform() in /home/toor/www/extensions/PdfExport/converters/PrincePdfConverter.php on line 114

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

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.

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

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

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().

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?

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.

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, '_', ' ');

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

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.

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

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

$options['permissions'] = '';