Slashdot Mirror

Posted at 11:37AM
(e.g. Firefox) http://www.croczilla.com/svg/samples/svgtetris/svgtetris.svg

Posted at 11:52AM
Wow, where did THAT hour go?....

It clearly went into some sort of timewarp where an hour now equals 15 minutes...

(e.g. Firefox) http://www.croczilla.com/svg/samples/svgtetris/svgtetris.svg

SVG is designed for still vector images and animation on the order of animated gif (IE, short and no sound). Nothing else.

SVG can do a lot more.

It may not do everything that Silverlight of Flash can, but SVG + Javascript can do what is actually useful: the important exceptions are embedded media players and games.

Try drag and dropping an SVG file onto a Firefox 3 window. Browsers STILL don't support vector graphics.

Works for me.

http://www.croczilla.com/svg/samples/butterfly/butterfly.svg

renders just fine in mozilla. Saving it to my desktop and dragging it back into firefox works too.

Can't find any. There are several open source SIP/Voice tools but with Multi-point nope.... Ekiga/GnomeMeeting - http://ekiga.org/ ZAP - http://croczilla.com/zap SFLPhone - http://www.sflphone.org/ OPenWengo - http://www.wengophone.com/ Can anyone list some one? or should the community should try to evolve this projects ?

Yes, I understand that there are certainly dissenting opinions here. But (IMHO) the thing that most Slash-bots complain about is that Microsoft will

A) Pick a feature that's dumb. (like embed a scripting language into an image format, or give a spreadsheet scripting language access to the filesystem)

You missed Moonlight

Seems like an as-yet unsolved problem.

There have been proposals to have a centralized mozilla bounty system at mozilla.org, but they've been dismissed as WONTFIX in anticipation of human conflict becoming distracting to those with authority over the code base.

Some, like Mark Shuttleworth, once held hope for more support for bounties from Mozilla, such as a bugzilla feature to associate bounties with bugs. That hope seems to have disappeared.

Mozilla-related Wiki attempts have also disappeared, and the other websites out there seem to lack critical mass.

However, Mozilla has started a limited bounty program for security bugs, with help from long-time bounty advocate Mark Shuttlesworth.

As far as the mechanics of moving money around, http://fundable.org/ might be an option.

other sites
----------
http://bountycounty.org/
http://www.opensourcexperts.com/bountylist.html?bo untytype=1&cat=33
http://croczilla.com/zap/bounties/

SVG is supported in the current Gecko version (since FF 1.5, at least) "without a plugin or other hackery":

http://www.croczilla.com/svg/samples/

I think SVG and CSS3 (possibly even version 4) along with more AJAX/JavaScript/OpenLazlo/Flash/Flex are what Web 3.0 would be about.

Although unless the most popular browser (IE) supports SVG and CSS3 by default I dont see it happening.

I've seen some impressive things with SVG and JavaScript.

SVG in 1.5.0.2 is a little busted -- one of my relatively simple SVGs took out the browser. That bug is fixed in 1.5.0.3.

Samples, including Tetris in Javascript + SVG:
    http://www.croczilla.com/svg/samples/

-- Azaroth

Installed on Win, co-exists with 1.5 peacefully.

Yay for the Safari/Camino-style tabs with Close buttons right on the tab. On a 21" monitor, it was weird flying over to the top-right corner to close a tab that was in the top-left.

The new bookmark manager is unfinished, but I frankly don't use it much anyway. Seems ok, just not exciting.

I am excited about SVG, though. Play with it here: http://www.croczilla.com/svg/samples/

Tetris. Man I love that game!

Yeah. And now that FireFox 1.5 has SVG graphics built in, Tetris is just a . click away.

Yes, that's an Adobe plugin test. Try this.

Talking of overhead. If you look at the code you will find that it isn't actual 3D either, just emulated 3D using math and gradients. Add to this that it running in entirely in software. No hardware rendering at all. No wonder it's so slow.

As a proof of concept it isn't bad, but current implementations of the technology(SVG in this case I believe) do not make decent use of available hardware, which is a pity. If the browser used the GFX chip for rendering this I imagine it would be a lot faster.

Best stick to uncomplicated 2d stuff like tetris for now.

It's faster.

Go to any page with 100+ image on it. Click on an image to view it, and then click Firefox's back button. You're back in an instant to the page w/100+ images.
Try the same experiment w/Firefox 1.0.x. It's sloooooooooow returning to the previous page.

