Mozilla Gets (Beta) Native SVG support
Rushuru writes "Mozilla is getting a beta native SVG support. Previously one had to use 3rd party plugins such as that from Adobe, and they only worked on windows. SVG is similar in scope to Flash, but it is a W3 recommendation (i.e. a standard) and uses an open format. The project page has more info."
mozilla svg samples
Check the SodiPodi galleries. They got all sorts of stuff including flags, corporate logos, animals, tux, and cartoons.
Err...no. From the article:
SVG is similar in scope to Macromedia's proprietary Flash technology: among other things it offers anti-aliased rendering, pattern and gradient fills, sophisticated filter-effects, clipping to arbitrary paths, text and animations.
You could already have seen some of SVG through the mozilla-bonobo plugin. As this plugin actually activates Eye Of Gnome for the image viewing, and EOG is actually more of a pixel-graphics viewer that happens to read SVG through the (still lagging) librsvg, the capacities are limited though.
For instance, you can only view SVG images as object tags, and complex stuff (like copied/ rotated graphics) aren't rendered well. (And it just so happens that Sodipodi produces SVG with a lot of copied/ rotated objects.)
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Bonus: All the images in the above galleries are Open Source, unless otherwise stated! (Quite literally, because SVG files are like "source code" for a vector image.)
As for SVG creating and editing software, apart from the new dSVG software announced earlier today on Slashdot, we have:
(Get your easy installable RPMs for Batik, and many other Java projects, at jpackage - but good luck finding a download link that works! Batik 1.5 hadn't propagated to all the Sourceforge mirrors when I tried it last night - so try all the US mirrors, it will be on at least one of them. Also, because of the numerous dependencies, it's recommended to use a smart package manager that can automatically resolve dependencies, like apt-get or urpmi.)
Female Prison Rape in NY
You are wrong, scripting is just one possibility. You can also write animations purely declaratively using elements like <animate> or <animateMotion>, see the animation chapter in the SVG spec. Another possibility is SMIL.
Programming can be fun again. Film at 11.
Previously one had to use 3rd party plugins such as that from Adobe, and they only worked on windows.
/ main.html
The Adobe plug-in works fine on MacOS 9 and MacOS X.
There are even betas for Red Hat Linux and Solaris 8, though I have no idea how they fare.
Check:
http://www.adobe.com/svg/viewer/install
This is untrue as the plugin crashed in Windows. The release notes have noted this all along. Only a seperate build(branch) of Moz had native SVG support.
I don't know why everybody has latched onto SVG == open Flash. SVG is just vector graphics. SMIL is closer to Flash in terms of functionality.
SVGmaker gallery
Kevin Lindsey
Adobe examples
Andreas Neumann's Vienna GIS example
I would assume that just like Mozilla let's you block graphics it will eventually let you turn off svg's. I also just found out about the flash blocker,
Flash Cick to View. It's part of the Firebird extensions but also works great on plain mozilla 1.4 if you get it from the author's page.
With no popups, no ads and no flash, the web is usable.
While on the topic of "SVG/SMIL != Flash" (or is, whatever), see also here. Though it is a book promotion website, there are lots of comprehensive examples on SVG, scripting SVG through Javascript (similar to simple Flash buttons) and combining SVG with SMIL.
That is, the W3C website says the link is also about SMIL. I'm still looking for that link.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Last I heard, maybe they were going to support the static SVG mini-spec or something. I'd be surprised if they dropped the policy of not including half baked implementations now.
There are no free software authoring environments. Flash is open as long as you have the Flash program, or maybe SWiSH, all of which are proprietary and mostly expensive.
As one of the mozilla SVG developers I find it a bit funny that a user creating a freshmeat site to stash their copy of a mozilla svg build is slashdot news. there are daily win32 builds ( from both the trunk and branch SVG trees) posted to ftp.mozilla.org and about monthly linux ( RH7.1) tar.gz. and have been since mozilla 1.0
There is still no agreement to make SVG part of the base GRE install, the current effort is to re-merge the SVG devel branch back to the trunk
dave
In addition, most plugins (at least which I have tried) also support SVGZ directly (standard gzip'ed SVG), both from the local disk and from the internet. Normally this compresses somewhere in the ratio of 80-90% (there is however still a few problems with large SVG-files in the plugins, so I would not recommend files with a native size over 1-2MB)..
mats
One man's ceiling is another man's floor.
Mozilla.org has already refuted allowing it be distributed by default in the bug which allowed libart to be checked in to the tree under the other-licenses/ directory of the cvs repository. The reasoning was that Mozilla sources are released under the MPL and the extra license could potentially cause extra headaches for distributors (as far as ensuring compliance with them, keeping track of them, etc.). Additionally, there are already enough licenses for distributors to deal with, and Mozilla.org should be looking to decrease that number, not increase it.
I tried Windows SVG_20020806_BRANCH/GDI+ just now, and pointed it at text-text-BE-01 in the 'mozillified' W3C SVG conformance suite at http://www.croczilla.com/svg/fosdem2003/w3c-confor mance-suite/mozillified-suite.html.
Mozilla crashes when it encounters that, both on an NT4 SP6 machine, and newer OS.
Mind you, SVG text is also a challenge for Adobe's viewer (v3) - if you try to view a multipage textual document, Adobe's viewer only displays the first page, and gets the kerning wrong, running words together.
IIRC from when i tried it a month or 2 ago, Corel's did a better job with SVG text, but right now, i can't get Corel's viewer to run properly anywhere :(
Bottom line:- you'll likely be disappointed if you are looking to display SVG text in a web browser today
SVG is actually much broader in scope than Flash, PDF, or other proprietary formats, as aptly pointed out by Paul Presod at SVG Open 2003.
Furthermore, the XML project of the Apache Software Founcation is hard at work on Batik, a Java-based toolkit for applications or applets that want to use images in the SVG format.
A lawyer & digital forensics examiner. Also an expert on open source software (OSS).
> That's like saying you can make animations with HTML just because you can access HTML tags through the DOM and script them.
Um, no it's not. SVG (Scalable Vector Graphics) is a markup language for producing vector graphics, which HTML most definitely isn't. Right there in the name, even.
No soup for you.
Il n'y a pas de Planet B.
zlib is completely free (and hence is used in a LOT of comercial software)
SVG has a long way to go before it will be suitable for data visualization. Most real world visualizations are based on large datasets and require a certain degree of interactivity. Both of these are possible using SVG. However, coding up an interactive application using JavaScript and the DOM model favored by the SVG designers is a non-trivial task.
A typical data set may contain 10,000 or more elements (e.g. financial analysis, temperature/forcast data, usage stats for a medium size web site, marketing data for a product line). Immediately, this requires a DOM tree with at least that many nodes. Given that each node requires a certain amout of meta-data and a containment heirarchy, the amount of data that needs to be transferred between the client/server, parsed, and managed in the browser grows quickly.
Ignoring the physical challeges of using DOM, there is also an abstraction challenge: Not all data fits nicely into the tree/scene-graph paradigm embraced by SVG. Of course, data can be transformed to use this model, but manipulating the data will be much more challenging.
Assuming a suitable DOM representation of the data exists, the next challenge is developing the JavaScript to allow the user to explore and manipulate the data. With no real package support and no built-in way to manage a large code base, JavaScript is not the ideal language for developing reusable vis code.
Before data visualization becomes commonplace in SVG browsers, another abstraction will need to be built on SVG that addresses the specific needs of the data vis community. This could be in the form of libraries that abstract the SVG frameworks with data vis APIs or another XML dialect that can be transformed into SVG.
I'm holding out hope that the SVG community will slow down on the feature creep and architecture bloat and focus on developing applications with the currect standard. Only by stepping back and trying to use the current system will the architects of SVG know what's missing and what needs improvement.
-Chris
Sorrowly, this has already happened; Adobe hasn't updated their plugin since 2001 and is lacking support for everything newer than the 1.0 standard.
This is not true. Adobe has an alpha with support for SVG 1.2.