Why Adobe chose FXG over SVG
I am currently on a speaking and press tour in Asia talking about some of the new stuff we are doing in Flex 4. One of the things that people seem to be really excited about is FXG and Thermo, and the improved designer / developer workflow that they promise. However, I have received a couple of questions about why we didnt just choose to use SVG instead of creating a new format.
This is actually addressed in the specification:
When initial work on an XML-based graphics interchange format began, the natural first thought was to use SVG. However, there are key differences between SVG and Flash Player’s graphics capabilities. These include core differences in SVG and Flash’s rendering model with regards to filters, transforms and text. Additionally, the interchange format needed to be able to support future Flash Player features, which would not necessarily map to SVG features. As such, the decision was made to go with a new interchange format, FXG, instead of having a non-standard implementation of SVG. FXG does borrow from SVG whenever possible.
Essentially, SVG didnt map well to the Flash world.
Our initial work around the format actually focused on SVG and Mark Anders has just posted a blog post describing in detail some of the issues that we ran into that led us to finally decide to pursue FXG over SVG.
You can read his post here.
As long as it’s easy to convert from one to the other, I think it’s all good.
Dusty
30 Sep 08 at 10:28 pm
Mike,
any idea about next speaking tour in Thailand/Southeast Asia?
isriya
30 Sep 08 at 11:36 pm
I work with Adobe products for a living, and am probably the prime audience for Thermo — I spend about 50% of my time developing prototypes in Flex. So, I find this discussion interesting, but I’m not as willing to give it a free pass as the previous commenters.
I guess I have to ask, since Adobe was involved in the creation of SVG and participates in its maintenance, why cant’ these limitation be addressed there?
Secondly, the SVG spec does have extensibility support with a mind towards including viable extensions in future specs: http://wiki.svg.org/SVG_Extensions
I find Mark Ander’s explanation to be fairly unconvincing. It kind of reads like someone who wants to make a new spec. For instance, he says “Flex doesn’t provide a DOM of the MXML document so there’s no way to look up an object with a specific ID”. Maybe I’m crazy, but I’m pretty sure there are multiple ways to lookup an object by ID in Flex(MyMXML.myPropery, MyMXML["myProperty"]), so I guess I just don’t get it. On most of his other points, I believe SVG extensions could likely address the issue.
I find the whole topic of Adobe and open formats rather frustrating.
Dan Martin
1 Oct 08 at 12:11 am
It’s too bad that we could not use SVG for Flash graphics and searchable content, but I find hundred times worst not to have a standard way to use FXG (or SVG) from the HTML page to use it at runtime in Flash.
We really need to execute FXG from the HTML page, it would allow to create full readable content for “Search Engines” and text readers. And it would help to silence a little those who tell you all the day long that Javascript is much easy to integrate and deploy than Flash for UI Design. It could be our better argument against nowadays Javascript conquerors (the best would be to have Actionscript evaluation … but we couldn’t for the moment).
I’ve started to develop something that read custom XML block from HTML with ExternalInterface but it is not HTML valid if I remember. The only standard way to read FXG from HTML is to write XML content inside the OBJECT tag. But its content couldn’t be read from Javascript nor ExternalInterface so.
Could it be possible to change the Flash Player to initialize it with FXG tags coming from the tag ? Would it be in any Adobe plan to parse FXG at runtime and to do so ?
Tek
1 Oct 08 at 3:35 am
I totally agree with Dan Martin, it’s like every Adobe developer group is creating their own file formats for interchange between application A and B, B and A, C and A, C and B etc. At the end we’ll have 10 apps and 100 file formats. Somebody totally misunderstood the approach of STANDARDS!
And if FXG is so close to SVG, why don’t you just improve SVG? Because you’re loosing the USP? “You” are looking at SVG like if it’s a fixed non-changeable standard…
And what’s the difference between a “non-standard implementation of SVG” and a not standardized FXG?
Frank Spangenberg
1 Oct 08 at 5:06 am
I’m not too worried about Adobe not supporting SVG. I’m sure there will be tools or some third-party API that might help convert such to FXG. People have been doing this for Silverlight. I guess I’m more interested on what SVG can do that FXG cannot.
todd
1 Oct 08 at 6:42 am
[...] Why Adobe chose FXG over SVG (from Mike Chambers) [...]
Flex Monkey Patches » Blog Archive » Rubbernecker’s Review - Week 15
7 Oct 08 at 7:31 am
[...] Blog Posts: Mike Chamber Blog Post - Why Adobe Chose FXG Over SVG [...]
Adobe Replaces SVG with FXG | Enetlive.net- Rich Internet Applications Blog
9 Oct 08 at 7:47 pm