xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jonathan wood <jonathanshaww...@gmail.com>
Subject continued contribution discussion ... Thomas' To Do List
Date Wed, 10 Feb 2010 14:21:43 GMT
Hello Dev,

 I've clipped Thomas' todo list and pasted below for reference.  I'll just
refer to the numbers.

  My paying gig would benefit from all of the below, so I'm ordering based
on personal preference.  If one task is more useful to a larger audience,
I'm cool with refocusing.

Task 4 is one I'd like to tackle first.  I do have some concerns though.
Would we continue to support the shadowtree api?  I would assume so since
much code probably relies on the voodoo-traversal to the real parent.  Since
the computational overhead of supporting the spec and the shadowtree may be
significant, should the shadowtree api be refactored to mimic the old
behavior while really traversing elementinstance's?  Are there any test
cases for the shadowtree to test for regression?

Task 3 probably the most interesting to me.  Thomas, do you happen to know
where the gradient example might have landed if not on trunk.  I can dig if
you are not sure.

1 & 2 look pretty straightforward.


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.

View raw message