Extension talk:Pdf Export

Jump to: navigation, search

About this board

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

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
192.196.142.91 (talkcontribs)

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 ?

Reply to "Blank page when exporting"

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

4
145.253.133.146 (talkcontribs)

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

115.113.69.206 (talkcontribs)

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

This comment was hidden by 115.113.69.206 (history)
115.113.69.206 (talkcontribs)

please anybody have solution ?

Reply to "Extension:PdfExport not working with 1.28.0: Call to undefined method Article::preSaveTransform() in HtmlDocPdfConverter.php"
Mariana duarte100 (talkcontribs)

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

Reply to "HELP PDF"
63.85.203.102 (talkcontribs)

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.

Reply to "Cant find the PDF Export Directory"

MW 1.26 PHP7 PrinceXML PdfExport 3.2.0 - ParseError / preg_replace

1
Lanthanis (talkcontribs)

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

Reply to "MW 1.26 PHP7 PrinceXML PdfExport 3.2.0 - ParseError / preg_replace"

Unable to generate PDF when using the Toolbar on side

5
70.52.198.236 (talkcontribs)

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

216.165.126.125 (talkcontribs)

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

178.15.192.35 (talkcontribs)

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

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.

Sorvis (talkcontribs)

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

Reply to "Unable to generate PDF when using the Toolbar on side"
Ralfk (talkcontribs)

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')) {
59.99.217.217 (talkcontribs)

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.

Reply to "MW 1.23 -> MW 1.24"
141.163.60.243 (talkcontribs)

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';
               }
       }
59.99.217.217 (talkcontribs)

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

$options['permissions'] = '';

Reply to "Htmldoc - permissions incorrectly set"
212.123.142.155 (talkcontribs)

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!

59.99.217.217 (talkcontribs)

Any non zero return value is an error. The code should not be changed as above.

Reply to "Bug in PdfConverterFactory"

Additional parameters to control the bahaviour of this extension

7
Kghbln (talkcontribs)

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
Cneubauer (talkcontribs)

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.

Kghbln (talkcontribs)

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

173.167.102.97 (talkcontribs)

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.

Cneubauer (talkcontribs)

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.

Teskeyn (talkcontribs)

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.

Loonybomber (talkcontribs)

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.

Reply to "Additional parameters to control the bahaviour of this extension"