Shan Kajendran wrote:
Dear Mr DeWeese
Thanks for your kind and quick reply.
Actually we are planning to use Batik in our project. As I am
researching (Feasibility) on different SVG implementation I am wondering
how these implementations going to cope with latest SVG SPEC (SVG 1.2
and SVGP).
As an example if I want to implement SVGP with the help or on top of the
Batik what root I have to follow.
There are two routes you could go. One is to try and build one
massive rendering tree that selectively displays each page (where
most of the work would be done in the Batik Bridge and a few new
GraphicsNode types in the GVT). The other would be to 'preprocess'
the SVG Document to get a fairly standard SVG document for each page.
What would make the decision for me would be why the Working Group
decides for how CSS is to be handled. I think they are headed towards
the each page is styled seperately but the spec really doesn't say yet.
Also if you wanted to do SVGP interactively (say in the JSVG canvas)
then you might want to lean towards the massive rendering tree (more overhead
to start with but better interactively), although you could also lazily build
the page rendering trees as well - which would allow for better memory management.
Thanks again
Shan
-----Original Message-----
From: Thomas DeWeese [mailto:[EMAIL PROTECTED]
Sent: 19 August 2003 15:03
To: Batik Users
Subject: Re: Extending Batik to SVG1.2
Shan Kajendran wrote:
Hi Genies
I know that Batik is supporting SVG 1.1 specification. When W3C
enhance the SVG SPEC features (example SVG1.2), How Batik is going to
support these enhancements. I can't find any document in the Batik
home page about the enhancements to SVG SPEC.
Any idea?
Hi Shan,
There is already some work in this area in the
Batik extensions (batik.extension.svg package). There are complete
working implementations of multiImage, and solidColor. There is also a
limited implementation of flowText (mostly it just supports rects rather
than arbitrary regions). All this work has taken place in the Batik
Namespace to make it clear that these are not part of SVG yet.
These sorts of extensions are handled very nicely by the Batik
extensibility architecture. I haven't looked at how easy (or difficult)
it might be to add support for things like Rcc which may require some
modification of the Batik architecture.
As SVG 1.2 becomes more real some effort should be focused on how
to move these from the Batik Namespace into the SVG namespace for
documents that reference SVG 1.2 (via the version attribute presumably).
This shouldn't be too hard given the bridge architecture in place.
What sort of things are you looking at/interested in?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
