Add "Other resolutions"-links to .svg files as well (PNG thumbnails)
Closed, ResolvedPublic

Description

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.


Version: 1.8.x
Severity: enhancement
OS: Windows XP
Platform: PC
URL: http://commons.wikimedia.org/wiki/Image:Example.png

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz6834.
PleaseStand created this task.Via LegacyJul 28 2006, 12:43 AM
PleaseStand added a comment.Via ConduitJul 28 2006, 12:43 AM

*** Bug 6731 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitMar 26 2008, 2:44 PM

alexander_berlin wrote:

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]]

brion added a comment.Via ConduitMar 26 2008, 7:21 PM

The 'zoomed'/large size is displayed on the image page...

bzimport added a comment.Via ConduitMar 26 2008, 11:57 PM

alexander_berlin wrote:

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.

brion added a comment.Via ConduitMar 28 2008, 7:30 PM

User preferences.

brion added a comment.Via ConduitMar 28 2008, 9:01 PM

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.

bzimport added a comment.Via ConduitOct 8 2008, 9:39 PM

gnu1742 wrote:

'User preferences' is something the drive-by-user does not have. We do this not for ourselves but for all those people out there.

Platonides added a comment.Via ConduitOct 8 2008, 9:45 PM

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.

bzimport added a comment.Via ConduitOct 9 2008, 3:52 PM

alexander_berlin wrote:

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
  1. 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.

Platonides added a comment.Via ConduitOct 9 2008, 9:33 PM
  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.

  1. 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)
brion added a comment.Via ConduitOct 9 2008, 9:37 PM

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.

bzimport added a comment.Via ConduitOct 10 2008, 10:07 AM

alexander_berlin wrote:

(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.

bzimport added a comment.Via ConduitOct 10 2008, 10:40 AM

alexander_berlin wrote:

> * 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.

bzimport added a comment.Via ConduitOct 31 2008, 6:10 PM

alexander_berlin wrote:

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.

brion added a comment.Via ConduitAug 3 2009, 4:53 PM

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.

Platonides added a comment.Via ConduitAug 3 2009, 10:44 PM

There's the gadget http://commons.wikimedia.org/wiki/MediaWiki:Gadget-ChooseResolution.js
That could be moved to global js if needed.

gpaumier added a comment.Via ConduitDec 30 2009, 8:33 PM

[[: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.

TheDJ added a comment.Via ConduitDec 31 2009, 12:46 AM

The functionality pointed out by guillom is also integrated into the english wikipedia. See [[:en:MediaWiki:Common.js/file.js]]

bzimport added a comment.Via ConduitMar 12 2011, 10:54 PM

Bryan.TongMinh wrote:

Mostly done in r83791; only needs to remove the $size < $size_orig checks for SVGs specifically.

ArielGlenn added a comment.Via ConduitSep 18 2011, 9:27 AM

giving SVG bugs back to the pool.

Krinkle added a comment.Via ConduitOct 9 2011, 11:54 PM

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.

Krinkle added a comment.Via ConduitOct 9 2011, 11:57 PM

Created attachment 9204
[[commons:File:AvHumboldts_Amerikareise_map_de.svg]] as of MediaWiki 1.18wmf1

attachment Screen Shot 2011-10-10 at 12.50.07 AM.png ignored as obsolete

Krinkle added a comment.Via ConduitOct 9 2011, 11:58 PM

The content of attachment 9204 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.

Krinkle added a comment.Via ConduitNov 12 2013, 10:33 PM

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?

bzimport added a comment.Via ConduitMar 6 2014, 6:47 AM

mcdevitd wrote:

(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/

gerritbot added a comment.Via ConduitMay 22 2014, 5:47 PM

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

Bawolff added a comment.Via ConduitMay 23 2014, 12:48 AM
  • Bug 56508 has been marked as a duplicate of this bug. ***
gerritbot added a comment.Via ConduitJul 3 2014, 11:40 AM

Change 134855 merged by jenkins-bot:
Make SVG files show "In other resolutions" at all sizes

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

Gilles added a project: Multimedia.Via WebDec 4 2014, 9:22 AM
Gilles raised the priority of this task from "Normal" to "Unbreak Now!".Via WebDec 4 2014, 10:11 AM
Gilles moved this task to Closed on the Multimedia workboard.
Gilles lowered the priority of this task from "Unbreak Now!" to "Normal".Via ConduitDec 4 2014, 11:23 AM

Add Comment