Page MenuHomePhabricator

Image on Commons is not displayed in a generated PDF file
Closed, ResolvedPublic

Description

Author: Juergen.Thomas

Description:
One image that exists at Commons is not displayed in a PDF file generated by "Download as PDF". Please, check this bug:

1- File:Hydravulgaris.jpg on Commons: http://commons.wikimedia.org/wiki/File:Hydravulgaris.jpg
2- Go to de-Wikipedia "Süßwasserpolypen": http://de.wikipedia.org/wiki/S%C3%BC%C3%9Fwasserpolypen
3- Click on Print/Export - Download as PDF
4- Open the generated PDF file. Oops - where is the image?

The same "works" in de-Wikibooks, see http://de.wikibooks.org/wiki/Benutzer:Juetho/_Entwurf#Allgemein (as page) and http://de.wikibooks.org/w/index.php?title=Spezial:Buch&bookcmd=download&collection_id=76ca7cce3e4172e7&writer=rl (PDF created by Special:Book) in the section "Allgemein".

Other users confirmed the problem:

I have no idea why this image cannot be displayed (the one and only).


Version: unspecified
Severity: normal
OS: Windows 7
Platform: PC

Details

Reference
bz34611

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:19 AM
bzimport added a project: Collection.
bzimport set Reference to bz34611.

