I've been poking at SVG support a bit; 1.4 in CVS now has the ability to run SVG images through an external rasterizer to display PNGs inline (ImageMagick, Batik, or sodipodi/inkscape though I've had trouble getting those last two working).
Of course it would be preferable to be able to use the actual SVG images inline when possible; they should download faster and should print at full resolution.
The <object> tag theoretically should let us use the SVG image when the browser supports it and automagically fall back to the rasterized PNG. Unfortunately in my testing I've had a few problems:
* No transparency support for plug-ins. All tests I did showed the SVG image on a solid white background. * If the image is embedded in a link, clicking it does not work if the SVG is showing; the click is passed through to the SVG plugin. * In Firefox, clicking or even right-clicking on the PNG if SVG is not available will bring up a plugin search dialog! * Firefox bugs the user to install a plugin if they don't have one already installed. If you click the button to search, it's unable to find any suitable plugins. :P * Printing with the Adobe SVG plugin doesn't work in Safari or Mozilla on Mac OS X, possibly other browsers/platforms are affected. * Some Mozilla users on Debian reported not seeing any image at all on my test page.
The test page is here: http://leuksman.com/misc/svgtest/
Anyone have ideas for working around these problems in a sensible way, or is real inline SVG that "just works" like our other images just out for now?
-- brion vibber (brion @ pobox.com)
On Mon, 2004-11-10 at 20:02 -0700, Brion Vibber wrote:
- Some Mozilla users on Debian reported not seeing any image at all on
my test page.
Mozilla (Firefox)? doesn't have the built-in SVG support on Debian; this is due to conflicts with desktop environments like Gnome. There's a bug for it somewhere that I can dig up if someone needs it.
Anyone have ideas for working around these problems in a sensible way, or is real inline SVG that "just works" like our other images just out for now?
Is there a good reason not to do content negotiation (see wfNegotiateContent() in GlobalFunctions.php) to determine if the browser can handle SVG?
~ESP
On Oct 11, 2004, at 8:31 PM, Evan Prodromou wrote:
On Mon, 2004-11-10 at 20:02 -0700, Brion Vibber wrote:
- Some Mozilla users on Debian reported not seeing any image at all on
my test page.
Mozilla (Firefox)? doesn't have the built-in SVG support on Debian; this is due to conflicts with desktop environments like Gnome. There's a bug for it somewhere that I can dig up if someone needs it.
Mozilla & Firefox don't have the built-in SVG support anywhere, so far as I know, since they refuse to enable it in the default build. The expected result if there's no built-in support and there's no plugin (such as the Adobe SVG viewer plugin) is that the PNG would show instead -- and that's exactly what happens on Mozilla 1.4.1 packaged by Fedora Core 1 and Mozilla 1.7.3 packaged by Fedora Core 2 and Firefox 0.10.1 packaged by the Mozilla Foundation for Win32.
However, two users of Mozilla 1.7 on Debian have claimed to see just a big gray box. If anyone knows why this is so, I'd love to know!
Anyone have ideas for working around these problems in a sensible way, or is real inline SVG that "just works" like our other images just out for now?
Is there a good reason not to do content negotiation (see wfNegotiateContent() in GlobalFunctions.php) to determine if the browser can handle SVG?
Mainly because you'd never find out about it that way...
Mozilla with Adobe SVG plugin: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ plain;q=0.8,image/png,*/*;q=0.5
Safari 1.2.3 with Adobe SVG plugin: Accept: */*
Internet Explorer 5.2/Mac OS X with Adobe SVG plugin: Accept: */*
Opera 7.54 with Adobe SVG plugin: Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
-- brion vibber (brion @ pobox.com)
On 12 Oct 2004, at 06:32, Brion Vibber wrote:
Safari 1.2.3 with Adobe SVG plugin: Accept: */*
Let me add:
If you DON'T have that plugin installed, you're getting an unwieldy error message (sheet) of:
Safari cannot find the Internet plug-in
The page “SVG test” has content of MIME type “image/svg+xml”. Because you don’t have a plug-in installed for this MIME type, this content can’t be displayed.
despite the page
saying that one should not receive any dialog boxes.
-- ropers [[en:User:Ropers]] www.ropersonline.com
Brion Vibber wrote:
Mozilla & Firefox don't have the built-in SVG support anywhere, so far as I know, since they refuse to enable it in the default build. The expected result if there's no built-in support and there's no plugin (such as the Adobe SVG viewer plugin) is that the PNG would show instead -- and that's exactly what happens on Mozilla 1.4.1 packaged by Fedora Core 1 and Mozilla 1.7.3 packaged by Fedora Core 2 and Firefox 0.10.1 packaged by the Mozilla Foundation for Win32.
For Firefox, although the default builds don't have SVG support, there are special builds with the support every now and then; this currently has two SVG-enabled builds, one for Linux and one for Windows:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/contrib/latest-trunk/
There's also a more stable (0.9 branch) version for Windows at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/contrib/latest-0.9/
For Mozilla, there are currently two nightly builds for Linux, and three for Windows (you can choose between the GDI, libart, and XTF implementations):
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/contrib/latest-trunk/
-- brion vibber (brion @ pobox.com)
(ImageMagick, Batik, or sodipodi/inkscape though I've had trouble getting those last two working).
Not sure the exact nature of your problem; but at Wikisophia, I resorted to an Xserver Virtual Frame Buffer.
- No transparency support for plug-ins. All tests I did showed the
SVG image on a solid white background.
Aye, that's the rub; what need we transparency? Opaque PNG's render more efficiently.
-- Peter Danenberg . wikisophia.org ..:
On Oct 11, 2004, at 8:54 PM, Peter Danenberg wrote:
(ImageMagick, Batik, or sodipodi/inkscape though I've had trouble getting those last two working).
Not sure the exact nature of your problem; but atWikisophia, I resorted to an Xserver Virtual Frame Buffer.
From a terminal they work fine with the -z (--without-gui) option, but on a shell out from PHP running under Apache they segfault. I've only tested this on my Mac so far, so it may be an idiosyncratic problem.
Actually, on second look sodipodi works from a shell and crashes from Apache/PHP but inkscape crashes both ways. I'll work through the backtrace and see if I can find something sensible. (I'm using packages from fink's unstable branch, compiled from source.)
Batik works fine with the headless AWT option, and produces very pretty output. ImageMagick produces lower quality output and doesn't scale up nicely -- it seems to render at some native screen resolution and then scale the rasterized version, at least with the command line I used.
- No transparency support for plug-ins. All tests I did showed the
SVG image on a solid white background.
Aye, that's the rub; what need we transparency? OpaquePNG's render more efficiently.
People put images on top of colored backgrounds and then complain that the background doesn't show through.
-- brion vibber (brion @ pobox.com)
On Oct 11, 2004, at 9:24 PM, Brion Vibber wrote:
(sodipodi/inkscape
From a terminal they work fine with the -z (--without-gui) option, but on a shell out from PHP running under Apache they segfault. I've only tested this on my Mac so far, so it may be an idiosyncratic problem.
The problem was that the Apache user (www) on Mac OS X has a home directory that it doesn't have permission to write to. When sodipodi and inkscape try to initialize their profile data they try to create a ~/.sodipodi or ~/.inkscape directory if it doesn't exist; then when it's unable to create the directory it tries to display a GTK+ dialog with a warning message.
Whoops! Can't display a GTK+ dialog box when there's no X11 server, can we? Eventually a massive failure to check for error conditions leads to a segmentation fault, where a graceful printf() would have sufficed.
Creating www-writable .inkscape and .sodipodi directories in /Library/WebServer has sidestepped this, and they now both work fine.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org