Extension talk:PdfHandler

→ PdfHandler Talk Archive

Previous page history was archived for backup purposes at Extension talk:PdfHandler/LQT Archive 1 on 2015-06-25.

On the file upload page for the PDF I see navigation buttons for next/previous pages, but I see no such navigation buttons on the page where the file is displayed. What am I doing wrong?

Does anyone have a modification of the extension to make click of the PDF when a page is specified to go to that page?

/mediawiki/index.php?title=File:Filename.pdf&page=25

to the following, to make the browser skip to the specified page?

/images/0/0b/Filename.pdf#page=25

I am able to do it in javascript, but the PHP evades me.

$("#file.fullImageLink").find("a:first").each(function() {
    $(this).attr("href", $(this).attr("href") + "#page=" + getUrlParameter("page"));
});

Use # instead of ...&page=25

PDFHandler extension is supposed to allow viewing of pdf files. However, this does not appear to be working as advertised.

We've gone through the troubleshooting area of MediaWiki for this plugin and double-checked the paths to PDF converters. We re-ran the maint scripts for images and image meta. We checked the logs.

There is no indication of errors other than the images not showing up.

MediaWiki 1.35.5
PHP 7.4.27 (fpm-fcgi)
MySQL 5.7.37-0ubuntu0.18.04.1-log
ICU 60.2
Lua 5.1.5
PDF Handler – (16eda4b) 20:58, 2022 January 23

Any help or suggestions would be appreciated.

Wild guess: Some Linux distributions (for example openSUSE) have disabled rendering of PDF files in their default ImageMagick config because it has been a steady source of security issues (for example "ImageTragick"). In openSUSE, you'd need to install the ImageMagick-config-7-upstream package to enable rendering of PDF files.

Note: I don't know if Ubuntu did something similar with the ImageMagick config.

If unsure, test if converting a PDF to an image in the shell works: convert foo.pdf foo.png

I have done this, and still can't get the extension to work. Any other ideas?

..check /etc/ImageMagick-<your_version>/policy.xml 

if <policy domain="coder" rights="none" pattern="PDF" /> means convert is not allowed to perform its job..

you might change rights="read | write"

but you should be aware and responsible of the security risks this might bring (as Cbolts mentioned)

PDFhandler is confirmed installed on Special:Versions, which returns all the required directories, and no extensions could be interfering with the install. What's the issue?

I am having this issue too. I have changed the settings in ImageMagick so that PDFs are able to be converted; verified this at the command line; verified that all 4 related utilities are working at the command line; run all the maintenance scripts; and...nothing.

..check /etc/ImageMagick-<your_version>/policy.xml 

if <policy domain="coder" rights="none" pattern="PDF" /> means convert is not allowed to perform its job..

you might change rights="read | write"

but you should be aware and responsible of the security risks this might bring (check post below from Cbolts)

Fehler beim Erstellen des Vorschaubildes: limit.sh: timed out executing command "('/usr/bin/gs' '-sDEVICE=jpeg' '-sOutputFile=-' '-sstdout=%stderr' '-dFirstPage=1' '-dLastPage=1' '-dSAFER' '-r150' '-dBATCH' '-dNOPAUSE' '-q' '/opt/mediawiki/images/7/7e/A.K.2023.pdf' | '/usr/bin/convert' '-depth' '8' '-quality' '95' '-resize' '800' '-' '/tmp/transform_96151e2ec90e.jpg')"

I already changed some settings but obviously not the right ones. What to do to get it work on a PDF file with A LOT of pixels in each direction?

I tried to achieve the same functionality like for example on the page in the commons File:PDF metadata.pdf having pdf browser in the single wiki page where it is possible to browse pdf file page by page by giving page number and go by using gallery tag and pdf handler. Unfortunately, it does not work it always shows only the first page, the end result was T220680 for pdf handler and gallery that went to T211754. Suggested hack from Russian wiki does not work. It really is blocking, the functionality works on the file page, it does not work using gallery tag but if it works on the file page, how to achieve it, is there any work around? Various PDFembed extensions are unusable. Thanks.

MW 1.31.1 running on Windows Server 2012 R2 IIS 8.5

I'm getting the following error (from $wgDebugLogFile output log file) for all execution of pdfinfo and pdftotext.

[exec] Error running "pdfinfo" "-enc" "UTF-8" "-meta" "C:/inetpub/wwwroot/w/images/f/f4/Phone_List.pdf": 'pdfinfo" "-enc" "UTF-8" "-meta" "C:' is not recognized as an internal or external command, operable program or batch file.

