For those who have put time or energy into making suggestions for the SVG_Plot program, an update (with pretty pictures!) is on the wiki: http://svn.boost.org/trac/boost/wiki/soc/2007/VisualizationOfContainers
Feedback / use cases welcome ;).
Hi, This question has probably already been answered when defining the subject, but I wasn't there. So if you don't mind: Why does this library export is graph only in SVG? I have nothing against SVG but (for example): - the picture on the wiki didn't show up correctly event after I installed a plugin, I needed to clic on it for them to display on a lank page (I use IE7, like a majority of users). Also, I took the plugin from adobe and it seems they don't plan to support it anymore after the end of the year. - If I want to put the svg in a latex document, I would need to convert it to ps/eps. It would be easier to output directly in ps format. - If I want to display the graph on the screen at runtime, it would be difficult. I think this library would be a lot more useful if it allowed multiple/user customized backend. Even if the only provided backend is svg. I read the code and actually, the output is completely bound to the drawing element. Since the drawing element are already a hierarchy of class, we would need to use double dispatch, either dynamically using a visitor pattern (for example) or statically by templatifying all the drawing element with a class containing the implementation of the output. I don't think the runtime speed would be noticeably be affected by this. Just my own opinion. I really think that developing all the framework for only outputting svg is a waste. Moreover since the change to the code would be minimal if done now. Use case: - with eps backend => latex document - with GDI or openGL backend => runtime plotting - raster backend => solid image (png, jpeg) Lastly, please excuse my poor English. I don't use English very often. -- Cédric Venet Student at Centrale Paris