Hello everybody, I am sorry to send this a second time. Someone hinted out that I would not reach everybody on the mailing list through the Google Groups address. I should have looked a bit more thoroughly. The Google Summer of Code 2013 is over! My project to port the charts [0] library to use diagrams [1] as an alternative to cairo [2] was a full success. The project goal [3,4] was to remove cairo as a dependency and replace it with a open backend API so different technologies can be used to render charts. This was mainly necessary, because cairo is hard to install on platforms like windows or mac. Aside of that it also makes charts more flexible and opens the doors for renderings charts in different contexts. We were successful. The cairo rendering code was completely removed from the chart library and replaced by a drawing API [5] that is backend independent. The cairo rendering backend, of course, is still there and now provided as the separate package Chart-cairo [6]. In addition we implemented a second backend based on the diagrams library. It is provided in Chart-diagrams [7]. To give some more detail on the development: The backend API is now based on a deep embedding of all drawing commands in the ChartBackend monad. The sequence of drawings commands resulting from this is then interpreted by a implementing backend. We use the operational package [9] to implement the deep embedding. Implementing the cairo backend was straightforward, because the backend API was developed with the cairo API in mind. Implementing the diagrams backend was some more work. Drawing on its own is not a problem but calculating text metrics is, because it requires to access the systems font rendering capabilities most of the time. Diagrams does not offer this access for several reasons (missing backend support, unclear how API would look, etc.). You can look at the diagrams-discuss mailing list for further information on this topic. We used the SVGFonts [10] library to render fonts, because of these issues. It is independent of the used backend and uses the SVGFonts format to render fonts and calculate their metrics. Like this fonts can be preloaded and metrics can be calculated on the fly. The only downside of this approach is that its performance is not to good, because we render each glyph as a path and because the math done in diagrams is not to fast either. At least when rendering to SVG files we could improve the performance by embedding fonts into the produced SVG and by that saving to insert each glyph as a path. The API to access this is not yet on hackage but the new version will be released soon. You can look at the GitHub repository [11] if you want to access it. Along with this development I also had the change to tackle some bugs and improve the diagrams-svg [12] and SVGFonts [10] code. Everybody who is interested in the details of the development process and see every bit of what was done can check the chart or diagrams mailing list. Both contain the progress reports of the project [8]. So have a look at charts [0] and see what it can do. We also have a nice little tutorial on how to use the new backends [13]. Greets Jan [0]: https://github.com/timbod7/haskell-chart/wiki [1]: http://projects.haskell.org/diagrams/ [2]: http://hackage.haskell.org/package/cairo [3]: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/jbracker/... [4]: http://www.google-melange.com/gsoc/project/google/gsoc2013/jbracker/33001 [5]: http://hackage.haskell.org/packages/archive/Chart/1.0/doc/html/Graphics-Rend... [6]: http://hackage.haskell.org/package/Chart-cairo [7]: http://hackage.haskell.org/package/Chart-diagrams [8]: https://groups.google.com/d/topic/diagrams-discuss/S2nkxyxbtcY/discussion [9]: http://hackage.haskell.org/package/operational [10]: http://hackage.haskell.org/package/SVGFonts [11]: https://github.com/timbod7/haskell-chart/blob/master/chart-diagrams/Graphics... [12]: http://hackage.haskell.org/package/diagrams-svg [13]: https://github.com/timbod7/haskell-chart/wiki/How-to-use-backends