DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39451>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39451 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement ------- Additional Comments From [EMAIL PROTECTED] 2006-04-30 23:34 ------- So I had some time to look into this yesterday. I didn't get through everything but I think I looked at enough to get the gist of things. In short you tool the basic interface of the GraphicsNode and turned them into interfaces. Then the Bridges interact with these interfaces. While I'm not dead set against this I would say that this is not particularly exciting to me. The whole 'gnode' interface is still rather large and proper implementation of it would be extremely difficult (for example all of text layout is done in the GVT tree yet this must be done properly for complex fills to be calculated properly). So there is a non-trivial interaction between the Bridge classes and the GVT implementation (this only get's worse when you consider the SVG DOM). To be honest I'm not interested in trying to debug across libraries as this would require (it works for GVT because of 'X' but fails for BLAH, but the Bridge should really handle case 'Z' even though it can't occur with the GVT...) Also this would really push the GVT out as a public 'interface' meaning that any change to the Bridge<->GVT tree would break 'external' software - or we would have to add new subinterfaces of interfaces that the bridge would check for (Gahhh!). Finally, I think that in _most_ cases people could, for less work, simply subclass our existing GVT classes, and subclass the Bridges (replacing the 'createGraphicsNode' method) to build a 'custom' GVT tree (all the above steps are required in the 'gnode' case anyways). The only drawback would be for someone who already had a graphics tree structure that was 'by chance' essentially identical in structure to the GVT tree. I encourage other people to look at it and come to separate opinions, I'm not dead set against it but I think it would add significantly to the effort needed to develop Batik and I don't think there would be significant benefit to Batik. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
