Fraggle writes "Recently the Mozilla Foundation and Adobe announced a partnership, working together on the next generation
JavaScript/ActionScript JIT Virtual Machine. The Browser Den looks at what this means for the future of scripting in Mozilla, and how this partnership with Adobe may affect Mozilla's support for other technologies such as SVG." From the article: "On the Mozilla side the plan is to integrate to code with SpiderMonkey which is Mozilla's current JavaScript implementation that is written in C. This is needed because Tamarin is not a drop-in replacement for SpiderMonkey as it provides necessary features that are not available in Tamarin. The combined SpiderMonkey with integrated Tamarin should not have any problems with old JavaScript and should show a performance boost for most. However, skilled scripters are sure to find ways of optimising performance to get even more gains."
Don't disparage something you don't understand. It's like saying you hate all music cause you heard a few Britney Spears songs.
No, it is like saying you don't want a radio without an "off" button.
Most Net Flash content is crap. It's mainly used for ads. I, for one, surf with FlashBlock and only allow the damn thing to play when absolutely neccessary.
I can't speek for the GP, but I understand Flash. Flash is about giving control to the content producers at the expense of the consumers. I am a comsumer who likes control, ergo I don't like like flash.
I am using a 64 bit Ubuntu 6.10 operating system with the latest firefox 2.0 browser. I can not get any flash to work or any video player. I tried downloading from Adobe and they state they do not support 64 bit. I tried automatix and downloaded a 32 bit firefox and when I download the plugins I get a error message. If I retry to install them, the programs states that they are already installed but when I tell it to reinstall them I get the same error I got before. I like this 64 bit firefox because I w
I've seen some very slick applications written in JavaScript. It can be quite powerful. One feature I really like and put to good use is the eval method - take any string and treat it as a piece of code and run it. It also does some funky things with enviroment contexts (can't remember the right term) where you can define a function that references a variable in the outer function, then pass function off to somewhere else. Later on when you call it from some unrelated code, the variable in the outer fun
I'm toying around with embeddable language interpreters to use in my current hobby project, and I'm very fond of lua. I recently discovered javascript, which I didn't give much attention before, and I was surprised to discover that it's actually a pretty good language. It pretty much does all the things I like in Lua (functional programming among other things), and even a few more things that could be useful to me.
The downside is that lua currently beats the crap out of it when it comes to performance. The ne
The downside is that lua currently beats the crap out of it when it comes to performance. The new JIT VM from adobe should reverse this tendency (at least regarding speed, maybe not regarding memory footprint).
Some speed benchmarks of Tamarin vs. Spidermonkey are here [playercore.com].
Some additional benchmarks of Flash Player 9 (which is essentially identical to Tamarin in this context) vs SpiderMonkey can be found here [oddhammer.com].
Despite its popularity, few know that JavaScript is a very nice dynamic object-oriented general-purpose programming language. How can this be a secret? Why is this language so misunderstood?...
...JavaScript's C-like syntax, including curly braces and the clunky for statement, makes it appear to be an ordinary procedura
On the Mozilla side the plan is to integrate to code with SpiderMonkey which is Mozilla's current JavaScript implementation that is written in C.
I presume the article means to say that the Tamarin engine will be coupled with SpiderMonkey's APIs? Because I don't see how you could "combine" two separate Javascript engines and expect a usable result. That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.
I wouldn't be so sure, there will be many more working on Tamarin then on the Neko VM [nekovm.org].
But who cares which one will be first, haXe [haxe.org] can be compiled for both.:)
>That would be like "combining" Windows and Mac OS X to make a better
>operating system. It doesn't quite work that way.
FX: Head of Vista development team "Doh!"
At the ajax experience [theajaxexperience.com] Brendan Eich spoke about this and without mentioning company names. The boost in performance in JS will cement web application's future and will bring javascript to the forefront even more as the power language that it is. Combine that with JSON [json.org] and the module tag [json.org] proposal, it should be some very interesting times.
For those who don't follow the project tightly, there are indeed a slew of implications.
On the side of Mozilla, it means much faster, JIT JS engine, and since you know that Firefox's XUL depends heavily on JS to run, it may have big impact on the performance of Firefox as a whole and change the perception some have of Firefox as "bloated" and "slow".
This is just a guess though. Here's what's really fun.
Adobe is now working on its next generation "web platform", code named Apollo. Apollo's long term goals are to merge Flash, HTML/JS/CSS and PDF in one single "web platform", for internet applications.
Apollo is not a browser, you can think of it sort of like the.NET or Java runtime. Or well, Adobe wants you to think that.
The first version of Apollo is not going to merge all three technologies into one, but it'll integrate them to work together. This means, you can have Apollo app that is based on AJAX with flash in it. Or Flash project with HTML in it. Or, I guess, Flash with PDF in it.. All sorts of combinations.
Adobe announced that they will NOT develop a browser on their own for Apollo, and that they are researching what to use.
I'll be honest, I thought it's apparent they'll pick Opera. Opera is faster than Firefox, it's portable to mobile platforms (and this is important to Adobe), and both Macromedia and Adobe have rich partnership with Opera already.
For example, Dreamweaver's WYSIWYG on Mac used to be Opera for a long time, and maybe it still is (on Windows, as far as I know, it's custom built).
And even now, the entire help system of Adobe uses built-in Opera browser. Even their "Bridge" image browser, is in fast running on Opera.
But now, as they contribute big chunks of Flash 9 (the script engine) to Mozilla, it means only one thing: Adobe has decided on a browser.
Apollo will feature a version of Gecko with Tamarin for a script engine.
Currently Adobe Reader (PDF) uses SpiderMonkey for its script engine, but when Tamarin is good enough to replace SpikerMonkey in Firefox, it'll be good enough to do it in Adobe Reader.
Hence, one step forward towards Adobe's vision of unified HTML/Flash/PDF platform. Interesting times.
Actually, it has been anounced [blogs.com] that Apollo will be based on WebKit, the framework that is behind Apple's Safari. They will be using the open source version rather than Apple's internal version, but the differences are minor.
Actually, it has been anounced that Apollo will be based on WebKit, the framework that is behind Apple's Safari. They will be using the open source version rather than Apple's internal version, but the differences are minor.
Interesting, didn't know that. It's strange that of all browsers on the market, Adobe will pick the least popular one, and one which needs a lot of work before it even runs on Windows (I know work is being done on it, but it's far from done).
Yes, but that work is minor compared to fixing Gecko's bloated code base. I'm sure Adobe chose KHTML (That is the real name WebKit) for the same reasons Apple did when building Safari: it's clean, it's fast, and it's standards compliant. I believe that KHTML (as Konqueror on KDE, and Safari on Mac) is the only engine currently passing the ACID2 compliance test. The guys on the KDE team have done an excellent job.
In addition, Apple has already shown that it's not a big deal to port KHTML.
Apple has already shown that it's not a big deal to port KHTML
Not to belittle their work, but they did "only" port it from one Unix-like system to another. Porting it to Windows will be rather more work, I suspect.
Well given that it has already been (partially) done, by one or two people working in their spare time, I doubt it's as difficult as you think. See here (it seems to be now defunct, but they did have a working release out at one point): http://en.wikipedia.org/wiki/Swift_(web_browser)/ [wikipedia.org]
When Macromedia started, they made great tools. They looked at what professional web developers wanted, and made neat tools to fulfil their needs. Unfortunately, for a while now they have been operating in an entirely different manner - they have been deciding where they want the technology to go, and then trying to push tools that fulfil their vision onto web developers. This has meant that their core products, such as Dreamweaver and the Flash development application, have been rapidly becoming crappier. D
The OpenLaszlo [openlaszlo.org] Legals Project [openlaszlo.org] will benefit immensely from this! OpenLaszlo is in a position to take excellent advantage of the now open source AMV2 JavaScript engine, for the benefit of users as well as developers. Not only will AVM2 make OpenLaszlo applications run faster on Firefox, but opening up the AVM2 virtual machine will make it possible to develop much more powerful debuggers and integrated development environments.
Plus, I'll bet that the JIT will be x86-32bit, Windows-only, meaning that on all other platforms, all you get is a much large JS engine than includes a VM.
The JIT is currently x86-32 for Windows and MacOSX, plus PPC-32 for MacOSX. There is also a prototype ARM implementation. x86-32 for Linux is functional but has not yet been merged into the CVS tree. x86-64 (Windows + Mac + Linux) is under development.
I find this idea a bit scary. HTML, Flash, and PDF do two completely different things, and attempting to combine them is not going to end with a super-browser but with a monstrous train-wreck something like Acrobat Viewer, which inserts buttons in my excel toolbar without asking, takes forever to load and is generally a waste of space.
There's not a lot of point in integrating tools that do the same thing. The functions of Flash, PDF, and HTML are complementary. Not that it means any given toolset to work
Despite all the harping,.NET has been a huge success for Microsoft in Corporate/Server development. On the desktop, just as MS is afraid of Flash and Firefox (not coincidental or surprising they linked up) obviating the need for , I think Adobe, et al have been concerned about the potential impact of WPF, etc. for what they call the RIA [kotay.com] space.
Some early benchmarks [kotay.com] comparing SpiderMonkey, what would become Tamarin, and JScript.NET. are on my site [kotay.com]... interesting is that neither CLR, nor Tamarin provide a big boost when you use the features of JavaScript that make it more interesting than just plain old C. Wonder how much a real world boost this will be for the integration complexity? (i.e. is this another Netscape 6? Perhaps buckling down and fixing SpiderMonkey might serve better...) -- graphically speaking [kotay.com]
They might be able to improve the new combined code to execute faster. This whole thing sounds a lot like Java to me. It will be slow starting up and after a page is loaded, it can execute very quickly. Based on recent research for ecommerce sites, I suspect this may have a negative impact on Firefox adoption down the road. The point of JavaScript was to make a lightweight interpreted language that could glue together other components such as plugins, later java, flash and active x controls. I understand
It will be slow starting up and after a page is loaded, it can execute very quickly
Don't rush to judgement on this without looking at the code. One of the design criteria for the JIT was to avoid this problem. Flash Player 9 (which uses this VM) can load and start executing jitted code very quickly. (Is "jitted" a real word?)
"Despite all the harping,.NET has been a huge success for Microsoft in Corporate/Server development."
No it hasn't all they have done is to convert their VB programmers to VB.NET or C# programmers and they VC++ developers to C#. It's not like they converted java programmers or anything. The truth is that VB programmers were going to "upgrade" to anything MS put out no matter what it was.
I've seen some theories on the Internet suggest that part of the deal with Adobe was to remove the native SVG support from Firefox effectively reducing the competition for Flash.
There's no need for Adobe to make such a deal. Anyone who has tried using SVG on Firefox knows that the code renders so slowly as to be almost unusable, and lacks support for a tremendous number of SVG features. On top of that Adobe's own staff were always the big force behind SVG, now that Adobe has pulled out of SVG development its safe to say that SVG has no future outside of the tiny community of inkscape users.
The only way I could see them removing SVG support would be if Adobe ever decided to open source the Flash player but even then I could imagine that this would not be a popular move as SVG is an open standard.
Aside from the video codecs--which are no doubt entangled in far too many patent issues for Adobe to publish the standards--Flash is just as open as SVG, and it's a shame that open standards pundits refuse to stop pretending otherwise. It makes them sound just as stupid as the HD-DVD evangelists who pretend that HD-DVD is any less proprietary than Blu-Ray, and its hard to convince people that standards-based web development is important when this kind of garbage keeps getting spewed out.
SVG will eventually get yanked from Firefox not because of sleazy deals between Adobe and the Mozilla foundation, but due to the W3C not being behind SVG, SVG not having enough developers, the majority of SVG content on the web being experimental projects, and lack of software support for animated SVG content.
I can open up an.swf in notepad and see the source? I can inline flash elements in my (x)html page?
I'm allowed to write my own viewer for it?
BTW... Konqueror has good support for non-animated/non-scripted SVG already. Soon, it will fix those flaws as well. Webkit has about the same level of support, and there's a committment to make SVG a first-class image format for pages. Opera's support is stellar, including the animation/scripting parts. And Firefox isn't too shabby either.
I'm a huge fan of SVG. Not because it's a replacement for Flash, but because it's just XML, which means you can create data-based SVG images "out of thin air" with PHP or the scripting language of your choice. But now that Adobe has bought Macromedia (and with it, Flash) it looks like they're going to give up on SVG. [adobe.com] I'm sure their apps will let you save as SVG, but they're going to quit supporting the viewer on 1/1/2008. And theirs was the dominant viewer. Mozilla has native support, and Safari is getting it, but that's nowhere near the adoption rate of MSIE or Flash.*
I was really hoping that they'd go the other way--that with the purchase of Macromedia, they'd roll SVG support into the hugely popular Flash plug-in. I wish I were wrong, but my guess is that Adobe, just like MS or anyone else, would rather back a proprietary solution (that they own) than an open one.
* and, the funny thing is, the MSIE/Adobe combination--on Mac and Windows--was the best. You could print a page with lots of embedded SVG images, and it worked! Safari with Adobe's plugin, or Mozilla with the plugin or natively, would print each image on a separate page, if at all. (Though I haven't tested FF 2.0 yet.) But MSIE/Adobe printed just as you saw on screen.
I am with you on SVG. My take on it is that it is the browser's job to implement SVG well and it will take off from there. I have tried creating SVG-only pages with Inkscape and it turned out pretty well...
...but because it's just XML, which means you can create data-based SVG images "out of thin air" with PHP or the scripting language of your choice.
This was never the reason why SVG was promising. There have been imagine manipulation libraries available to scripting languages for a long time. I remember using GD in Perl to create GIF images "out of thin air" as you put it. That was in 1996.
The strength of SVG is that it's vector-based. This allows developers to produce images that can be resized on-the-f
It isn't a trap because it's impossible to trap anyone all the time the code is GPL'd. IceWeasel could easily benefit from this code as well (although i'm not saying I support IceWeasel or oppose the Adobe/Mozilla partnership). The *worst* that could happen is the Mozilla/Firefox 'brand name' becomes tainted and people move away from it in droves. How this could feasibly happen I don't know, it isn't likely at all. Either way I couldn't give a monkeys butt about the brand, I care about the product. So I real
Gecko 1.9 will be shipped in Firefox 3, currently scheduled for the May or November 2007, depending on which part of the Mozilla Wiki to belive*. From what I understand there are plans to release a Firefox 4 off Gecko 1.9, much like Firefox 1.5 and Firefox 2 are built off Gecko 1.8. So that would put these changes in Firefox 5 time frame, yes this is quite some time away. * http://wiki.mozilla.org/Firefox3/Schedule [mozilla.org] * http://wiki.mozilla.org/ReleaseRoadmap [mozilla.org]
Amazing (Score:2, Insightful)
HTML either, but that preconception was crushed when I saw the money those art school dropouts were making.
I just hope that they don't embed Flash player into the browser. That would suck royally.
Re: (Score:3, Interesting)
Don't disparage something you don't understand. It's like saying you hate all music cause you heard a few Britney Spears songs.
Take a look at OpenLaszlo. [openlaszlo.org]
Re: (Score:2)
No, it is like saying you don't want a radio without an "off" button.
Most Net Flash content is crap. It's mainly used for ads. I, for one, surf with FlashBlock and only allow the damn thing to play when absolutely neccessary.
Re: (Score:2)
I can't speek for the GP, but I understand Flash. Flash is about giving control to the content producers at the expense of the consumers. I am a comsumer who likes control, ergo I don't like like flash.
Re: (Score:2)
Re: (Score:2)
http://blogs.adobe.com/penguin.swf/2006/10/whats_
http://www.kaourantin.net/2006/10/flash-player-9-
Re: (Score:2)
Re: (Score:2)
I know Rexx and VBScript can also do that and I'm sure they're not the only ones. It's very handy but hardly unique.
Re: (Score:2)
Re: (Score:2)
I recently discovered javascript, which I didn't give much attention before, and I was surprised to discover that it's actually a pretty good language. It pretty much does all the things I like in Lua (functional programming among other things), and even a few more things that could be useful to me.
The downside is that lua currently beats the crap out of it when it comes to performance.
The ne
Re: (Score:2)
Some speed benchmarks of Tamarin vs. Spidermonkey are here [playercore.com].
Some additional benchmarks of Flash Player 9 (which is essentially identical to Tamarin in this context) vs SpiderMonkey can be found here [oddhammer.com].
Re: (Score:2)
From Javascript: The World's Most Misunderstood Programming Language [crockford.com]:
There goes the neighborhood (Score:2, Funny)
Say What? (Score:5, Insightful)
I presume the article means to say that the Tamarin engine will be coupled with SpiderMonkey's APIs? Because I don't see how you could "combine" two separate Javascript engines and expect a usable result. That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.
Re:Say What? (Score:5, Informative)
Parent
Re: (Score:2)
I bet on neko having AMD64 JIT first.
I wouldn't be so sure, there will be many more working on Tamarin then on the Neko VM [nekovm.org]. :)
But who cares which one will be first, haXe [haxe.org] can be compiled for both.
Re:Say What? (Score:5, Funny)
That sound you hear is the thousands of Microsoft Windows programmers kicking the dirt and going back to the drawing board.
Parent
Re: (Score:2)
>operating system. It doesn't quite work that way.
FX: Head of Vista development team "Doh!"
Re: (Score:2)
Why not? OS X is a train wreck of OS 9, BSD, Mach, and NeXT code and it works pretty well.
Slashdot (Score:2)
Reviewing this should be done with an eye to GPLv3 (Score:2)
Whether the deal is good or bad, or partly good and partly bad, it is a good example for thinking about what patent protections should be in GPLv3 [fsfe.org].
A good focus for the discussion, IMO.
However, skilled scripters are sure to.. (Score:2, Funny)
Like having Samy as your hero.
First post ! (Score:2, Interesting)
Good news (Score:3, Informative)
Lots and lots of implications (Score:5, Informative)
On the side of Mozilla, it means much faster, JIT JS engine, and since you know that Firefox's XUL depends heavily on JS to run, it may have big impact on the performance of Firefox as a whole and change the perception some have of Firefox as "bloated" and "slow".
This is just a guess though. Here's what's really fun.
Adobe is now working on its next generation "web platform", code named Apollo. Apollo's long term goals are to merge Flash, HTML/JS/CSS and PDF in one single "web platform", for internet applications.
Apollo is not a browser, you can think of it sort of like the
The first version of Apollo is not going to merge all three technologies into one, but it'll integrate them to work together. This means, you can have Apollo app that is based on AJAX with flash in it. Or Flash project with HTML in it. Or, I guess, Flash with PDF in it.. All sorts of combinations.
Adobe announced that they will NOT develop a browser on their own for Apollo, and that they are researching what to use.
I'll be honest, I thought it's apparent they'll pick Opera. Opera is faster than Firefox, it's portable to mobile platforms (and this is important to Adobe), and both Macromedia and Adobe have rich partnership with Opera already.
For example, Dreamweaver's WYSIWYG on Mac used to be Opera for a long time, and maybe it still is (on Windows, as far as I know, it's custom built).
And even now, the entire help system of Adobe uses built-in Opera browser. Even their "Bridge" image browser, is in fast running on Opera.
But now, as they contribute big chunks of Flash 9 (the script engine) to Mozilla, it means only one thing: Adobe has decided on a browser.
Apollo will feature a version of Gecko with Tamarin for a script engine.
Currently Adobe Reader (PDF) uses SpiderMonkey for its script engine, but when Tamarin is good enough to replace SpikerMonkey in Firefox, it'll be good enough to do it in Adobe Reader.
Hence, one step forward towards Adobe's vision of unified HTML/Flash/PDF platform. Interesting times.
Re:Lots and lots of implications (Score:5, Informative)
Parent
Re: (Score:3)
Interesting, didn't know that. It's strange that of all browsers on the market, Adobe will pick the least popular one, and one which needs a lot of work before it even runs on Windows (I know work is being done on it, but it's far from done).
Re: (Score:2)
Re: (Score:3)
Not to belittle their work, but they did "only" port it from one Unix-like system to another. Porting it to Windows will be rather more work, I suspect.
Re: (Score:2)
See here (it seems to be now defunct, but they did have a working release out at one point):
http://en.wikipedia.org/wiki/Swift_(web_browser)/ [wikipedia.org]
Is Adobe/Macromedia losing it? (Score:3, Interesting)
This has meant that their core products, such as Dreamweaver and the Flash development application, have been rapidly becoming crappier. D
If by Mozilla you mean WebKit (Score:2)
They actually announced they're using WebKit for Apollo.
http://labs.adobe.com/wiki/index.php/Apollo:develOpenLaszlo is the big winner from all of this! (Score:2)
The OpenLaszlo [openlaszlo.org] Legals Project [openlaszlo.org] will benefit immensely from this! OpenLaszlo is in a position to take excellent advantage of the now open source AMV2 JavaScript engine, for the benefit of users as well as developers. Not only will AVM2 make OpenLaszlo applications run faster on Firefox, but opening up the AVM2 virtual machine will make it possible to develop much more powerful debuggers and integrated development environments.
-Don
Re: (Score:2)
The JIT is currently x86-32 for Windows and MacOSX, plus PPC-32 for MacOSX. There is also a prototype ARM implementation. x86-32 for Linux is functional but has not yet been merged into the CVS tree. x86-64 (Windows + Mac + Linux) is under development.
Re: (Score:2)
I find this idea a bit scary. HTML, Flash, and PDF do two completely different things, and attempting to combine them is not going to end with a super-browser but with a monstrous train-wreck something like Acrobat Viewer, which inserts buttons in my excel toolbar without asking, takes forever to load and is generally a waste of space.
There's not a lot of point in integrating tools that do the same thing. The functions of Flash, PDF, and HTML are complementary. Not that it means any given toolset to work
Credible OSS response to .NET (on the desktop) (Score:4, Interesting)
Some early benchmarks [kotay.com] comparing SpiderMonkey, what would become Tamarin, and JScript.NET. are on my site [kotay.com]... interesting is that neither CLR, nor Tamarin provide a big boost when you use the features of JavaScript that make it more interesting than just plain old C. Wonder how much a real world boost this will be for the integration complexity? (i.e. is this another Netscape 6? Perhaps buckling down and fixing SpiderMonkey might serve better...)
--
graphically speaking [kotay.com]
Re: (Score:3, Interesting)
I understand
Re: (Score:2)
Re: (Score:2)
Don't rush to judgement on this without looking at the code. One of the design criteria for the JIT was to avoid this problem. Flash Player 9 (which uses this VM) can load and start executing jitted code very quickly. (Is "jitted" a real word?)
Re: (Score:2)
No it hasn't all they have done is to convert their VB programmers to VB.NET or C# programmers and they VC++ developers to C#. It's not like they converted java programmers or anything. The truth is that VB programmers were going to "upgrade" to anything MS put out no matter what it was.
About SVG (Score:3, Interesting)
There's no need for Adobe to make such a deal. Anyone who has tried using SVG on Firefox knows that the code renders so slowly as to be almost unusable, and lacks support for a tremendous number of SVG features. On top of that Adobe's own staff were always the big force behind SVG, now that Adobe has pulled out of SVG development its safe to say that SVG has no future outside of the tiny community of inkscape users.
Aside from the video codecs--which are no doubt entangled in far too many patent issues for Adobe to publish the standards--Flash is just as open as SVG, and it's a shame that open standards pundits refuse to stop pretending otherwise. It makes them sound just as stupid as the HD-DVD evangelists who pretend that HD-DVD is any less proprietary than Blu-Ray, and its hard to convince people that standards-based web development is important when this kind of garbage keeps getting spewed out.
SVG will eventually get yanked from Firefox not because of sleazy deals between Adobe and the Mozilla foundation, but due to the W3C not being behind SVG, SVG not having enough developers, the majority of SVG content on the web being experimental projects, and lack of software support for animated SVG content.
Re: (Score:3, Informative)
I can inline flash elements in my (x)html page?
I'm allowed to write my own viewer for it?
BTW... Konqueror has good support for non-animated/non-scripted SVG already. Soon, it will fix those flaws as well. Webkit has about the same level of support, and there's a committment to make SVG a first-class image format for pages. Opera's support is stellar, including the animation/scripting parts. And Firefox isn't too shabby either.
As far as I know, that's all 4
Re: (Score:2)
not so sure about SVG (Score:4, Informative)
I was really hoping that they'd go the other way--that with the purchase of Macromedia, they'd roll SVG support into the hugely popular Flash plug-in. I wish I were wrong, but my guess is that Adobe, just like MS or anyone else, would rather back a proprietary solution (that they own) than an open one.
* and, the funny thing is, the MSIE/Adobe combination--on Mac and Windows--was the best. You could print a page with lots of embedded SVG images, and it worked! Safari with Adobe's plugin, or Mozilla with the plugin or natively, would print each image on a separate page, if at all. (Though I haven't tested FF 2.0 yet.) But MSIE/Adobe printed just as you saw on screen.
Re: (Score:2)
Re: (Score:2)
This was never the reason why SVG was promising. There have been imagine manipulation libraries available to scripting languages for a long time. I remember using GD in Perl to create GIF images "out of thin air" as you put it. That was in 1996.
The strength of SVG is that it's vector-based. This allows developers to produce images that can be resized on-the-f
Re: (Score:2, Insightful)
Re: (Score:2)
The *worst* that could happen is the Mozilla/Firefox 'brand name' becomes tainted and people move away from it in droves. How this could feasibly happen I don't know, it isn't likely at all. Either way I couldn't give a monkeys butt about the brand, I care about the product. So I real
Re: (Score:2)
It's getting that, and a bunch of other cool stuff, in the ECMAScript 4 version that Tamarin will implement.
To see the current working proposals for ECMA for, go here: http://developer.mozilla.org/es4/ [mozilla.org]
Re: (Score:2)
* http://wiki.mozilla.org/Firefox3/Schedule [mozilla.org]
* http://wiki.mozilla.org/ReleaseRoadmap [mozilla.org]