I'm not sure if this is the result of the new Shell framework introduced in 1.30, Manual:Shell framework, which replaces wfShellExec(). The debug log line before the error is:

[exec] MediaWiki\Shell\Command::execute: "pdfinfo" "-enc" "UTF-8" "-meta" "C:/inetpub/wwwroot/w/images/f/f4/Phone_List.pdf"

This seems to be related to this discussion Topic:Ugtwpe4lyuly6q98 regarding PHP, Windows and Shell.

In case someone else is having this issue of not seeing PDF and is running MW 1.31 on Windows Server 2012 R2.

1. I added the path to pdfinfo.exe and pdftotext.exe to System variables path (mine was C:\Program Files\xpdf-tools-win-4.00\bin64).
2. Then, I edit {mediawiki install path}/extensions/PdfHandler/includes/PdfImage.php function retrieveMetaData.

a. Replacing:

$cmdMeta = [
$wgPdfInfo,
'-enc', 'UTF-8', # Report metadata as UTF-8 text...
'-meta',         # Report XMP metadata
$this->mFilename,
];

with

$cmdMeta = "pdfinfo.exe -enc UTF-8 -meta " . $this->mFilename;

b. Replacing

$cmdPages = [
$wgPdfInfo,
'-enc', 'UTF-8', # Report metadata as UTF-8 text...
'-l', '9999999', # Report page sizes for all pages
$this->mFilename,
];

with

$cmdPages = "pdfinfo.exe -enc UTF-8 -l 9999999 " . $this->mFilename;

c. Replacing

$cmd = [ $wgPdftoText,  $this->mFilename, '-' ];

with

$cmd = "pdftotext.exe " . $this->mFilename;

It's a bit of a hack, but it works. This should last until the issue is properly fixed.

Thank you for the information. I have modified the code further to avoid pdfinfo and pdftotext from hanging. If anyone needs PdfHandler in Windows Server - you can download the modified extension at https://github.com/SeongMoon/MW-v1.31.1-PdfHandler-Windows-Server

I had a similar problem using ImageMagick 7.1.0-19 Q16-HDRI with MedaiWiki 1.37.1 on Windows 11. To fix it, in extensions\PdfHandler\includes\PdfHandler.php

Change this line:

$cmd .= " | " . wfEscapeShellArg(

$wgPdfPostProcessor,

"-depth",

"8",

"-quality",

$wgPdfHandlerJpegQuality,

"-resize",

$width,

"-",

$dstPath

);

To this: (i.e. move the "-" to the first thing after the $wgPdfPostProcessor, line):

$cmd .= " | " . wfEscapeShellArg(

$wgPdfPostProcessor,

"-",

"-depth",

"8",

"-quality",

$wgPdfHandlerJpegQuality,

"-resize",

$width,

$dstPath

);

I had this extension installed and working on two wikis. After upgrading each at different times (to 1.31.7 and 1.32), I later noticed that it is no longer rendering them on File: pages or anywhere else, and the File: pages now show a pop-up security warning (when you hover over the "application/pdf" text) which links to Special:MyLanguage/Help:Security/PDF_files -- but that page has no information about suppressing the warning.

I'm thinking that whatever is triggering the warning is preventing the extension from rendering the files, but I haven't been able to find any information about how to change that.

Does anyone have any information about this?

Thanks.

The first thing to do is to make sure your extensions are up to date as well.

The warning is about generic issues with the PDF format as a whole and has nothing to do with the configuration details of any individual website. It also shouldn't prevent the preview from displaying (see for example commons:File:JUA0680291.pdf, where both a preview of the PDF and the warning popup are visible). You should be able to hide the warning via CSS, though I've never done this myself so I can't advise on what classes or IDs you need to use. Unfortunately I can't provide any help with why the previews aren't displaying for you; I've had the same issue on a wiki of mine for a while.

Another extension does seem to have been causing the issue in at least one wiki, though it's not clear how the two were interfering with each other. Still investigating -- but PDFs on that wiki seem to be rendering properly now.

Which extension?

I think it was one of mine, not one that MW distributes.

Hello,

Im using approvedRevs to approve stuff on our wiki. So if I link to a file on a page it will display the latest approved version of it.

If I link to a pdf with PdfHander it will always displays the latest version.

Anyone using approvedRevs and managed to get PdfHandler only to display the latest approved version?

Thanks

I don't use it but suspect you are likely to get a reply much more quickly on the Extension talk:Approved Revs page.

Is there anything to watch out for here? Anything I can change? The files which aren't working show as 0 x 0 pixels. Thanks.