On Thu, 11 May 2006, Bryce Harrington wrote:
Wow, that sounds interesting - do you have an example you could show (just out of curiousity.)
http://uva.hobby-site.com/~skinkie/screenshot-kka-1.png http://uva.hobby-site.com/~skinkie/screenshot-kka-2.png
This is the webinterface. It is Dutch, so don't worry if you don't understand the text.
My first project is to put all dependencies of sp_export_png_file into a renderserver that allows me to have an application sleeping instead of startingup foreach svg file I want to convert. Eventually getting the Inkscape SVG renderer into Ambulant (a SMIL player), so I don't need intermediate files, then again, cache can be quite handy.
Could you provide some additional details about these plans? Possibly others could review your approach and suggest alternatives.
The abstracted application: -Frontend (Apache/PHP) -Backend (Apache/PHP calling Inkscape with a XML+XSL=SVG document) -Scheduler to copy over the rendered files to the player
Player: -SMIL Subset that calls xview to display PNG images.
Issues: because of the poor SVG support in browsers I'm rendering each little change. Some cache is in place, but from an Inkscape perspective there could be a lot of more cache done. For example compositing part-solutions on top of each other.
Because I starting Inkscape everytime I'm doing a change (without gui) still isn't a thing you want to do embedded. Prelinking is in place.
So my own alternative would be: 1) Get a daemon that converts svg documents in one directory to a output directory. (Save startup time)
2) Get a SMIL player support Inkscape render functions but make sure it doesn't choke on slow rendering.
3) Whichful thinking: integrate SMIL and SVG in order to animate SVG based on SMIL events.
Stefan