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 ------- Additional Comments From [EMAIL PROTECTED] 2006-05-16 17:24 ------- I didn't provide much motivation when I posted this RFE, so here is some of that, along with some thoughts on Thomas' comments. It's possible that GNode would be large and difficult, but I think the benefits would justify the effort. SVG has the potential to be the lingua franca (or RTF, if you prefer) of graphics applications, but at present it addresses only XML to raster conversions (i.e. gif, tiff, jpg). The goal of this proposal is to promote the potential of SVG to address conversion from any app to any other app. A way to do this is to give developers a leg up on importing SVG files into their apps. This enhancement would be useful for any application that deals with graphics. My goal in the attached code is not to build a 'custom gvt tree', but to build a completely distinct object graph for an application that has nothing to do with svg. (The demo code may look a lot like gvt, but it doesn't have to be.) I think it could potentially have a large impact on the disemination of svg if it were easy for developers to import svg documents and convert them to their own application data structures. Subclassing gvt classes is not sufficient and has the negetive effect of making gvt a defacto public interface. Since it is not designed for that, apps that used it that way would likely break in complicated ways in subsequent releases of batik, which would make subclassing gvt a risk not worth taking. The point of the GNode interface is to avoid pushing gvt out as a public interface. GNode would be the public interface and it would be designed for public consumption. I'm not sure I get the possbility where 'Bridge should really handle case 'Z' even though it can't occur with GVT. If we're talking about implementing the SVG spec it seems unlikely that there could be a situation where it was possible to write legal svg that wasn't handled by gvt. In addition, I think the GNode interface should be made as simple as possible, leaving most of the implementation details in subclasses. The more work required of the subclass, the less chance there will be of conflicts. -- 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]
