This issue is already reported in here (Japanese) about a month ago. As you can see there, svg files do not properly processed with frame in File:. Image quality is inferior to that without frame. Although Yapparina reported that this issue is avoidable with thumb, the problem still remains.
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Ensure framed/unscaled SVG transclusions have srcset | mediawiki/core | master | +32 -8 |
Event Timeline
That's fine, just wanted to make sure it wasn't some strange svg feature or otherwise. Task updated :)
I don't speak Japanese, but looking at the examples in that thread:
[[File:Parzen window illustration.svg|center|frame]] [[File:Parzen window illustration.svg|center]] [[File:Parzen window illustration.svg|center|thumb|620px]]
<div class="center"> <div class="thumb tnone"> <div class="thumbinner" style="width:622px;"><a href="/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Parzen_window_illustration.svg" class="image"><img alt="Parzen window illustration.svg" src="//upload.wikimedia.org/wikipedia/commons/thumb/a/a3/Parzen_window_illustration.svg/620px-Parzen_window_illustration.svg.png" width="620" height="88" class="thumbimage" data-file-width="620" data-file-height="88" /></a> <div class="thumbcaption"></div> </div> </div> </div>
<div class="center"> <div class="floatnone"><a href="/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Parzen_window_illustration.svg" class="image"><img alt="Parzen window illustration.svg" src="//upload.wikimedia.org/wikipedia/commons/thumb/a/a3/Parzen_window_illustration.svg/620px-Parzen_window_illustration.svg.png" width="620" height="88" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/a/a3/Parzen_window_illustration.svg/930px-Parzen_window_illustration.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/a/a3/Parzen_window_illustration.svg/1240px-Parzen_window_illustration.svg.png 2x" data-file-width="620" data-file-height="88" /></a></div> </div>
<div class="center"> <div class="thumb tnone"> <div class="thumbinner" style="width:622px;"><a href="/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Parzen_window_illustration.svg" class="image"><img alt="Parzen window illustration.svg" src="//upload.wikimedia.org/wikipedia/commons/thumb/a/a3/Parzen_window_illustration.svg/620px-Parzen_window_illustration.svg.png" width="620" height="88" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/a/a3/Parzen_window_illustration.svg/930px-Parzen_window_illustration.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/a/a3/Parzen_window_illustration.svg/1240px-Parzen_window_illustration.svg.png 2x" data-file-width="620" data-file-height="88" /></a> <div class="thumbcaption"> <div class="magnify"><a href="/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Parzen_window_illustration.svg" class="internal" title="拡大"></a></div> </div> </div> </div>
The first one doesn't have the 'srcset' attribute with 1.5x and 2x resolution images (for high DPI screens).
Probably due to missing one of the spaghetti code paths in image rendering when we added srcset... Let me take a quick look.
Confirmed, Linker::makeThumbLink2 does not call processResponsiveImages in the framed case. Needs cleanup, will poke it when on a real computer and not just in Safari on an iPad. :)
Is anybody going to work on this? Doing nothing for 7 years doesn't look nice...
As I understand, the problem is that here:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/linker/Linker.php#820
the function processResponsiveImages() is not called if $noscale is set, and it is set unconditionally for all "framed" images here:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/linker/Linker.php#711
So I guess the solution would be to skip setting $noscale = true; for vector files (SVG, PDF, what else?), which should be doable, since that file already includes (in a different place) some special treatment for SVG files.
@MikhailRyazanov: There is no unlimited number of developers; we could simply hide or switch off the issue tracker if "looking nice" was somehow important. :P
Anyone is free and welcome to propose a code change, see https://www.mediawiki.org/wiki/Gerrit/Tutorial - thanks!
@Aklapper, I know how to use Git (and have already committed to another WP-related project), but I'm not familiar with the Mediawiki codebase. In particular, I don't know what is the proper way to determine the image type (to make that $noscale = true; conditional) and how to test the results. I would expect that for any active Wikimedia developer these things should be trivial, and my suggestions where and which modifications to make should be sufficient to at least try...
(For context, this was recently reported at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Blurry_SVG_render_with_"frame")
@MikhailRyazanov I encourage you to try to propose a patch yourself, since then you just need to find one active developer to review it, and otherwise you need to find two (one to write the patch and another to review it). I would be happy to review it.
I browser around a bit and I think that you can use $file->isVectorized() there. (See definitions for different file types: https://codesearch.wmcloud.org/search/?q=function+isVectorized)
and how to test the results.
If you're talking about unit tests, the documentation for how we test the parser is here: https://www.mediawiki.org/wiki/Manual:Parser_tests
Some relevant test cases can be found here:
- https://codesearch.wmcloud.org/core/?q=\|frame\|&files=tests%2Fparser%2F
- https://codesearch.wmcloud.org/core/?q=\.svg\|&files=tests%2Fparser%2F
It seems there aren't any test cases with a .svg file and |frame, so you'll probably want to add one – I recommend copy-pasting and adjusting :)
If you have trouble with running MediaWiki or running the tests locally, you can submit the patch anyway, and the continuous integration bot will run the tests on our servers and report back with the results. This usually takes a while though.
By the way, good news, this bug is not present in the new parser (Parsoid) – you can compare the outputs like this: https://en.wikipedia.org/wiki/Uncanny?action=parsermigration-edit#Related_theories
@matmarex, thanks for pointing to isVectorized()! Then my proposed patch would be simply to replace this line:
if ( !$noscale && !$manualthumb ) {
by this:
if ( ( !$noscale && !$manualthumb ) || $file->isVectorized() ) {
That is, add higher-resolution subimages for all "vector" files (currently just SVGs, it seems), regardless of whether the "thumb" is the full-size image or substituted manually. (The parentheses around && are unnecessary but the current coding style apparently uses them, for example.)
I really hope that somebody actually paid by the WMF can do the rest.
P.S. It is ironic that the https://www.mediawiki.org/wiki/Parsoid page suffers from exactly this rendering issue.
Change 973245 had a related patch set uploaded (by TheDJ; author: TheDJ):
[mediawiki/core@master] Ensure framed/unscaled SVG transclusions have srcset
Change 973245 merged by jenkins-bot:
[mediawiki/core@master] Ensure framed/unscaled SVG transclusions have srcset
Thank you @TheDJ!
The change will be deployed to Wikimedia wikis two weeks from now, on 28-30 November (it would usually happen in one week, but the usual scheduled deployments next week are cancelled due to US Thanksgiving, see https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar).