The main ASF Bugzilla instance will be unavailable for 4 hours starting 19.00 UTC 2016-10-29 for an upgrade to 5.0.3

Bug 23443

Summary: reference vs referencing element bug
Product: Batik - Now in Jira Reporter: Tonny <tonny>
Component: GVTAssignee: Batik Developer's Mailing list <batik-dev>
Status: NEW ---    
Severity: normal CC: age, batik.foodie, rjudson
Priority: P3    
Version: 1.5   
Target Milestone: ---   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 46914, 46919    

Description Tonny 2003-09-26 17:44:25 UTC
update on reference element doesn't reflected by the referencing element
for example I have rect element with fill attr point to gradientElement, if I
update the gradient element
property/child the update doesn't reflected by GVT.

work around for batik user (not developer)
when update the reference element, update also the referencing element by
setting/update any attribute

according to the batik-users mailing list
"This is a known limitation.  This is _much_ harder than you think
since gradients can reference other gradients etc... In particular it
is difficult to avoid memory leaks (this was supported early on but
was removed because the memory leaks were so bad)."
Comment 1 Thomas Deweese 2005-03-22 12:16:36 UTC
Reassigning all open bugs to the development list.
Sorry for the mass mailing.
Comment 2 Cameron McCormack 2007-08-26 21:32:58 UTC
*** Bug 42968 has been marked as a duplicate of this bug. ***
Comment 3 Cameron McCormack 2007-09-24 19:23:34 UTC
*** Bug 40163 has been marked as a duplicate of this bug. ***
Comment 4 Age Bosma 2009-02-03 00:41:24 UTC
I ran into this issue now as well. What appears to be, at least a partial, additional workaround is to place the element(s) to be references in a 'g' element. I only used it for the stroke but that is accepted somehow. Note potential NPE's when animating the referenced elements though (bug #46618).

What I don't understand is why the status page doesn't mention any of these shortcommings.