Also, SVG (Scalable Vector Graphics) support is turned on in 1.5. Send someone to http://www.croczilla.com/svg/samples w/Firefox 1.5. All the images there are vector based, and several are dynamic (click around). Check out 'XBL Shapes' near the bottom. Very cool! And SVG is a native implementation in Firefox, so you don't have have that wretched browser after thought feeling that Flash gives. Personally, I've been waiting ~2 years for SVG support to be turned on in Mozilla/Firefox. Expect to see a slew of cool SVG sites popping up in the next 6 months!

I could go on...

Or how about a certain well-known Russian puzzle game?

Maybe they plan on discontinuing the Flash series so that SVG powered sites can take over in their stead?...lol Probably not, but the combination of SVG being built into Firefox and Opera now along with their continued lack of 64bit support sure ain't gonna help 'em out too much ;)

Tried the samples at http://www.croczilla.com/svg/samples/? Using this 1.5 beta, they Work For Me.

SVG is built into 1.5 beta 1! There are a number of samples that you can check out at http://www.croczilla.com/svg/samples.
I especially like the SVG Tetris game.

Here's a site with examples, if you want to test it out.

Works for me. Here's a good page of samples for you to check out:

Croczilla SVG Samples

Er, sorry, that SVG demo link I provided seems a bit non-functional :). Try this instead.

The SVG implementation is there in Deer Park, the test version of Firefox 1.1. Examples here

It's about time! :)

I always thought Mozilla's smooth and transparent SVG implementation was leaps and bounds over Macromedia's Flash plugin which feels like a second-hand browser afterthought.

I envision thousands of pages springing up w/sweet SVG content running in Firefox/Opera only (WebCore/KHtml too?). As Internet "power" users will naturally want the full Internet experience... they'll jump the IE ship in droves!

An earlier poster claimed IE would have support for SVG (via the buggy Adobe SVG plugin?), but I don't imagine IE will implement this natively for 7.0. Again, I question IE's support for SVG until I see a substantiated web reference claiming so.

Note: Current bee's knees for SVG samples: http://www.croczilla.com/svg/samples/

and when will all the browsers support it..
http://www.adobe.com/svg/viewer/install/main.html
the simple stuff already works with:
http://www.mozilla.org/projects/svg/
samples

The rotoscoped screenshots' style is quite reminiscent of SVG images such as Lion (PNG) and Tiger (PNG). The strong, solid lines lend themselves to vector rendering. Perhaps the entire movie could be thus done in SVG?

The rotoscoped screenshots' style is quite reminiscent of SVG images such as Lion (PNG) and Tiger (PNG). The strong, solid lines lend themselves to vector rendering. Perhaps the entire movie could be thus done in SVG?

The rotoscoped screenshots' style is quite reminiscent of SVG images such as Lion (PNG) and Tiger (PNG). The strong, solid lines lend themselves to vector rendering. Perhaps the entire movie could be thus done in SVG?

The rotoscoped screenshots' style is quite reminiscent of SVG images such as Lion (PNG) and Tiger (PNG). The strong, solid lines lend themselves to vector rendering. Perhaps the entire movie could be thus done in SVG?

I wish Mozilla (and friends) would ship with --enable-svg compiled by default.

I know the SVG implementation in Mozilla isn't 100% (the builds I've tried do crash more often), but neither has the DOM-JavaScript implementation been 100% in all the major browsers all these years, and we've worked around it (albeit a pain but) with great success.

I say turn SVG on by default and let the SVG websites a cometh. Soon enough you'll have the Mozilla crowd surfing a slew of fantastic SVG sites and their IE friends will be jumping ship in droves.

You can wet your whistle by grabbing the Mozilla-Firefox SVG build for Linux/Solaris and experience the fantastic SVG work at Croczilla. The bezier-paths demo shows some serious potential.

The progression for better SVG implementation in Mozilla (or any browser for that matter) will go hand in hand with the easy availability for the user to be able to browse these websites w/o jumping through hoops.

<last-blurb-of-nonsense>SVG is a native implementation in Mozilla, so the end effect is completely smooth and transparent unlike Macromedia's Flash which feels like a browser afterthought.</last-blurb-of-nonsense>

I wish Mozilla (and friends) would ship with --enable-svg compiled by default.

I know the SVG implementation in Mozilla isn't 100% (the builds I've tried do crash more often), but neither has the DOM-JavaScript implementation been 100% in all the major browsers all these years, and we've worked around it (albeit a pain but) with great success.

I say turn SVG on by default and let the SVG websites a cometh. Soon enough you'll have the Mozilla crowd surfing a slew of fantastic SVG sites and their IE friends will be jumping ship in droves.

You can wet your whistle by grabbing the Mozilla-Firefox SVG build for Linux/Solaris and experience the fantastic SVG work at Croczilla. The bezier-paths demo shows some serious potential.

