Last modified: 2014-05-29 19:57:26 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 T65914, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63914 - SVG images with a specified width should not get rendered into PNG thumbnails that are bigger
SVG images with a specified width should not get rendered into PNG thumbnails...
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.23.0
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-14 21:29 UTC by Mark Holmquist
Modified: 2014-05-29 19:57 UTC (History)
7 users (show)

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


Attachments

Description Mark Holmquist 2014-04-14 21:29:44 UTC
http://www.mediawiki.org/w/api.php?action=query&format=json&titles=File:MediaWiki-sysadmins-icon.svg&prop=imageinfo&iiprop=url|size&iiurlwidth=1000

This is just a totally silly return value for this API call. I mean, it makes sense with SVGs, but SVGs are the only place where this sort of response makes sense. A PNG test image successfully returns the maximum size, and the URL to the original image, for a request that goes over the limit:

http://en.wikipedia.org/w/api.php?action=query&titles=File:Test.jpg&prop=imageinfo&iilimit=50&iiend=20071231235959&iiprop=url|size&indexpageids=1&format=json&iiurlwidth=1000

I'm going to fix this issue on our end, but if we could also fix the API so it doesn't give me a 50,000 pixel wide thumbnail for an SVG when I ask for it that would be FANTASTIC. (I haven't tried this yet but it seems the logical conclusion)
Comment 1 Bawolff (Brian Wolff) 2014-04-15 15:29:50 UTC
If it makes you feel better it will probably run out of memory before actually rendering a 50,000 pixel wide thumb out of an svg.

Its expected behaviour that svgs can be resized beyond their "natural" width unlike raster images. However might make sense to have some sort of upper limit for sanity on that. From a performance prespective it probably doesnt matter that much as there are the max memory/file size/cpu time limits.
Comment 2 Mark Holmquist 2014-04-15 18:36:48 UTC
(In reply to Bawolff (Brian Wolff) from comment #1)
> If it makes you feel better it will probably run out of memory before
> actually rendering a 50,000 pixel wide thumb out of an svg.

...not really? :)

> Its expected behaviour that svgs can be resized beyond their "natural" width
> unlike raster images. However might make sense to have some sort of upper
> limit for sanity on that. From a performance prespective it probably doesnt
> matter that much as there are the max memory/file size/cpu time limits.

Maybe there could be a per-request "limit this to the size of the image" option that only applied to vector formats? That way we don't need to deal with it on our end, it can just be part of the normal thumbnail negotiation - "give me the thumbnail that is the same size as the original SVG".
Comment 3 C. Scott Ananian 2014-05-29 19:57:26 UTC
I think this is a WONTFIX.  The Parser clearly allows SVGs to be rendered above their native resolution, and that is explicitly what is being requested by the API call in the bug description.  Why are you passing width=1000 if that's not what you want?

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


Navigation
Links