Last modified: 2011-02-08 21:56:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28548, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26548 - External wiki generates incorrect thumbnails of PDF files from Wikimedia Commons
External wiki generates incorrect thumbnails of PDF files from Wikimedia Commons
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.18.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://tools.wikimedia.pl/testwiki/w/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-02 20:58 UTC by Leinad
Modified: 2011-02-08 21:56 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
possible patch to make instantcommons work with paged media (8.89 KB, patch)
2011-01-30 04:24 UTC, Bawolff (Brian Wolff)
Details

Description Leinad 2011-01-02 20:58:18 UTC
To reproduce:
1. Create new installation of MediaWiki and enable extension PdfHandler and set variable $wgUseInstantCommons=true;
2. In this wiki try open PDF file from Wikimedia Commons and click 2nd, 3rd, 4 page
3. Wiki will generate all thumbnails the same as the first page (example in URL)

PS My apologies, but I don't know which Bugzilla Compotent is proper, probably the issue is connected with extension PdfHandler or with variable $wgUseInstantCommons.
Comment 1 Roan Kattouw 2011-01-02 21:22:02 UTC
This sounds like an issue with the way ForeignAPIRepo and PdfHandler work together, but I can't tell offhand which one is to blame.
Comment 2 Mark A. Hershberger 2011-01-28 19:55:49 UTC
Giving this to Roan so it doesn't fall through the cracks and since he seems to have an idea about it.
Comment 3 Krinkle 2011-01-28 22:48:53 UTC
Within WIkimedia wikis this works fine:

http://en.wikisource.org/w/index.php?title=File:Apuntes_Electronica_Transistores.pdf&page=2

So it 'can' work and the solution has apparently been found. But then again, WMF doesn't have the typical InstantCommons / API ForeignRepo config.
Comment 4 Leinad 2011-01-28 22:59:14 UTC
(In reply to comment #3)
> Within WIkimedia wikis this works fine:
> 
> http://en.wikisource.org/w/index.php?title=File:Apuntes_Electronica_Transistores.pdf&page=2
> 
> So it 'can' work and the solution has apparently been found. But then again,
> WMF doesn't have the typical InstantCommons / API ForeignRepo config.

Wikimedia sister projects use thumbnails from Commons. Wikis with InstantCommons generate own thumbnails.
Comment 5 Krinkle 2011-01-28 23:02:10 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Within WIkimedia wikis this works fine:
> > 
> > http://en.wikisource.org/w/index.php?title=File:Apuntes_Electronica_Transistores.pdf&page=2
> > 
> > So it 'can' work and the solution has apparently been found. But then again,
> > WMF doesn't have the typical InstantCommons / API ForeignRepo config.
> 
> Wikimedia sister projects use thumbnails from Commons. Wikis with
> InstantCommons generate own thumbnails.

Caching can be disabled when using wikimediacommons as a foreign file repo. Then the thumbnails are used directly from Commons.
Comment 6 Bawolff (Brian Wolff) 2011-01-28 23:03:03 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Within WIkimedia wikis this works fine:
> > 
> > http://en.wikisource.org/w/index.php?title=File:Apuntes_Electronica_Transistores.pdf&page=2
> > 
> > So it 'can' work and the solution has apparently been found. But then again,
> > WMF doesn't have the typical InstantCommons / API ForeignRepo config.
> 
> Wikimedia sister projects use thumbnails from Commons. Wikis with
> InstantCommons generate own thumbnails.

No. Wiki's with instantCommons get their thumbnails from commons too (either directly, or they are downloaded from commons, and then cached). But they do it in a different way.

The problem is, at the moment the api only supports passing the height and width parameter for getting the thumb url. ForeignApiRepo throws away any other rendering parameters (which includes page number).
Comment 7 Krinkle 2011-01-28 23:06:11 UTC
According to bawolff, on IRC, when using ForeignDBRepo (rather than ForeignApiRepo, such as on WMF):

> Yeah, ForeignDBRepo is fine
> the getThumbUrl function of ForiegnApiRepo doesn't even take an argument for pages as far as i can tell
> it appears that technically we support passing handler-specific rendering parameters that could be anything

I guess these parameters could be added to ForeignApiRepo like in ForeignDBRepo fairly easily.
Comment 8 Bawolff (Brian Wolff) 2011-01-30 04:24:52 UTC
Created attachment 8065 [details]
possible patch to make instantcommons work with paged media

Here's a first version of a patch to make this work.

The basic issue is:
*When transforming a file into a thumbnail, there are several parameters. The most basic are width and height. Paged media (like pdf's) also use a page parameter. Media handlers can define whatever parameters are useful to them (for example, oggHandler uses a seek parameter to determine which frame in a video stream to use as a thumbnail).
*The API only supports making thumbnails with the width and height parameters. No other parameters are supported.
*ForeignApiFile throws away any other rendering parameters that aren't width or height.

This patch fixes that by adding a new parameter to the api - iiurlparam. This should fix the issue. However there's a couple things I'm not sure about (which is why this is attached to the bug instead of committed).

*The syntax for specifying rendering parameters to the api is api.php?titles=file:your_image.pdf&action=query&query=imageinfo&prop=url&iiurlwidth=200&iiurlparam=page=3|some_other_parameter=bar
Basically, iiurlparam takes a | separated list of name=value pairs.
Having name=value inside an api parameter is a little different from how the rest of the api works. However we can't just have iiurl<param name here> because the parameters could be anything. Although we could just have iiurlpage since that is really the only one causing the issues at the mto be consistentoment, but that seems kind of half-hearted.
*Does allowing arbitrary rendering parameters introduce any security issues? I'm pretty sure it does not, since I believe they are validated before used, however not 100% sure how the image rendering code actually works. Just from giving useful error messages, the parameters should probably be validated inside ApiQueryImageInfo better then what I've done (as it stands, if something is really invalid, it should cause a mediatransformerror, which seems to just cause the api not to output a thumb parameter, with no warnings/errors. Maybe pass through the image handler's normaliseParams before trying to use, and error out if that returns false).
*A minor issue. I'm not sure what the deal is with the error codes in this module. http://en.wikipedia.org/w/api.php?action=query&prop=imageinfo&titles=image:Example.jpg&iiprop=url&iiurlheight=10&format=xml has a couple too many i's. So do the new error codes I introduced (to be consistent, since i'm not really sure what the conventions with api error codes actually are).

So anyways, thoughts?
Comment 9 Bawolff (Brian Wolff) 2011-02-05 08:51:16 UTC
I discovered that there exists a validateParam method of the media handler's to validate parameters, which made me feel a whole lot better about this patch.

Committed in r81558.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links