[Haskell-cafe] Fwd: [GSoC 2013] Porting Charts to Diagrams - Final Report

Jan Bracker jan.bracker at googlemail.com
Thu Sep 26 18:47:21 CEST 2013

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

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].


[0]: https://github.com/timbod7/haskell-chart/wiki
[1]: http://projects.haskell.org/diagrams/
[2]: http://hackage.haskell.org/package/cairo
[6]: http://hackage.haskell.org/package/Chart-cairo
[7]: http://hackage.haskell.org/package/Chart-diagrams
[9]: http://hackage.haskell.org/package/operational
[10]: http://hackage.haskell.org/package/SVGFonts
[12]: http://hackage.haskell.org/package/diagrams-svg
[13]: https://github.com/timbod7/haskell-chart/wiki/How-to-use-backends
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130926/69a14b51/attachment.htm>

More information about the Haskell-Cafe mailing list