From: Tobias Reif Date: 2001-12-01T04:44:54+09:00 Subject: [ruby-talk:27117] Ruby & SVG (Curl might be first) There is discussion going on in the Curlbreaker list regarding SVG support in the Curl language. The post might include interesting aspects of implementing SVG in&for Ruby. Tobi -----Original Message----- From: James Joly [mailto:jjoly@curl.com] Sent: Thursday, November 29, 2001 3:46 PM To: curlbreaker-l@yahoogroups.com Subject: Re: [curlbreaker-l] Curl & SVG Hi Paul- We are currently investigating SVG support on several levels. It would be interesting to see what you and the rest of the CurlBreakers think about our plans in this space. One could feasibly write their own support for SVG using the current Curl API. Utilizing the XML parser, one could extract out the contents of an SVG file, determine the objects which need to be rendered, and make the appropriate calls to the 2D renderer, and display the results in the container of their choice. In addition, one could parse the file for events and animation and simulate these events and actions as well, although the current lack of a 2D retained mode would make this more difficult (you could always use the 3D system with the z set to 0, but I digress). This would be a cumbersome task, and some capabilities of SVG would undoubtably require significant hackery to replicate with our current 2D API. We have recognized that we need to do better in this space, primarily to leverage the abundance of development tools currently in the marketplace designed to output SVG code. At the same time, rather than pulling together the functionality described above in-house and creating an SVGViewer class or something of the sort, we would like to do it the "right" way. That would involve parsing an SVG file and rather than just drawing the contents, creating each object as a true Curl object, which lives in the Surge GUI system. In doing so, it would listen to option changes applied to the document, have the ability to be dynamically manipulated by your applet, etc. This would necessitate some underlying infrastructure to be created in the GUI system and multimedia engine. First, we would create a 2D retained mode. For the non-graphics programmers amongst us, the main difference between an immediate-mode and retained-mode graphics system is that the objects in a retained-mode system have "state", and can be altered individually by altering that state. In immediate-mode, things are drawn on the screen and their state is lost. If you want to alter something dynamically in immediate-mode, you need to dynamically alter parameters to the draw routine and redraw the entire container. Next, we would parse the SVG file and create 2D retained-mode Curl objects for display. Each SVG object would now be a Curl object and live in the GUI system, and would be named according to some convention similar to -. So if you had an SVG object called RedCircle that was colored red, with a radius of 1in, at x-y position (2in, 3in), saved in a file called redcircle.svg, we would parse this file to create a Curl object called SVG-RedCircle which is an instance of the (new) retained-mode class Circle with the correct properties and position. At this point, any scripting, events, or animation in the SVG file would be dropped on the floor however you may add these effects yourself by adding event handlers or changing the properties/position of SVG-RedCircle. The next level would be adding native support for the events and animation defined in the SVG spec, so that we don't drop those elements on the floor. The final step would be adding support for the scripting elements of SVG. Most SVG code-generators default to using ECMAScript for their scripting, however the SVG spec allows for alternatives. While we might not ever parse ECMAScript due to the differences between their DOM and Curl, we could possibly have Curl be an alternative scripting language for SVG. This level of support is the furthest off; until then, interactive scripting elements will need to be added by hand. For our next release, we are hoping to add the first step (retained-mode), and hopefully the second step, actually parsing SVG files so that we can display SVG content. However, as I mentioned this will not allow for standard SVG animation or events. Would this still be of value? Do we need to get to the third phase to have any real utility? Or are we useless until we reach all four phases? Any feedback would be greatly appreciated, and you can send it directly to me if you don't feel that the entire list would care :) Hope this answers your question! Sincerely, James Joly Curl Corporation Product Manager, Surge Software Platform jjoly@curl.com 617-761-8027 -- Tobias Reif http://www.pinkjuice.com/myDigitalProfile.xhtml go_to('www.ruby-lang.org').get(ruby).play.create.have_fun http://www.pinkjuice.com/ruby/