There are a lot of people using SVG, and SVG is the only "real" vector graphics standard that exist*, almost all browsers except one has SVG support in one form or another (Safari, Firefox, Chrome, Opera and so on), Microsoft will off course do everything they can to avoid having to support SVG and it was a bit nasty of Adobe to stop supporting the SVG plugin though.
But if you take a look at the number of people complaining about the lack of SVG support in IE I think you will find SVG to be pretty well alive and kicking at the moment. I know a lot of people that refuse to install Silverlight just for the simple reason that they are so tired of getting the "Would you like to install silverlight" popping up when ever you get close to any of Microsofts websites. Flash is a pretty different beast compared to SVG, they have the advantage that flash is installed on almost all computers that exist but flash does not do the same thing as SVG and the other way around, depending on the type of application you might want to use flash instead of SVG or the other way around. Javascript can do a lot of neat stuff but getting it to work on all browsers is a pain in the lower regions. * yes there is stuff like CGM but that is pretty dead today, and WMF/EMF is not a standard with any one but MS. ----- Original Message ----- From: John C. Turnbull To: batik-users@xmlgraphics.apache.org Sent: Monday, October 13, 2008 2:22 PM Subject: RE: Why is Batik so complex? Hi Thomas, Thanks for the comprehensive and helpful response. Yes, it does go some way to explaining the need for such complexity. It seems to me that perhaps SVG is underutilized in that there is so much functionality available and yet I haven't seen very many complex applications that use all or most of it. Maybe SVG is being abandoned as developers move to competing technologies like Silverlight, Flash and pure JavaScript solutions. I do hope not and I also hope that Batik will continue to be developed and not just maintained. I would love to see some more advanced SMIL support for example. Cheers, -JCT From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, 13 October 2008 23:08 To: batik-users@xmlgraphics.apache.org Cc: batik-users@xmlgraphics.apache.org Subject: Re: Why is Batik so complex? Hi John, "John C. Turnbull" <[EMAIL PROTECTED]> wrote on 10/13/2008 07:05:37 AM: > I really admire Batik. I think it's a fantastic library and a > really great example of what can be achieved with Java in the hands > of the right people. > > But I do wonder one thing... why is it so very complex? I mean, the > code to do rendering is very comprehensive and yet I would have > thought that traversing a tree and rendering each basic graphical > element and applying a few affine transforms here and there would be > a fairly simple thing to do. Is it because that achieving the 'S' > for "Scalable" is not as simple as just applying a scaling transform > to the basic rendering code? Are there hidden complexities when it > comes to writing code to produce scalable graphics? Or is there > another reason? There are quite a number of reasons. This first problem is that we have to implement a specification. So we don't always get to do things in the most straight forward way for Java because we need to match the SVG specification. The actual support for simple bezier shapes is quite simple but of course SVG goes _way_ beyond that. First you need to support DOM Level2 with events (including things like mouse over/exit of complex shapes), then you have all of CSS 2 (perhaps one of the trickiest specs to implement correctly... take the HTML browsers which still diverge widely). This of course brings up Text where SVG goes well beyond normal text in a box to have text on a path with manual position adjustments, text length, kerning and a bazillion other features, Batik also supports a version of text flow in complex regions, all with BiDi support. It's also important to remember text selection and the various text query API's as well. Then you need to consider SVG Filters and the image element, which moves you into the relm of raster graphics where you can apply filters (including 3D lighting) as well as adjust the resolution that filters are rendered at. Also there are patterns and complex gradient fills for all shapes text etc as well as masking and clipping (by any graphics elements). Don't forget that an image can reference another SVG image (which has to have an independent scripting environment etc). Then features like markers/symbols and use make your graphics tree quite a bit more interesting as they have significant implications about how the rendering tree is structured. Top with a nice drizzle of SMIL animation over the top, and you are presented with an extremely challenging specification to implement. Then we do some things like supporting asynchronous rendering to avoid locking the UI for potentially long periods of time which doesn't make anything easier. > Please don't get me wrong - I am sure it *needs* to be this complex > - I just want to understand why. Does this start to give you a feel for why Batik is a bit more complex than a really simple graphics tree...
