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: [email protected] Cc: [email protected] 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...
