Well if you are going to compare basic rendering primitives why did you skip path data? In anything but the simplest graphics essentially everything is path data in SVG the overhead per cubic bezier (the primary data type) is around 18-24 bytes before compression flash must be around 19 bytes. The SVG version will generally compress very well because it is made up of [-0-9.] 14 chars.
Since for most content the path data dominates in many _real_world_ cases the SVGZ version is smaller. What you say about parsing is true, however now days in most _real_world_ cases I/O is the limiting factor not parsing time. I won't say that Flash doesn't have it's advantages but in at least this case it isn't as clear cut as people try to make it out to be.
Isn't this a bit like saying: Of course we are lying... so?
By definition a trojan horse is pretending to be something it really is not. Since no one has been able to independently verify the compliance claims it's hard to know how hurtful the trojan horse is.
As I've said elsewhere I'm willing to give them the benefit of the doubt for now but I am very wary. It is unfortunately far to easy for companies to subtly corrupt standards, if there is a desire to do so - this does nothing but hurt consumers in order to benefit the corruptor.
I won't try to defend Robin & Antoine however you really should mention John Dowdel on the Macromedia side who has been attacking SVG for years.
I do believe that history is important here. I am willing to at least consider that Macromedia has changed it's real position on SVG. Given there history however this topic bears close scrutiny in an attempt to avoid the browser wars 2004.
In the Flash authoring tool you can use ActionScript to parse XML data from external sources and display it in the swf where the user can then be allowed to manipulated it at his heart's content.
getURL and parseXML have been in the SVG U/A's for a while. Versions of these will be part of the standard in SVG 1.2. You can do exactly what you describe in SVG.
On the topic of video as I understand it SVG 1.2 will include support for video and audio elements, along with a number of other cool features from SMIL (transitions etc).
I assume you mean 'xforms' when you say we already have an open standard? The issue with xforms is that it doesn't do anything to allow authors to control the appearence of the form elements.
In HTML this it generally fine but for many SVG use cases it is really important that people be able to control the forms elements in ways that xforms just doesn't allow.
Finally I don't think that this technology should be considered an alternative to xforms but another way of implementing xforms. Imagine if it was easy for a 3rd party to add xforms support to xhtml - lots of people would do it - right now you need to provide the entire xhtml renderer if you want to do xforms.
As far as the 1024 character limit is concerned SVG UA's go _way_ beyond this - it is quite common to have fairly large images (couple hundred K), FYI with base64 encoding it's 3 bytes per 4 chars. You get almost all of this loss back if you gzip the SVG file (which UA's are required to support).
Actually SVG does support embedding fonts. In fact it includes it's own font format where the various glyphs are described using what else? SVG. These are "real fonts" still so text just references the embedded SVG font and text stays text. A user agent is free to support alternate font formats but the only format UA's are required to support is SVG.
As for SVG + forms there has actually been a fair amount of work in this area. The current thinking is to create an analog of XUL using SVG for the rendering. There is something already implemented in the Adobe SVG beta called RCC that allows one to describe how your custom XML markup should be rendered and how it should behave.
I'm not entirely sure what you mean by embedded files but I suspect you are refering to embedded Raster images (like JPEG's) if so these are also already part of SVG. All SVG UA are required to support the 'data' protocol for URL's which allows images to be encoded directly in the href.
I don't know why having a single standard that can handle a wide range of use cases is a problem. The standard already distinguishes between 'static' SVG and 'dynamic' SVG so you don't have to have scripting to have SVG be useful.
>> Unfortunately for your argument, using a monopoly to gain a monopoly in a related market is illegal.
>You missed my point entirely. They should have argued that it was not two different markets (OS and Browser) but only one market (User Interface).
Well you missed the point of the article completely.:)
If Microsoft was able to admit the possibility that they were wrong they wouldn't be where they
are now.
If Microsoft didn't feel that all mass market application developers are there competition they wouldn't be where they are now.
If Microsoft could restrain it's self from attacking perceived rivals with all available means (legal or not) they wouldn't be where they are now.
The point of the article is that the only reason Microsoft might be broken up is because of Microsoft. Microsoft had dozens of ways to 'get out' of the lawsuit, but because it's Microsoft they couldn't take any of those options. What the article was trying to point out was that the reasons they couldn't take those options were the same or similar reasons to why Microsoft is successful and disliked.
In some sense Microsoft is caught in a Catch 22, without being as incredibly aggressive they couldn't have become a monopoly, but once they became a monopoly they couldn't modify their behavior as required by law since that aggressiveness had been so strongly reinforced by the Open Market.
Slashdot Mirror
Well if you are going to compare basic rendering primitives why did you skip path data? In anything but the simplest graphics essentially everything is path data in SVG the overhead per cubic bezier (the primary data type) is around 18-24 bytes before compression flash must be around 19 bytes. The SVG version will generally compress very well because it is made up of [-0-9 .] 14 chars.
Since for most content the path data dominates in many _real_world_ cases the SVGZ version is smaller. What you say about parsing is true, however now days in most _real_world_ cases I/O is the limiting factor not parsing time. I won't say that Flash doesn't have it's advantages but in at least this case it isn't as clear cut as people try to make it out to be.
Isn't this a bit like saying: Of course we are lying... so?
By definition a trojan horse is pretending to be something it really is not. Since no one has been able to independently verify the compliance claims it's hard to know how hurtful the trojan horse is.
As I've said elsewhere I'm willing to give them the benefit of the doubt for now but I am very wary. It is unfortunately far to easy for companies to subtly corrupt standards, if there is a desire to do so - this does nothing but hurt
consumers in order to benefit the corruptor.
Check out Batik:
http://xml.apache.org/batik
It is one of the more complete SVG implementations.
It's biggest failing is no SMIL animation, it has
excellent script support.
I won't try to defend Robin & Antoine however you really should mention John Dowdel on the Macromedia side who has been attacking SVG for years.
I do believe that history is important here. I am willing to at least consider that Macromedia has changed it's real position on SVG. Given there history however this topic bears close scrutiny in an attempt to avoid the browser wars 2004.
In the Flash authoring tool you can use ActionScript to parse XML data from external sources and display it in the swf where the user can then be allowed to manipulated it at his heart's content.
getURL and parseXML have been in the SVG U/A's for a while. Versions of these will be part of the standard in SVG 1.2. You can do exactly what you describe in SVG.
On the topic of video as I understand it SVG 1.2 will include support for video and audio elements, along with a number of other cool features from SMIL (transitions etc).
I assume you mean 'xforms' when you say we already have an open standard? The issue with xforms is that it doesn't do anything to allow authors to control the appearence of the form elements.
In HTML this it generally fine but for many SVG use cases it is really important that people be able to control the forms elements in ways that xforms just doesn't allow.
Finally I don't think that this technology should be considered an alternative to xforms but another way of implementing xforms. Imagine if it was easy for a 3rd party to add xforms support to xhtml - lots of people would do it - right now you need to provide the entire xhtml renderer if you want to do xforms.
As far as the 1024 character limit is concerned SVG UA's go _way_ beyond this - it is quite common to have fairly large images (couple hundred K), FYI with base64 encoding it's 3 bytes per 4 chars. You get almost all of this loss back if you gzip the SVG file (which UA's are required to support).
Actually SVG does support embedding fonts. In fact it includes it's own font format where the various glyphs are described using what else? SVG. These are "real fonts" still so text just references the embedded SVG font and text stays text. A user agent is free to support alternate font formats but the only format UA's are required to support is SVG.
As for SVG + forms there has actually been a fair amount of work in this area. The current thinking is to create an analog of XUL using SVG for the rendering. There is something already implemented in the Adobe SVG beta called RCC that allows one to describe how your custom XML markup should be rendered and how it should behave.
I'm not entirely sure what you mean by embedded files but I suspect you are refering to embedded Raster images (like JPEG's) if so these are also already part of SVG. All SVG UA are required to support the 'data' protocol for URL's which allows images to be encoded directly in the href.
I don't know why having a single standard that can handle a wide range of use cases is a problem. The standard already distinguishes between 'static' SVG and 'dynamic' SVG so you don't have to have scripting to have SVG be useful.
It really is a very cool standard!
Sure you can, using JavaScript:
// Assuming LTR text
var t = document.getElementById("myText");
var len = t.getComputedTextLength();
-- or --
var bbox = t.bbox;
var len = bbox.width;
>You missed my point entirely. They should have argued that it was not two different markets (OS and Browser) but only one market (User Interface).
Well you missed the point of the article completely. :)
If Microsoft was able to admit the possibility that they were wrong they wouldn't be where they are now.
If Microsoft didn't feel that all mass market application developers are there competition they wouldn't be where they are now.
If Microsoft could restrain it's self from attacking perceived rivals with all available means (legal or not) they wouldn't be where they are now.
The point of the article is that the only reason Microsoft might be broken up is because of Microsoft. Microsoft had dozens of ways to 'get out' of the lawsuit, but because it's Microsoft they couldn't take any of those options. What the article was trying to point out was that the reasons they couldn't take those options were the same or similar reasons to why Microsoft is successful and disliked.
In some sense Microsoft is caught in a Catch 22, without being as incredibly aggressive they couldn't have become a monopoly, but once they became a monopoly they couldn't modify their behavior as required by law since that aggressiveness had been so strongly reinforced by the Open Market.