Do you mean frame where you say flame?

It is a mere misspelling.

In T133489#2233175, @ARAKI_Satoru wrote:

It is a mere misspelling.

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

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.

In T133489#9283244, @MikhailRyazanov wrote:

In particular, I don't know what is the proper way to determine the image type (to make that $noscale = true; conditional)

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.

You can also propose a patch through https://gerrit-patch-uploader.toolforge.org.

Change 973245 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/core@master] Ensure framed/unscaled SVG transclusions have srcset

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

Change 973245 merged by jenkins-bot:

[mediawiki/core@master] Ensure framed/unscaled SVG transclusions have srcset

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