The progression for better SVG implementation in Mozilla (or any browser for that matter) will go hand in hand with the easy availability for the user to be able to browse these websites w/o jumping through hoops.

<last-blurb-of-nonsense>SVG is a native implementation in Mozilla, so the end effect is completely smooth and transparent unlike Macromedia's Flash which feels like a browser afterthought.</last-blurb-of-nonsense>

The Mozilla SVG project started as part of the Crocodile Mathematics project, although its checkin to Mozilla CVS didn't happen until December 2001

• Big areas of the SVG specification where we're still lacking include clipping, filters and declarative animations.

You can see screenshots of what the patched Mozilla is capable of here. It can do basic drawing of shapes. However, without filters (eg. embossing, shadows, etc) or animation (eg. smoothly interpolate a color or shape from one state to another), much of the really sexy parts of SVG aren't available. And if you have a stock browser, none of SVG will be available until the code's good enough to bring in.

Ok, I've been following SVG for a little while and I'm excited about its prospects.

Most of you have probably seen the SVG demos at Croczilla.

I once had a Mozilla 1.3 Alpha with SVG build, and it rendered these files perfectly. I was using Red Hat at the time.

Now I'm using Gentoo, and I emerge Mozilla with mozsvg in my USE flags, which of course builds an SVG enabled Mozilla. Cool.

Except that the croczilla files look like crap. They are rendered B&W, all color is gone. AND the image gets corrupted every time 1) you open a menu over it, or 2) part of it is manipulated with DOM. None of this was a problem with that old build I had.

I also just downloaded the latest SVG build from Mozilla's site, in case there was something wrong with the ebuild process. It had the same problems.

My questions:

1. Is everyone else getting the same screwed up results when viewing SVG in Mozilla? If not, I'm wondering if there's a problem with a library I have installed.

2. Has anyone tried the Croczilla files with a recent Konqueror CVS? Do they work? Including the DOM transformations?

Thanks!

1. 
   
   always the first place one should start
   
   Samples#1
   
   samples#2
   
   examples#3 (part of a SVG webring)
   
   examples#4 (it also answers the question. Who uses this?)
   
   ditto#2
   
   Adobe plugin (shoots down the "hasn't been updated in years" argument)
   
   Too imature for you?
   
   Oh yeah! Immature, and it has a browser plugin too
   
   

The current mozilla build expects text/xml mime type for SVG rather than image/svg+xml . Because of this, you can only render SVG when it has the xml mime type.

Mozilla say it has put out a branch to deal with this by including a mime type synonym from image/svg+xml to text/xml:
Mozilla SVG Samples:

