You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Alan Deikman <Al...@znyx.com> on 2008/11/03 06:17:54 UTC

Re: Why is Batik so complex?

thomas.deweese@kodak.com wrote:
>
> > 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...
This answer was very helpful, but still Batik is more than a little 
intimidating.

Consider SVGGraphicsElement class.  It has 7 super-classes (not counting 
Object), 19 interfaces, and 16 "direct known" sub-classes.  To 
understand what is going on you have to understand Swing, AWT, DOM, DOM 
Events, Threads, CSS, ECMAScript, XPath, and several other packages. 
User documentation is almost non-existent, so if you try to read the 
code you quickly find out there are 81 packages that start with 
"org.apache.batik," all interlinked and many with naming conventions 
that must mean something, but there is no key anywhere.  For example, 
the substrings "GVT", "OM", "XBL", "Bridge", -- all unexplained.

I realize that many of the questions are obvious to those who grew up 
with the structure -- but starting from scratch is not for the faint of 
heart.

Mind you I'm not complaining.  I like a challenge like this, and I must 
say it all works incredibly well.   When I introduced Batik to my 
application, it took like 5 lines of code (not counting imports) to 
construct a JSVGCanvas object and display it successfully.  All I could 
think was wow.   However to do anything much more fancy drives you to 
obscure and difficult problems really fast.  (I'll be posting another 
question later tonight maybe.)   I suspect that Batik's wide deployment 
is going to be slowed by this.

Apropos of that;  Alexander Kolesnikov's book is very good, but it 
doesn't get past the basics.  A "Mastering Batik" book is needed that 
documents the internals.

Thanks in advance for all you guys that answer questions here.

-- 
Alan Deikman


RE: Why is Batik so complex?

Posted by "John C. Turnbull" <oz...@ozemail.com.au>.
I agree with you Alan.  The Batik web site has some explanatory pages but
there is a still a distinct lack of documentation that explains the various
subsystems from the perspective of someone who wishes to do advanced things
with Batik that may include modifying the source itself.  It can be a bit
baffling to locate the part of the code base that is relevant to the task
you have in mind.

 

But I love Batik.  It's probably the best Java class library I have come
across and I want to get the most out of it.

 

Cheers,

 

John

 

From: Alan Deikman [mailto:Alan.Deikman@znyx.com] 
Sent: Monday, 3 November 2008 16:18
To: batik-users@xmlgraphics.apache.org
Subject: Re: Why is Batik so complex?

 

thomas.deweese@kodak.com wrote: 


> 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... 

This answer was very helpful, but still Batik is more than a little
intimidating.

Consider SVGGraphicsElement class.  It has 7 super-classes (not counting
Object), 19 interfaces, and 16 "direct known" sub-classes.  To understand
what is going on you have to understand Swing, AWT, DOM, DOM Events,
Threads, CSS, ECMAScript, XPath, and several other packages. User
documentation is almost non-existent, so if you try to read the code you
quickly find out there are 81 packages that start with "org.apache.batik,"
all interlinked and many with naming conventions that must mean something,
but there is no key anywhere.  For example, the substrings "GVT", "OM",
"XBL", "Bridge", -- all unexplained.

I realize that many of the questions are obvious to those who grew up with
the structure -- but starting from scratch is not for the faint of heart.

Mind you I'm not complaining.  I like a challenge like this, and I must say
it all works incredibly well.   When I introduced Batik to my application,
it took like 5 lines of code (not counting imports) to construct a
JSVGCanvas object and display it successfully.  All I could think was wow.
However to do anything much more fancy drives you to obscure and difficult
problems really fast.  (I'll be posting another question later tonight
maybe.)   I suspect that Batik's wide deployment is going to be slowed by
this.

Apropos of that;  Alexander Kolesnikov's book is very good, but it doesn't
get past the basics.  A "Mastering Batik" book is needed that documents the
internals.

Thanks in advance for all you guys that answer questions here.



-- 
Alan Deikman