Last modified: 2014-07-03 17:48:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6834 - Add "Other resolutions"-links to .svg files as well (PNG thumbnails)
Add "Other resolutions"-links to .svg files as well (PNG thumbnails)
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.8.x
PC Windows XP
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://commons.wikimedia.org/wiki/Ima...
:
: 6731 56508 (view as bug list)
Depends on: 2581
Blocks: svg
  Show dependency treegraph
 
Reported: 2006-07-28 00:43 UTC by Invitatious
Modified: 2014-07-03 17:48 UTC (History)
10 users (show)

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


Attachments
[[commons:File:AvHumboldts_Amerikareise_map_de.svg]] as of MediaWiki 1.18wmf1 (deleted)
2011-10-09 23:57 UTC, Krinkle
Details
http://commons.wikimedia.org/wiki/File:AvHumboldts_Amerikareise_map_de.svg (41.68 KB, image/png)
2011-10-09 23:58 UTC, Krinkle
Details

Description Invitatious 2006-07-28 00:43:35 UTC
The image page of an SVG image should show a link to the full-size PNG version,
for browsers that can't display SVG; most browsers with no plugins except
Firefox. The PNG link would greatly increase accessibility for MSIE as well as
most other browsers.

Also, Wikipedia and other Wikimedia projects render SVG differently than Windows
browsers, as it runs on Linux servers, so this allows a wiki user to quickly and
easily check the rendering of the vectorial image.

[[w:en:User:Invitatious]] on Wikipedia.
Comment 1 Invitatious 2006-07-28 00:43:58 UTC
*** Bug 6731 has been marked as a duplicate of this bug. ***
Comment 2 Alexander Karnstedt 2008-03-26 14:44:54 UTC
Seems like a pretty crucial feature to mee. What's the status of this issue? 

At the moment we are impelled to upload PNG version parallel to the SVG images. Along with different language versions we got x² versions of one image... cumbersome. 

This parallel uploading can be easily eliminated with linking to a full-size PNG version.

[[w:de:User:Alexrk]]
Comment 3 Brion Vibber 2008-03-26 19:21:53 UTC
The 'zoomed'/large size is displayed on the image page...
Comment 4 Alexander Karnstedt 2008-03-26 23:57:59 UTC
Brion, thanks for your comment. 

I understand, that for performance reasons (and PNG limitations) it might not be convienent to rasterize the SVG in full size (1:1); however, it would be great, if we can specify the size of the 'large size' version of the PNG image.

For instance my SVG file is 2843 x 1902 pixels (http://commons.wikimedia.org/w/index.php?title=Image:AvHumboldts_Amerikareise_map_de.svg)

The PNG version of this file is 800 x 535. But I want it to be 1,200 x 803 (cause 800 is somewhat too small)

How the size of the 'large size' PNG is figured out at the moment? Is there a formula? It doesn't seem to be a fixed resolution.
Comment 5 Brion Vibber 2008-03-28 19:30:10 UTC
User preferences.
Comment 6 Brion Vibber 2008-03-28 21:01:46 UTC
I do agree there could be some utility to a larger-than-inline, possibly 'native' size rasterization, both for browsers that don't support SVG specifically and for other formats that are inconsistently supported.

Probably not terribly difficult to arrange, though we need to make sure we can cleanly add a second link without it getting confusing.
Comment 7 Gnu1742 2008-10-08 21:39:38 UTC
'User preferences' is something the drive-by-user does not have. We do this not for ourselves but for all those people out there.
Comment 8 Platonides 2008-10-08 21:45:05 UTC
Are you sure all those people out there want the SVG in full size? The default 800×600 should be suitable for most non-technical reusers.
Comment 9 Alexander Karnstedt 2008-10-09 15:52:40 UTC
Nope, full size rendered PNG's are neither desirable nor convenient. What if one uploads a SVG with 50.000² pixel? But on the other hand 800x600 is definitely way too small for a lot of technical drawings or maps.

I reconcidered the whole issue and came up with 2 possible solutions:

1) The preview PNG should no longer directly link to the SVG file but instead the link should open a PNG, where the uploader can define the size of this "full size"-PNG (somewhere within the file description).
To get the original SVG source file we could embed a *download link* on the page (e.g. "Download SVG version here").

