Page MenuHomePhabricator

PdfHandler: Incorrect aspect ratio of the preview images.
Closed, DuplicatePublic

Description

Author: helix

Description:
Uploaded pdf's with no a4 aspect ratio are converted perfectly to png but on the preview they are stretched like a a4 page.


Version: unspecified
Severity: enhancement
OS: Linux

Details

Reference
bz22194

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 10:50 PM
bzimport set Reference to bz22194.
bzimport added a subscriber: Unknown Object (MLST).

helix wrote:

Shows how it looks like.

Attached:

Bildschirmfoto_2010-01-20_um_22.36.32.png (588×503 px, 79 KB)

anon.hui wrote:

This occurs, when the orientation of pdf file is landscape, and imagemagick (my version is 7:6.3.7.9.dfsg1-2ubuntu1.1) auto rotate the image according that orientation.

helix wrote:

(In reply to comment #2)

This occurs, when the orientation of pdf file is landscape, and imagemagick (my
version is 7:6.3.7.9.dfsg1-2ubuntu1.1) auto rotate the image according that
orientation.

Is there any way to turn this off?

anon.hui wrote:

(In reply to comment #3)

(In reply to comment #2)

This occurs, when the orientation of pdf file is landscape, and imagemagick (my
version is 7:6.3.7.9.dfsg1-2ubuntu1.1) auto rotate the image according that
orientation.

Is there any way to turn this off?

This should be the prefer behavior, and PdfHandler should detect and handle these orientations?
Since Acrobat Reader also rotate the pages according to these orientations.

helix wrote:

But it isn't the best way when you try to use it with presentation slides.

anon.hui wrote:

(In reply to comment #5)

But it isn't the best way when you try to use it with presentation slides.

why?

helix wrote:

Ok I checked it again. Imagemagick works fine and generates a png picture with 424 x 300 pixel but MediaWiki tells me that the pdf has a resolution of 1.653 × 2.338 Pixel and displays the png preview like on the screen shoot I have uploaded.

d4nilo wrote:

This is not an MW/extension bug. Problem is that PdfHandler gets the PDF page dimension with a call to the pdfinfo command (an Xpdf tool). But pdfinfo returns the *physical* page dimension, not the *displayed* page dimension (i.e. it does not take into account the page rotation parameter; not really a bug, just a design choice).

Solutions are: 1) use something else and not pdfinfo 2) apply the following patch to pdfinfo.

Since development of Xpdf looks a bit stuck and this is not something that may justify a new release, I'm posting the following patch here (referred to v3.02, any patch level).

Tested working. Have fun.

Danilo

  • xpdf/pdfinfo.cc.old 2010-07-08 11:31:52.000000000 +0200

+++ xpdf/pdfinfo.cc 2010-07-08 13:20:51.000000000 +0200
@@ -92,6 +92,8 @@

int exitCode;
int pg, i;
GBool multiPage;

+ int r;
+ double xchg;

exitCode = 99;

@@ -194,6 +196,10 @@

for (pg = firstPage; pg <= lastPage; ++pg) {
  w = doc->getPageCropWidth(pg);
  h = doc->getPageCropHeight(pg);

+ r = doc->getPageRotate(pg);
+ if ((r != 0) && ((r % 180) != 0)) {
+ xchg = h; h = w; w = xchg;
+ }

if (multiPage) {
  printf("Page %4d size: %g x %g pts", pg, w, h);
} else {

andrew wrote:

(In reply to comment #8)

This is not an MW/extension bug. Problem is that PdfHandler gets the PDF page
dimension with a call to the pdfinfo command (an Xpdf tool). But pdfinfo
returns the *physical* page dimension, not the *displayed* page dimension (i.e.
it does not take into account the page rotation parameter; not really a bug,
just a design choice).

Solutions are: 1) use something else and not pdfinfo 2) apply the following
patch to pdfinfo.

Since development of Xpdf looks a bit stuck and this is not something that may
justify a new release, I'm posting the following patch here (referred to v3.02,
any patch level).

Tested working. Have fun.

Danilo

  • xpdf/pdfinfo.cc.old 2010-07-08 11:31:52.000000000 +0200

+++ xpdf/pdfinfo.cc 2010-07-08 13:20:51.000000000 +0200
@@ -92,6 +92,8 @@

int exitCode;
int pg, i;
GBool multiPage;

+ int r;
+ double xchg;

exitCode = 99;

@@ -194,6 +196,10 @@

for (pg = firstPage; pg <= lastPage; ++pg) {
  w = doc->getPageCropWidth(pg);
  h = doc->getPageCropHeight(pg);

+ r = doc->getPageRotate(pg);
+ if ((r != 0) && ((r % 180) != 0)) {
+ xchg = h; h = w; w = xchg;
+ }

if (multiPage) {
  printf("Page %4d size: %g x %g pts", pg, w, h);
} else {

Thanks for the info, where should this extra code be put?
Also, you mentioned to use an alternative to pdfinfo, can you suggest one?

Thanks a lot.

d4nilo wrote:

(In reply to comment #9)

Thanks for the info, where should this extra code be put?

  • Download Xpdf source code from http://www.foolabs.com/xpdf/download.html
  • Extract the sources in some folder and cd to that folder
  • Follow the instructions in the included INSTALL file and make sure the whole thing builds
  • Save what I posted above (from "--- xpdf/pdf..." to the end, inclusive) in a file named pdfinfo.patch in the current directory
  • Execute "patch -p0 < pdfinfo.patch"
  • Optionally, apply the other patches found on the download page with "patch -p1 < xpdf-3.02pl1.patch"
  • Build it and, optionally, install it (or just substitute your current pdfinfo -- found with "which pdfinfo" -- with the new one)

Also, you mentioned to use an alternative to pdfinfo, can you suggest one?

No, that's why I patched pdfinfo... :)
And anyway, any alternative would probably require a change in MW code.

Danilo

andrew wrote:

(In reply to comment #10)

(In reply to comment #9)

Thanks for the info, where should this extra code be put?

  • Download Xpdf source code from http://www.foolabs.com/xpdf/download.html
  • Extract the sources in some folder and cd to that folder
  • Follow the instructions in the included INSTALL file and make sure the whole

thing builds

  • Save what I posted above (from "--- xpdf/pdf..." to the end, inclusive) in a

file named pdfinfo.patch in the current directory

  • Execute "patch -p0 < pdfinfo.patch"
  • Optionally, apply the other patches found on the download page with "patch

-p1 < xpdf-3.02pl1.patch"

  • Build it and, optionally, install it (or just substitute your current pdfinfo
    • found with "which pdfinfo" -- with the new one)

Also, you mentioned to use an alternative to pdfinfo, can you suggest one?

No, that's why I patched pdfinfo... :)
And anyway, any alternative would probably require a change in MW code.

Danilo

Perfect, that worked a treat! Cheers very much!
Andrew

saibotrash wrote:

The pdf thumbnailing has a inconsistent behaviour:
http://commons.wikimedia.org/wiki/File:Feaux_de_Lacroix_-_%C3%9Cber_den_Anteil_des_Sauerlandes_an_den_grossgeschichtlichen_Bewegungen_des_sp%C3%A4teren_Mittelalters.pdf#filehistory See the second file version.

Either it shouldn't be rotated or the dimensions need to be adjusted, too. Currently it is strange. Okular shows the second pdf correctly. Why not MediaWiki? EXIF tags at jpegs are used for rotation now - apparently (and according to a discussion here http://commons.wikimedia.org/wiki/User_talk:Ras67#pdf_rotation ) they aren't fully for pdfs.

Newer versions of pdfinfo seem to include the patch from comment 8 and should therefore work. (I don't know what "newer versions" means in version numbers. My system has pdfinfo 0.18.0 from poppler and prints the correct size/rotation.)

That said: What about a simple solution that works for all pdfinfo versions? ;-)

ImageMagick generates "good" preview images, so PdfHandler could just read the size of the _preview images_ instead of using pdfinfo.

They'll include a slightly different patch - newer pdfinfo (starting with poppler 0.20) will report page rotation in addition to the page size.
See https://bugs.freedesktop.org/show_bug.cgi?id=41867
I've committed r103313 to support it. This commit should fix the bug.

d4nilo wrote:

Thanks for taking the time to properly fix this. At the time I posted the xpdf patch, I wasn't aware of the poppler fork. The change in the pdfinfo output was only justified for MW purposes and not as a public fix (where credits should've been given too :).

Also, I think in your r103313 you should check for rotations beyond 270 and below 0 (e.g., 450 or -90) like my original patch was doing. This is because the PDF Reference (at page 146 in version 1.7) only specifies that the value of a Rotate entry in a page object "... must be a multiple of 90", without stating any boundary.

Cheers!
Danilo

Ok, thanks, committed the check for any multiple of 90 in r103341.

Just to clarify, this is fixed?

By which I meant - is it possible/do we have plans to do it for earlier versions, or can this bug be closed.

  • Bug 33722 has been marked as a duplicate of this bug. ***
  • Bug 61373 has been marked as a duplicate of this bug. ***

Another example: https://commons.wikimedia.org/wiki/File:Carta_a_SUBTEL_ref_Wikipedia_Zero.pdf

(As in bug 61373, the thumbnail displays fine by itself:
https://upload.wikimedia.org/wikipedia/commons/thumb/f/f5/Carta_a_SUBTEL_ref_Wikipedia_Zero.pdf/page1-776px-Carta_a_SUBTEL_ref_Wikipedia_Zero.pdf.jpg , and also while embedded in this blog post with almost the same HTML: https://blog.wikimedia.org/2014/09/22/chilean-regulator-welcomes-wikipedia-zero/ . Makes one wonder whether it has to do with the "thumb tnone" or "thumbinner" CSS classes, which are not present on the blog.)

On wikimedia we are waiting on an update to the app servers, which im told will happen with hhvm update, which will allegedly be real soon now(tm).

There is another bug (+an rt ticket) somewhere with more details, but i dont know off hand and hard to find with from my phone.

Having trouble with this issue still. I've scoured the web for help on issue of improperly reported PDF rotation. We have many PDFs such as this one:
http://terdzod.tsadra.org/index.php/File:Terdzo-KA-006-ALT.pdf
With the dimensions being properly defined but not the rotation. This pdf thumbnail should be wider than high.
According to this bug, the newest versions of pdfinfo (xpdf) should have fixed this. But alas. We're running:
Product Version
MediaWiki 1.24.2
PHP 5.4.38 (apache2handler)
MySQL 5.6.21
pdfinfo version 3.04
ImageMagick 6.9.0-0 Q16 x86_64 2015-05-17
GPL Ghostscript 9.16 (2015-03-30)
We've tried to alter all sorts of image and thumbnail settings in LocalSettings, but still no luck.
Help?