| fbstj | |
| Nov 4 2012, 7:27 PM |
| F10236: patch0.patch | |
| Nov 22 2014, 1:12 AM |
I am running in safe_mode, and am having trouble with thumbnails. I have $wgUseImageResize = false; so that I can use all my already-rasterized images, but I have no way of disabling the SVG rasterizer, and yet still being able to view the image itself (aka an img tag with src="something.svg"). I don't want to support old browsers. How can I fix this?
Version: unspecified
Severity: enhancement
Duplicate of: T5593
Since most major browsers already support SVG [1] it seems sensible enough that we provide a configuration variable so SVG images are embedded directly in articles just as any other images, without the need to generate a rasterized thumbnail.
Although I'm not sure if that would eliminate the need of a SVG converter to retrieve the file dimensions and get the proper aspect ratio for generating width and height of the image. Maybe we could get it directly from the svg markup.
[1] = http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Support_for_SVG_in_web_browsers
Created attachment 11414
hack that fixes this bug on my wiki
attachment svg_as_vector.patch ignored as obsolete
(In reply to comment #1)
Although I'm not sure if that would eliminate the need of a SVG converter to
retrieve the file dimensions and get the proper aspect ratio for generating
width and height of the image. Maybe we could get it directly from the svg
markup.
We actually already get that directly from the file actually, so that's not really an issue.
Main issues for doing this:
*Having svgs directly on the page is scarier from a security prespective [There might already be work to dissallow scripted svgs. I can't remember. I would assume so]
*Different browsers implement svg rendering differently. Some users might not like it looks different to different people
Copying Brion on this bug.
I believe current support for this type of functionality (serving SVGs directly to users/browsers) is being packaged in a MediaWiki extension, but perhaps it should be moved into core.
Created attachment 11520
hacks to v1.20.2 specificlally
rather than patching from 1.19.1 + hacks to 1.20.1
Attached:
@MZMcBride well, considering the size of the hack, I don't see how it is viable as an extension.
note there are extensions of all sizes, ranging from 2 lines to tens of thousands of lines or more.
it was more that its fixable in the main with a small amount of code, which would be greatly expanded to make it into a plugin, surely.
Whoops, this petition already exists as bug 3593
@Joe ST : You may want to post your patch there