[EMAIL PROTECTED] 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
