Heya,
I actually considered that same thing when I was looking into this. What I concluded is the following:
- SVG is targeted at building images from the bottom up (simple shapes, text, etc) for the purpose of simple, yet pretty pictures and user interfaces (even animations!)
- SVG is targeted at wireless (and related) devices where the bandwidth is limited
- SVG does not include handling of files (read/write/formats/etc)
- SVG does not include manipulation of existing image files, for example, you cannot take a JPEG of a monkey and draw a circle on his face... you can however create an image of a monkey using vectors, but it'd be really really hard to make it look remotely realistic.
- My project is targeting manipulation of existing images, and while SVG does have a good framework for their purposes, their model is pretty obfuscated (in that its overly complex)
- SVG doesn't seem to support the chaining model, but rather only allows you to draw to a single palette.
Further more, my envisioning allows the user to build complexity in a hierarchical form; even extend by overloading one function, and it all seems to fit nicely with the ANT framework. See where I'm coming from with this? :)
~~K
[EMAIL PROTECTED] wrote:
Guys,
how does this compare with SVG - there seems to be a large crossover here.... -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers
Christoph Wilhelms <[EMAIL PROTECTED] To: 'Ant Developers List' <[EMAIL PROTECTED]> press.com> cc: Subject: RE: ImageManip 05/23/02 07:49 PM Please respond to "Ant Developers List"
Erik, Kevin!
This is quite cool. Thanks for sharing.
Since this likely would not make it directly into Ant's
codebase, are you
planning on posting it on Sourceforge and open-sourcing it so that its
available via CVS and can evolve with other developers assistance?
I'd +1 to let this stuff go into our distribution, because:
1st: JAI (Java Advanced Imaging) is a SUN API!
2nd: It makes sense to use in standard builds. For example to generate version numbers in splash-screens and about-graphics. I think many GUI developers will find it useful...
3rd: We have so much stuff in our optional tasks, that should be transfered to the vendors of the related software... The JAI stuff is much nearer to the Java Core!
IMHO it minimumly should become an optional task!
Greetings, Chris
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
