Thanks a lot....
-----Original Message-----
From: Thomas DeWeese [mailto:[EMAIL PROTECTED]
Sent: 22 August 2003 12:17
To: Batik Users
Subject: Re: Extending Batik to SVG1.2
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