News
The mime-type issue (bug #160882) and a whole load of other things are now fixed in SVG_20020806_BRANCH builds.

foreignObject support is fixed for gtk2 builds on SVG_20020806_BRANCH


but I can't find it... My version of Mozilla (Mozilla 1.5b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030720) does not appear to have bug #160882 (mime-type) taken care. I guess this is because it's not a branch build.

This problem comes from a long-standing argument between the w3c and mozilla. The plugin vendors (Corel and Adobe) have gone all practical on us and decided to use the generally accepted image/xvg+xml mime type as recommended by the W3C, but since nobody has bothered registering this mime type, this is actually an *INVALID* mimt type. This means that now developers (I am developing SVG apps on roasp.com ) have to support both mime types. This is a problem.

It seems that the mime type issue originates in the need of the browser plugins to have their own mime type in order to recognize plugin-handled content.

A serverside solution is to server SVG content dynamically and allow a mime=xml|[svg] parameter in my query strings, or some other similar kludgy workaround. Alternatively, if you know how, you can test for supported mimetypes. or for plugins.

None of these options is really palatable.

Ronan
Use SVG;
Serverside SVG Portal

mozilla svg samples

You mean as in "Does a bear in the woods?"

Not to diminish the valiant efforts of the sparsely populated team of Moz SVG developers, but the Moz SVG viewer tends to crash more and lag in level of standards implement when compared to Adobe's SVG viewer.

Keep looking here to find out.

If they used SVG, people using the official Mozilla builds wouldn't be able to view it.
you are correct.

How well do you think that would go over? Everyone would be crying about how they were locking out open-source browsers.
here, i disagree; initially, there would be a hurdle, yes. but then people would see a need for further development and lend a hand. croczilla isn't as far from ready (for alpha/beta, perhaps to integrate into moz1.4a) as people may think.

the main reason I've taken the time to mention SVG here is because it gives the recommendation some visibility amongst those who can help OSS implementations like croczilla out there.

flash started the same way, but it is a propietary standard. i would much rather use a propietary plug-in that implements an open standard than a propietary plug-in that uses its own closed standard.

And set up your API's on data streams so that you NEVER waste a cycle pumping data one pixel beyond what's visible.

And thus incur a performance overhead on every single drawing operation as the API keeps track of what's visible or not.

Your suggestion is valuable in some cases, but its up to the application author's knowledge of how much data will be drawn, and where it comes from. (Better worst-case performance, but slower in average cases)

In a highly controlled game environment, the level designers can be trusted to create only objects simple enough to display all at once (without any tricky checking- you can move the visibilty checking to design-time)

But yes, for a generic 3d editor, someone's going to copy his 600 polygon cylinders to start building a forest of tree stumps, and individual refreshes could grind to a halt. (For a first-hand view of this problem in action, try a recent build of Sodipodi. Load a medium sized file, the tiger for instance, and then try to scroll around with the mouse)

SVG support has been a difficult issue in Mozilla because of the rich canvas. As you say, the XML parser and DOM and CSS parser and inheritance and XLink simple linking and JPEG and PNG and ECMAscript are there already.

The Mozilla SVG project started off by using Raph Levien's rendering library libart, which is only licensed to be used under the terms of the LGPL and not the standard Mozilla MPL/GPL/LGPL tri-license.

So, that licensing issue held up getting SVG code into the trunk, and when it was in ther trunk, stopped it being in the core builds (it was there in CVS and could be enabled at compile time). It worked on Linux, MacOS, Windows, etc - it was very cross platform code but there was the licensing issue.

A new approach is to split the rendering code into platform-independent and platform-dependent parts. A test of this approach is available from the croczilla site (which has a bunch of great examples too) - there is a build that uses the GDI+ renderer suplied with Windows 2000/XP. Clearly, this avoids the license issue o the rendering library and clearly, it means there needs to be a separate platform layer for each supported OS (darwin on MacOS X, perhaps different linux layers for Gnome or KDE, etc)

I know the Netscape folks are aware of this, too, because I visited Netscape and gave them a demo which included Mozilla SVG among other things.

The Mozilla SVG implementation is a native SVG implementation. This is as opposed to plug-in SVG viewers such as the Adobe viewer (which is currently the most popular SVG viewer).

Some of the implications of this are:

• Mozilla can handle documents that contain SVG, MathML, XHTML, XUL, etc. all mixed together in the same 'compound' document. This is being made possible by using XML namesspaces.
• Mozilla is 'aware' of the SVG content. It can be accessed through the SVG DOM (which is compatible with the XML DOM) and manipulated by Mozilla's script engine.
• Other Mozilla technologies can be used with SVG. XBL coupled with SVG is a particular interesting combination. It can be used to create graphical widgets (I wonder when we'll see the first SVG-based chrome!) or extend Mozilla to recognize other specialized languages such as e.g. CML (chemical markup language). There are samples of these kinds of more advanced usage patterns on croczilla.com/svg/.

I don't agree that the SVG viewer is flaky: the implementation is proprietary, but SVG itself is an open standard and this free software lets one "View Source" which alone far surpasses Flash: the "View Source" aspect of HTML is in large part responsible for its success as a language authored effectively by a large number of people.

The Adobe Viewer is only one of many ways to enjoy SVG. The Batik project is a fantastic Open Source implementation.

There is a Mozilla build by Alex Fritze that facilitates inline SVG (something that the Adobe Viewer is just starting to support in IE). That is an example of a "single current browser supporting SVG natively"... of course it's not yet in the main Mozilla build.

But SVG is not just for browsers: it can run in applications and on the server. It is far more than just a replacement for Flash...

Max

Browsing SVG

The only browser plug-in for SVG right now is Adobe's, and it only works in NS4 and IE5 for Mac and Win32. However, there is a rapidly-developing Win32 SVG-savy branch of Moz by Alex Fritz. No text support yet, alas, but the author suggests that it should be easy to port to other platforms.

Generating SVG

Sodipodi is a Win/Linux vector graphics program with SVG at its heart -- well worth a look. Sketch runs in Python and includes SVG in its import/export set. I've had good luck transforming complex Illustrator diagrams into SVG using Sketch.

On the Win platform, I'm quite fond of Jasc WebDraw; it's in beta and a fully functional demo is provided.

Finally, the versitility of the Batiklibrary is staggering. Written in Java, it includes a viewer, transcoders to png and jpg and a very cool Graphics2D implementation. The latter allows anything graphics that can be drawn to a java G2D panel to be instead output as SVG. This is a great way to get font dimension info for precision layout of SVG, as we've done building dynamic timelines at the Historical Event Markup Project.