IMO it makes no sense to directly link to the SVG (as it does now) for various reasons:
 * Various browser are not able to render SVG innately
 * and if the browser can do so, mostly it looks ugly
 * client side rendering a SVG freezes the Browser app (sometimes for minutes) 
 * I think most unexperienced users will expect to see an image (PNG) anyway if they click on an image link; because they want to see the large version of this preview and are not interested in any SVG
 * only experts and other authors might be interested in the SVG source file

2) The author uploads his SVG file as rendered PNG and just somehow attaches the SVG source to it. That is: a normal PNG file page has a special function "upload source file". The SVG source file afterwards again is available as download link from the description page.

That second solution would imply another advantage: the SVG author is able to control the rendering independently by himself with his own SVG application (eg Inkscape). Particularly if the WP-renderer will change afterwards, then there wont be a danger anymore to damage uploaded images (cause they might use sophisticated SVG features so that a SVG file uploaded in 2008 might look totally different in 2010).

Anyway, this is only of interest for complex SVG files (eg cartographic maps). Simple SVG graphics could still be uploaded directly as SVG and rendered server side.
Comment 10 Platonides 2008-10-09 21:33:26 UTC
> 1) The preview PNG should no longer directly link to the SVG file but instead
> the link should open a PNG, where the uploader can define the size of this
> "full size"-PNG (somewhere within the file description).
> To get the original SVG source file we could embed a *download link* on the
> page (e.g. "Download SVG version here").

Maybe the image shouldn't have a link and instead be used for tagging. 
([[commons:MediaWiki:ImageBoxes.js]])

> IMO it makes no sense to directly link to the SVG (as it does now) for various
> reasons:
>  * Various browser are not able to render SVG innately
>  * client side rendering a SVG freezes the Browser app (sometimes for minutes) 
Those are browser bugs.

>  * and if the browser can do so, mostly it looks ugly
Look at the first versions of [[commons:Image:Compsci-logo.svg]] They render correctly 
on firefox but bad on rsvg (I have also seen the opposite).


>  * I think most unexperienced users will expect to see an image (PNG) anyway if
> they click on an image link; because they want to see the large version of this
> preview and are not interested in any SVG
>  * only experts and other authors might be interested in the SVG source file
Probably, they'll wonder what's that their browser wants to download. But how many 
unexperienced users choose that? I that those clicking it are experts, which we don't 
want to annoy by breaking the UI.
Adding a second link to a Special page for rendering images on different size 
could be ok.


> 2) The author uploads his SVG file as rendered PNG and just somehow attaches
> the SVG source to it. That is: a normal PNG file page has a special function
> "upload source file". The SVG source file afterwards again is available as
> download link from the description page.
It could be embedded on a dedicate stream (use the 'compressed text'?). But on 
such a use I'd expect it from Commons to the users. The source embedded on the 
full image (probably pointlessly increasing the image size) or a copyleft notice
added pointing to the wiki.

Providing 'preferred' representations (or just for svg but for any file) may be 
worth discussing, but in the context of a new bug request.
However, note that if you provide the source, you should be able to 'compile' it. 
What if you provide a 'normal' image 'goatse'-sourced?



> That second solution would imply another advantage: the SVG author is able to
> control the rendering independently by himself with his own SVG application (eg
> Particularly if the WP-renderer will change afterwards, then there
> wont be a danger anymore to damage uploaded images (cause they might use
> sophisticated SVG features so that a SVG file uploaded in 2008 might look
> totally different in 2010).
SVG semantics are well defined. A sophisticated SVG feature may be misrepresented 
(or ignored) on 2008, but won't change for 2010.
There're only two cases on which the rendering would change:
1) A regression on the renderer (a bug on the renderer)
2) The svg was relying on a bug which was later fixed (a bug on the file)
Comment 11 Brion Vibber 2008-10-09 21:37:53 UTC
A separate rasterized upload would easily get out of sync by accident (or be abused by vandals), so I strongly recommend against this -- it's just a general maintenance problem.

