xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jonathan wood <jonathanshaww...@gmail.com>
Subject Re: contribution advice?
Date Fri, 08 Jan 2010 14:31:20 GMT
This is exactly what I was looking for.  Thanks for taking the time to put
this together!


On Fri, Jan 8, 2010 at 9:15 AM, <thomas.deweese@kodak.com> wrote:

> Hi Jonathan,
>
> jonathan wood <jonathanshawwood@gmail.com> wrote on 12/31/2009 05:28:15
> PM:
>
>
> >     Perhaps someone familiar with the current state of batik's bug
>
> > list (Helder???) could point me toward some validated, higher priority
> > bugs so that I might attempt to resolve?
>
>    I'm not sure there are a lot of high priority bugs.  I'll list a few
> things that have been on my TODO list (for a few years now ;).
>
> 1) Pipe all element "lookups" through an object associated with the
>    BridgeContext.  This would be to serve two purposes.  First it
>    would more easily enable people to 'replace' Batik's lookup/fetch
>    logic (replacing/augmenting ParsedURL only goes so far).  Second
>    if paired with 'unlookup' calls it would enable Batik to detect
>    complex reference loops in content (an element that references a
>    pattern that uses the element).
>
> 2) Make everything use ParsedURL for references.  Currently there
>    are still a few places where we don't use ParsedURL (I think
>    mostly in CSS) this mostly means that you can't use base64
>    encoded URLS in these places.
>
> 3) Add dynamic updates for referenced content. Currently in many
>    cases if a referenced element changes Batik doesn't notice.  I
>    think this is true for patterns, filters, masks, etc.  I did an
>    example of dependency tracking for gradients (which may not have
>    landed on trunk) at some point it would be nice if this was extended
>    to other areas.
>
> 4) Implement ElementInstance for Use elements.  Currently we create a
>    shadow tree to support the use element, which is not conformant to
>    the SVG specification.  It would be better if we created
> ElementInstances
>    that could carry the CSS cascade information and then use a reference
>    to the actual element for DOM attributes.  This would require updating
>    all of the Bridges to know/handle the ElementInstance case but I think
>    the changes (while widespread) could be fairly simple.
>
>    These are just suggestions, let me know if these are the sorts of
> suggestions you are looking for, or if your interested lie in other areas.
>
> >   My Apache ICLA has been submitted and I do understand that I will
> > be limited to submitting patches that may or may not be applied by
> > an individual with commit access.
> >
> >
> >   Thanks,
> >
> >     jonathan
>

Mime
View raw message