xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikael" <mikael-arons...@telia.com>
Subject Re: Why is Batik so complex?
Date Mon, 13 Oct 2008 13:50:53 GMT
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.






  From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com] 
  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" <ozemale@ozemail.com.au> 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... 

View raw message