Having the default click-through link go to a large-ish rasterized version (say fitting in 1600x1200, or whatever), and having the 'download original' link go to the source, would probably be reasonably sensible. On the other hand, it breaks the standard convention that clicking the large inline version on the image page gets you the original download.
Comment 12 Alexander Karnstedt 2008-10-10 10:07:17 UTC
(In reply to comment #11)
> A separate rasterized upload would easily get out of sync by accident (or be
> abused by vandals), so I strongly recommend against this -- it's just a general
> maintenance problem.

Agree. Albeit we have this inconvenience of parallel SVG and PNG uploads as well today ([[commons:Image:SFOBB_map.svg]])

But yes, invisible SVG source files might be a special problem of potential vandalism. Because nobody will consistently check them.

> Having the default click-through link go to a large-ish rasterized version (say
> fitting in 1600x1200, or whatever), and having the 'download original' link go
> to the source, would probably be reasonably sensible. On the other hand, it
> breaks the standard convention that clicking the large inline version on the
> image page gets you the original download.

When I started with Commons I found it strange UI-behaviour that the image link goes to the SVG file - I expected a PNG to open because there already is an explicit link to the SVG below the preview image. IMO the average joe (like me:)) expects to see a rasterized image (PNG, JPG or whatever) if he clicks on a image within a website.

I believe that those users how want to get the SVG source file are not interested in opening it in the browser, instead they just want to download it (eg to use it in Inkscape). And those users who are not aware of any SVG, will get annoyed by opening a SVG because of the browser issues I described above.



Comment 13 Alexander Karnstedt 2008-10-10 10:40:47 UTC
> >  * Various browser are not able to render SVG innately
> >  * client side rendering a SVG freezes the Browser app (sometimes for minutes) 
> Those are browser bugs.

Yep, but sadly those deficiencies exist and to stay on a pragmatic level, we shouldn't blame browser manufacturers; cause it wont solve issues for Wikimedia.

> Adding a second link to a Special page for rendering images on different size 
> could be ok.

The question (from Brion) is only how to make this "without getting it confusing" to the user. 

My thought was therfore: don't embed an extra PNG link but let the image itself link to a large size PNG ...what IMO should be the less confusing solution.

> It could be embedded on a dedicate stream (use the 'compressed text'?). But on 
> such a use I'd expect it from Commons to the users. The source embedded on the 
> full image (probably pointlessly increasing the image size) or a copyleft
> notice
> added pointing to the wiki.

I'm not sure if I understand you right (embedding the SVG within the PNG?) However, what I meant was: uploading a PNG and attaching the SVG somehow to the wiki page. What Brion dislikes because of maintenance and vandalism issues.
 
> SVG semantics are well defined. A sophisticated SVG feature may be
> misrepresented 
> (or ignored) on 2008, but won't change for 2010.
> There're only two cases on which the rendering would change:
> 1) A regression on the renderer (a bug on the renderer)
> 2) The svg was relying on a bug which was later fixed (a bug on the file)

To "beat" the commons renderer SVG authors anyway have to use a swiss army knife of tricks and workarounds today. That's why I'm uncertain, whether all those tricks will have the same effect two years later, when the render service might undergo various changes. Even though today different SVG interpreter will render (partly totally) different results, then how a guarantee can be given, that the Commons renderer will produce the same results in 2010? Well ok, that's another problem.

Comment 14 Alexander Karnstedt 2008-10-31 18:10:34 UTC
> how a guarantee can be given, that the Commons renderer will produce the same results in 2010?

Meanwhile those fears has already come true as you can see here: http://commons.wikimedia.org/wiki/Image:Jade-weser-muendung_map_de.svg