(In reply to comment #1)

please read http://www.gossamer-threads.com/lists/wiki/wikitech/271493

Not relevant. Swift was taken offline on the 14th http://noc.wikimedia.org/, problems were fixed and it was back on the Feb 17th (https://wikitech.wikimedia.org/view/Server_admin_log).

ralf_wikimedia wrote:

I'm reading the arrogant "not relevant" as "you don't have a
clue". I'm pissed cause I took the time yesterday to render the
collection and one of the images was truncated. We're still seeing
lots of errors from broken images.

btw, upload.wikimedia.org is currently serving corrupt thumb images
(see below). What makes you think that you solved the problem?

,----

wget -S http://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Commons-emblem-disambig-notice.svg/1200px-Commons-emblem-disambig-notice.svg.png
--2012-02-24 10:30:55-- http://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Commons-emblem-disambig-notice.svg/1200px-Commons-emblem-disambig-notice.svg.png
Resolving upload.wikimedia.org... 208.80.152.211
Connecting to upload.wikimedia.org208.80.152.211:80... connected.
HTTP request sent, awaiting response...
HTTP/1.0 200 OK
Last-Modified: Thu, 02 Feb 2012 17:10:31 GMT
Accept-Ranges: bytes
Content-Type: image/png
Content-Length: 102400
Date: Mon, 20 Feb 2012 03:49:30 GMT
Age: 366058
X-Cache: HIT from sq83.wikimedia.org
X-Cache-Lookup: HIT from sq83.wikimedia.org:3128
X-Cache: MISS from sq84.wikimedia.org
X-Cache-Lookup: MISS from sq84.wikimedia.org:80
Connection: keep-alive
Length: 102400 (100K) [image/png]
Saving to: `1200px-Commons-emblem-disambig-notice.svg.png'
100%[======================================>] 102,400 112K/s in 0.9s
2012-02-24 10:30:56 (112 KB/s) - `1200px-Commons-emblem-disambig-notice.svg.png' saved [102400/102400]
[py27] ~/t/ % md5sum 1200px-Commons-emblem-disambig-notice.svg.png
4a42cbe023060d011d6dc1f92572eb1c 1200px-Commons-emblem-disambig-notice.svg.png
[py27] ~/t/ % display 1200px-Commons-emblem-disambig-notice.svg.png
display: Expected 8192 bytes; found 3893 bytes `1200px-Commons-emblem-disambig-notice.svg.png' @ warning/png.c/MagickPNGWarningHandler/1754.
display: Read Exception `1200px-Commons-emblem-disambig-notice.svg.png' @ error/png.c/MagickPNGErrorHandler/1728.
display: corrupt image `1200px-Commons-emblem-disambig-notice.svg.png' @ error/png.c/ReadPNGImage/3695.

`----

(In reply to comment #3)

I'm reading the arrogant "not relevant" as "you don't have a
clue". I'm pissed cause I took the time yesterday to render the
collection and one of the images was truncated. We're still seeing
lots of errors from broken images.

My intention was to say that swift probably isn't the cause of those problems -- at least, not the swift problem robla was talking in that message since that problem had been fixed.

I'll notify robla that you think swift is still causing problems.

Thanks for the report Ralf. Ben, could you investigate this?

Ben points out that the original report is a separate bug, which is now filed as bug 34695 and assigned to him. Assigning the PDF generation issue to Tomasz to help sort out what to do here.

ralf_wikimedia wrote:

My intention was to say that swift probably isn't the cause of those problems

  • at least, not the swift problem robla was talking in that message since that

problem had been fixed.

But I guess not all of the corrupt images have been removed. Judging from the ones I looked at today these were all .svg images and the truncated files have a filesize that is a multiple of 4096.

ralf_wikimedia wrote:

*** This bug has been marked as a duplicate of bug 34695 ***

bhartshorne wrote:

I'm sorry, but this is not a duplicate of bug 34695, unless the comments referenced in German (which I'm afraid I can't read) say something different from the original post. The image referenced isn't truncated; it's only the PDF that Juetho describes not having the final image. I checked all the existing thumbnails for Hydravulgaris.jpg in swift (and on ms5, the original thumbnail store) and they are all ok.

At the same time, I can't recreate the bug (poking at things on the german page that look like they might say print or export), so my request is that Juetho or someone else recreate the bug and confirm that it still exists. Barring that, we should probably close this as unreproducible (but not a dupe).

ralf_wikimedia wrote:

(In reply to comment #9)

I'm sorry, but this is not a duplicate of bug 34695, unless the comments
referenced in German (which I'm afraid I can't read) say something different
from the original post. The image referenced isn't truncated; it's only the
PDF that Juetho describes not having the final image. I checked all the
existing thumbnails for Hydravulgaris.jpg in swift (and on ms5, the original
thumbnail store) and they are all ok.

I guess you're not only sorry but also wrong. As I have already written in this bug report one of the images *was truncated*:

-rw-r--r-- 1 ralf users 143360 Feb 23 12:47 Datei:Hydravulgaris.jpg

filesize is a multiple of 4096. display says it's truncated:

[py27] ~/t/ % display images/Datei:Hydravulgaris.jpg
display: Premature end of JPEG file `images/Datei:Hydravulgaris.jpg' @ warning/jpeg.c/JPEGWarningHandler/325.
display: Corrupt JPEG data: premature end of data segment `images/Datei:Hydravulgaris.jpg' @ warning/jpeg.c/JPEGWarningHandler/325.

This could very well be a problem in our code fetching the images, in python's urllib, in python's zipfile module or even a hardware problem on the machines fetching the images. Probably even a bug in imagemagick.

However, given the recent swift problems it looks much more likely that the image file as served by upload.wikimedia.org in fact was truncated and that this was caused by the swift issue. At least that's my opinion on the matter.

If you have any other facts that hint at the problem not being caused by the swift issue, please let me know. And yes, I understood that Hydravulgaris.jpg is not truncated *now*.

Juergen.Thomas wrote:

(In reply to comment #9)

At the same time, I can't recreate the bug (poking at things on the german page
that look like they might say print or export),

The menu item is called "Drucken/exportieren" (exportieren = export), the feature is called "Als PDF herunterladen". I might have used the German descriptions, too.

someone else recreate the bug and confirm that it still exists. Barring that,
we should probably close this as unreproducible (but not a dupe).

Indeed, it's OK now. Perhaps, the new MW version 1.19wmf1 instead of 1.18.1 contains the solution.

I mark this bug as FIXED.

ralf_wikimedia wrote:

It's fixed when bug 34695 is fixed IMHO (Juetho: the error occurs for many images at the moment, for more information read my comments on the subject).

No one has given a reasonable argument why this could be a different issue from bug 34965 (besides the fact that it is working *now*, which isn't a very strong argument - since the images being served now and before really differ).

Closing as duplicate again.

*** This bug has been marked as a duplicate of bug 34695 ***