Last modified: 2014-11-04 08:01:46 UTC
Uploaded pdf's with no a4 aspect ratio are converted perfectly to png but on the preview they are stretched like a a4 page.
Created attachment 6990 [details] Shows how it looks like.
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.
(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?
(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.
But it isn't the best way when you try to use it with presentation slides.
(In reply to comment #5) > But it isn't the best way when you try to use it with presentation slides. why?
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.
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 {
(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.
(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
(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
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.
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?
Yes for poppler >= 0.20 https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/PdfHandler.git;a=commit;h=c870582fee1127b65e521fc4aeaa8bb5212b9dcb
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.
Problem reported on https://commons.wikimedia.org/wiki/COM:FORUM several times in the past few weeks for 1) https://commons.wikimedia.org/wiki/File:Yamaguchi_Soken_-_An_Album_of_People_of_Yamato.pdf 2) https://commons.wikimedia.org/wiki/File:Treffen_der_Redaktion_Chemie_-_Statistik.pdf 3) https://commons.wikimedia.org/wiki/File:Rauchwaren-Preis-Verzeichnis_Heinrich_Lomer,_Leipzig,_1913-1914-10.pdf
This file: https://pl.wikisource.org/wiki/Plik:Maryan_Smoluchowski-O_atmosferze_ziemi_i_planet.pdf is also still displayed with wrong aspect ratio. Any timeline to fix it?