.. fonts are all messed up :(  I've uploaded that SVG in April 2008 and it looked good at that time.

Seems that the commons renderer already changed and produces different results now.
Comment 15 Brion Vibber 2009-08-03 16:53:46 UTC
Assigning SVG bugs to Ariel -- need a cleanup pass to see what's fixed up by a librsvg upgrade, what can be resolved with fixes to our font configuration, what can be fixed on our end, and what still needs to be pushed upstream.
Comment 16 Platonides 2009-08-03 22:44:11 UTC
There's the gadget http://commons.wikimedia.org/wiki/MediaWiki:Gadget-ChooseResolution.js
That could be moved to global js if needed.
Comment 17 Guillaume Paumier 2009-12-30 20:33:00 UTC
[[:commons:MediaWiki:Common.js]] also adds links to PNG renderings of a SVG file at various sizes. I agree we should integrate a similar feature.
Comment 18 Derk-Jan Hartman 2009-12-31 00:46:44 UTC
The functionality pointed out by guillom is also integrated into the english wikipedia. See [[:en:MediaWiki:Common.js/file.js]]
Comment 19 Bryan Tong Minh 2011-03-12 22:54:47 UTC
Mostly done in r83791; only needs to remove the $size < $size_orig checks for SVGs specifically.
Comment 20 Ariel T. Glenn 2011-09-18 09:27:46 UTC
giving SVG bugs back to the pool.
Comment 21 Krinkle 2011-10-09 23:54:59 UTC
Rephasing bug.

Except for some formats, most images have "Other resolutions"-links below their default-size thumbnail on the File:-page.

As of MediaWiki 1.8 these are now added for .svg files as well. (See attachment).

(In reply to comment #19)
> Mostly done in r83791; only needs to remove the $size < $size_orig checks for
> SVGs specifically.

I'm not marking this bug fixed just yet per the above comment.
Comment 22 Krinkle 2011-10-09 23:57:07 UTC
Created attachment 9204 [details]
[[commons:File:AvHumboldts_Amerikareise_map_de.svg]] as of MediaWiki 1.18wmf1
Comment 23 Krinkle 2011-10-09 23:58:13 UTC
The content of attachment 9204 [details] has been deleted by
    Krinkle <krinklemail@gmail.com>
without providing any reason.

The token used to delete this attachment was generated at 2011-10-09 23:58:11 UTC.
Comment 25 Krinkle 2013-11-12 22:33:48 UTC
Hm.. looks like something has happened recently in this area.

The file page for SVGs now looks like this:


[page]

Size of this preview: 800 × 535 pixels. Other resolutions: 320 × 214 pixels | 640 × 428 pixels | 1,024 × 685 pixels | 1,280 × 856 pixels | 2,844 × 1,903 pixels.

Full resolution ‎(SVG file, nominally 2,844 × 1,903 pixels, file size: 303 KB)

This image rendered as PNG in other widths: 200px, 500px, 1000px, 2000px.


[/page]

This last bit ("PNG in other widths") is from a gadget on Commons, but that first bit ("Other resolutions" is from the server-side output).

Resolved?
Comment 26 Dominic 2014-03-06 06:47:21 UTC
(In reply to Krinkle from comment #25)
> Hm.. looks like something has happened recently in this area.
> 
> The file page for SVGs now looks like this:
> 
> 
> [page]
> 
> Size of this preview: 800 × 535 pixels. Other resolutions: 320 × 214 pixels
> | 640 × 428 pixels | 1,024 × 685 pixels | 1,280 × 856 pixels | 2,844 × 1,903
> pixels.
> 
> Full resolution ‎(SVG file, nominally 2,844 × 1,903 pixels, file size: 303
> KB)
> 
> This image rendered as PNG in other widths: 200px, 500px, 1000px, 2000px.
> 
> 
> [/page]
> 
> This last bit ("PNG in other widths") is from a gadget on Commons, but that
> first bit ("Other resolutions" is from the server-side output).
> 
> Resolved?

That change was in https://gerrit.wikimedia.org/r/#/c/86387/
Comment 27 Gerrit Notification Bot 2014-05-22 17:47:54 UTC
Change 134855 had a related patch set uploaded by Brian Wolff:
Make SVG files show "In other resolutions" at all sizes

https://gerrit.wikimedia.org/r/134855
Comment 28 Bawolff (Brian Wolff) 2014-05-23 00:48:38 UTC
*** Bug 56508 has been marked as a duplicate of this bug. ***
Comment 29 Gerrit Notification Bot 2014-07-03 11:40:28 UTC
Change 134855 merged by jenkins-bot:
Make SVG files show "In other resolutions" at all sizes

https://gerrit.wikimedia.org/r/134855

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


Navigation
Links