1

I don't exactly know how to word this question properly, so I'll make an attempt:

See the rasterized SVG on this page? Looks pretty distorted, and - excuse me language - rather s***. Now let's compare it with the one here. Both of them have the exact same SVG file and the source code is identical in wikitext. The difference is in how the rasterized "thumbnail" is generated, it seems.

The result that MediaWiki gives me

The result I get from MediaWiki.

Intended result

The intended result.

From what I have noticed - correct me if I'm wrong - both Wikipedia and Wikia either create several rasterized thumbnails for the SVG, or just simply generate them on demand, depending on the size the pages want. MediaWiki by default however, only generates one thumbnail, which is implied to have the same resolution as the original SVG - which gives us blurry and **** raster-images when rasterizing a small SVG to a large image.

Either that, or the SVGs don't get scaled/resized prior to thumbnailing/rasterization, when they should be.

Just for heads up, here's some come from my LocalSettings.php:

$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg',
    'xls', 'mpp', 'pdf', 'ppt', 'tiff', 'ogg', 'svg',
    'woff', 'eot', 'woff2'
);
// $wgSVGConverters['ImageMagick'] = '"' . $wgImageMagickConvertCommand . '" -background white -thumbnail $widthx$height^! $input PNG:$output';
// $wgSVGConverters['ImageMagick'] = '$path/convert -density $width -geometry $width $input PNG:$output';
$wgSVGConverters['ImageMagick'] = '$path/convert -density 1200 -background none -geometry $width $input PNG:$output';
$wgSVGConverters['rsvg'] = '/usr/bin/rsvg-convert -w $width -h $height $input -o $output';
$wgSVGConverter = 'ImageMagick';
// $wgSVGConverter = 'rsvg';
$wgSVGMaxSize = 2048;
$wgMaxImageArea = 1.25e7;
$wgMaxAnimatedGifArea = 1.0e6; 
$wgUseImageResize = true;
$wgGenerateThumbnailOnParse = true;

So... how do I enable having multiple thumbnails, if the lack of them is the cause of the problem? Is this even the cause of the problem to begin with? If not, what is the real reason why I'm not getting my intended result? What can I do?

EDIT: Already solved by switching over to ImageMagick to RSVG.

3 Answers3

1

Already solved by switching from ImageMagick to RSVG.

1

Believe me, the best solution is just to disable imageMagick and just let the SVGs be rendered as SVGs, in their original perfect resolution.

Here you can see the native SVG feature being developed, it hasnt been finished. https://phabricator.wikimedia.org/T5593

Here is a beta feature opt-in svg for wmf proposed: https://phabricator.wikimedia.org/T134482

"larson wrote:

Would love to have SVG rendered natively in the client. It's 2013, the support is there — Brion's 4-year-old comment in that regard notwithstanding. If you don't want to enable it on Wikimedia sites, fine, you don't have to. For my site, I'd rather have the file downloaded and cached once, than fetching multiple rasterized resizings of it."

Mediawiki documentation seems to pretend that client rendering of SVG is done on 99% of websites, and the practice of rendering to png is never done. They basically ignore that native SVG handling is an option, and the BEST option for any non-wmf site. This is mostly because the documentation needs updating and is a mess, there is no malicious intent.

ImageMagick is buggy and mediawiki's GD library will be used instead for normal images.

The only reason mediawiki png renders svgs is because they like supporting really old browsers, like IE6, which no one is using. They do it because Wikipedia's userbase is huge, and all demographics of people use it.

Just let the SVGs be rendered by the browser, client-side. You will use less server power, and won't have a huge deprecated chain of dependencies to worry about.

Install this: https://www.mediawiki.org/wiki/Extension:NativeSvgHandler

$wgFileExtensions[] = 'svg';
$wgAllowTitlesInSVG = true;
$wgUseImageMagick = false;

//Make sure this variable is false or not there at all:
$wgSVGConverter = false;

If you want to read more (this is a poorly written page though): https://www.mediawiki.org/wiki/Manual:Image_administration#SVG

edit: Not to mention, why the **** would you take SVGs, and then dynamically rasterize them? You might as well just save the image as png in the first place. It ruins all the great benefits of SVG.

  • Full resolution crisp

  • Can be styled with css

  • Filters

  • Animations

  • Fully editable file, just open it in text / code editor

  • Smaller file size, depending on how efficiently the SVG was made and how complex it is.

Run SVGs through SVGOMG, it can optimise the file a lot. Personally sometimes its even possible to get a few dozen more bytes smaller with my own techniques after SVGOMG does its work.

o0o0o0o0o
  • 89
  • 1
  • 11
  • This solution also works if you leave ImageMagick enabled! This way it can still handle all the raster types. – dval Dec 30 '19 at 13:55
  • It also solved a completely separate issue of `Error creating thumbnail: convert.im6: unable to access configure file 'delegates.xml' `. So, something breaks ImageMagick when mediawiki allows svg uploads. – dval Dec 30 '19 at 14:03
0

In Imagemagick, you just need to provide a large density before reading the svg file. So this works for me.

convert -density 600 The_Mystics.svg mystics.png

enter image description here

fmw42
  • 46,825
  • 10
  • 62
  • 80
  • Yes, I have figured that out. The server - which isn't owned by me, I merely have write and read privileges to the Wiki part, but no root privileges - has Gentoo Linux, and apparently has an older version Imagick that ignores the density. Therefore, the only solution for me was to switch to RSVG (fortunately, the server has that installed too). – Stephanus Tavilrond Aug 08 '17 at 15:48