We want to implement ResourceLoader module to ship CSS for sets of SVG+PNG icons to the user. This has been in the works for a while now at https://gerrit.wikimedia.org/r/#/c/165922/ , I'm filing this task to have a place to dump assets and tests and such, and point people to.
- Mentioned In
- T76148: Compress OOjs UI PNGs with pngcrush -brute -reduce
rMWaa00a3e8384a: ResourceLoaderImageModule for icons
T72933: SVG icons in MediaViewer should have a fallback
T72654: MediaViewer's SVG icons cannot be automatically transformed to PNG
T76852: OOUI's svgo-optimized SVG files are not compatible with rsvg's broken SVG parsing
T76477: Create a variant of SvgHandler suitable for ResourceLoaderImage
T76475: "ImageMagick" SVG converter shouldn't use "-background white", but "transparent"
- Mentioned Here
- T76477: Create a variant of SvgHandler suitable for ResourceLoaderImage
Trevor's rasterization test: https://github.com/trevorparscal/colorize (check out the rsvg branch too: https://github.com/trevorparscal/colorize/tree/rsvg).
Effect: the default behavior sucks. Using ImageMagick and rsvg, respectively, we get icons mangled in different funny ways:
However, it can be easily worked around. ImageMagick just needs some command-line options, rsvg needs massaged input data.
|ImageMagick, tweaked||rsvg, tweaked|
Problem: SvgHandler doesn't allow us to do either of these things. Needs some refactoring.
Also, if the goal here is to have these images rasterized dynamically, I'm not sure if that's a good idea:
*Not all people have either image magick or rsvg installed
*I believe I've seen people who have image magick installed, with it compiled to use rsvg, but don't have the shared librsvg library installed, resulting in an error whenever image magick is fed an svg
*Hard to control for quality when different users will have different software, and different versions/compile time options of the software installed
Huh, so ImageMagick can act like a wrapper for rsvg? Curious, I didn't know that.
The rasterized images are only used by browsers that can't handle SVG, and there aren't that many of them anymore. Without dynamic rasterizatiom we'd have to take care of somewhere between one and ten additional copies for each image.
ImageMagick's use of RSVG is cool - but the reason we were trying to get ImageMagick to output acceptable quality (using super sampling and sharpening) was to support the minimum requirements of MediaWiki for "rendering thumbnails", as stated on mediawiki.org. RSVG support is indeed a great thing to have both for performance and quality reasons.
Do we have a list of the browsers that would need PNGs and a rough number for their usage?
The ones that are not supported by http://pauginer.com/post/36614680636/invisible-gradient-technique – that post mentions IE<=9, Firefox<=3.5 and some old Android browsers. The full list of browsers that need PNG is the browsers that don't support http://caniuse.com/#feat=multibackgrounds or http://caniuse.com/#feat=css-gradients .
So, this would be mostly IE8 and below users – maybe 3% of worldwide usage, and less by the time MediaWiki 1.25 ships. Theoretically we could modify the MW release tarballs to ship with the PNGs available if it's a problem, but I'm not convinced it's needed. Let's address that come the RCs if someone finds it problematic in the real world.
So Idf6ff4eb8e is merged; can this be marked as Resolved? If so, are the "blocking" tasks not really blocking, or is there a subsequent implicit part of this task ("… and use it") which isn't yet fixed?