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

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

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

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.

User preferences.

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.

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.

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.

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

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.

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)

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.

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.

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.

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.

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.

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

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

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

Bryan.TongMinh wrote:

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

giving SVG bugs back to the pool.

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.

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

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.

Created attachment 9205
http://commons.wikimedia.org/wiki/File:AvHumboldts_Amerikareise_map_de.svg

Attached:

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?

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/

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

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

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

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

The fix for this task obsoleted scripts/gadgets such as these:
https://en.wikipedia.org/wiki/MediaWiki:Common.js/file.js (see w:en:MediaWiki talk:Common.js#Remove MediaWiki:Common.js/file.js)
https://pt.wikipedia.org/wiki/MediaWiki:Gadget-SVGPNG.js/Core.js
other wikis should be checked to remove any forks of these scripts. User-notice

In T8834#7014359, @Jdlrobson wrote:

Not all browsers we support, support forEach on NodeLists e.g. older Chrome versions and IE 11. Jdlrobson (talk) 01:16, 18 April 2021 (UTC) - this has led to a large spike in errors and is now our top bug (TypeError: divs.forEach is not a function)

I have a patch up to add some array method polyfills to the MW JS environment. It currently does not polfill Array.from but I could add a polyfill for that method later today.

That would allow this code to be written in a way that we can be sure that forEach is okay to use in this sort of situation, without having to rely on jQuery.each.