Difference between revisions of "Diagrams/Projects"

From HaskellWiki
Jump to navigation Jump to search
(→‎Backends: update repo links etc.)
(15 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
Looking for something to work on? Try one of these!
  
Looking for something to work on? Try one of these!
   
  +
=== Port cool examples to diagrams ===
−
* Figure out an infrastructure for including animations in the gallery and/or user manual
  
−
* Improvements to paths: lengthening/shortening, arrowheads, etc.
  
−
* Controlled creation of splines using an API like the one in MetaPost.
  
   
  +
There is actually quite a lot of value in taking some existing cool graphics or animations and reimplementing them using diagrams, both as a way to obtain some cool examples for the gallery, and to help drive new features in diagrams or active. (So examples that we would ''like'' to be able to describe in diagrams but cannot easily do are particularly interesting---what feature(s) would need to be added to make them possible?)
−
==Backends==
  
  +
  +
Some possible sources of inspiration:
  +
* http://web.williams.edu/Mathematics/devadoss/papers.html
  +
* http://www.bridgesmathart.org/
  +
* http://recodeproject.com/
  +
* [http://www.joachim-breitner.de/blog/archives/557-A-copying-garbage-collector-animated.html Joachim Breitner's animation of a copying garbage collector]
  +
* [http://www.numbersimulation.com/ Cool animation demonstrating the concept of prime numbers with orbiting segments for each natural]
  +
* [http://youtu.be/ug9fhgy9N60 animation of creating a dragon curve fractal by cutting and sliding blocks]
  +
* [http://www.mathcurve.com/fractals/gosper/gosper.shtml Gosper fractal, aka flowsnake]
  +
  +
=== Include animations in the gallery and user manual ===
  +
  +
We need some sort of infrastructure for including animations in the gallery and/or user manual. See https://github.com/diagrams/diagrams-doc/issues/1 .
  +
  +
=== GTK application for creating diagrams interactively ===
  +
  +
Having a tight feedback loop between coding and seeing the reflected changes in a diagram is important. Right now some of the backends have a "looped" compilation mode, but it's somewhat clunky and still a lot slower than it could be, probably due to overheads of compilation, linking, etc.
  +
  +
The idea would be to develop a GTK application allowing the user to edit diagrams code (either with an in-application editing pane or in their own editor, perhaps using [http://hackage.haskell.org/package/fsnotify fsnotify] to watch for changes) and see the updated diagram immediately. Additional potential features include:
  +
  +
* the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file
  +
* using sliders, input boxes, etc. to interactively display parameterized diagrams, perhaps in a type-directed way (see [http://hackage.haskell.org/package/craftwerk-gtk craftwerk-gtk] for inspiration)
  +
* Interactive editing of diagrams, e.g. dragging a displayed component and having an appropriate translation call automatically added to the code, or some other sort of support for interactively generating points, vectors, scaling factors, etc. using mouse input
  +
* Support for developing animations (e.g. with a slider for moving back+forth in time)
  +
  +
=== Path operations ===
  +
  +
It would be nice if diagrams could support various operations on paths such as intersection and union, curve fitting, and path simplification. See also [[Diagrams/Dev/Paths]], which has quite a bit of information on current efforts to implement path offsets and other path-related things.
  +
  +
A student taking this on would probably already need some experience in computational geometry and paths in particular; implementing path algorithms properly is notoriously tricky (though having an incomplete and buggy implementation that nonetheless works "most of the time" would still be better than nothing!).
  +
  +
For more ideas see http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html.
  +
  +
=== Taking advantage of diagram tree structure ===
  +
  +
Diagrams are stored using a [http://hackage.haskell.org/package/dual%2Dtree fancy tree data structure], but currently diagrams backends cannot take advantage of this information: diagrams are simply compiled into a list of primitives with attributes, and these are handed off to the backend. This has some important implications:
  +
  +
* Sometimes it leads to inefficiency. For example, the diagrams code <code>fc blue (hcat $ replicate 1000 (circle 1))</code> results in backends setting the fill color 1000 times (once for each circle), when instead the fill color ought to be set just once.
  +
  +
* There are additional features which could be implemented if backends were able to observe the tree structure, such as grouping for transparency.
  +
  +
The project would consist in first figuring out how best to change the backend interface to allow observing the tree structure, and then implementing new features and improvements to backends based on this new ability.
  +
  +
The devil's in the details: working with the diagram trees can be tricky. This is not a project for the faint of heart, but if you like getting down into tricky details, understanding them, and coming up with creative and elegant ways to achieve a goal given a number of constraints, this could be a fun project with a big impact.
  +
  +
=== Constraint Based Diagrams ===
  +
  +
Generate diagrams that meet some declarative constraint specification---perhaps something
  +
along the lines of http://wadler.blogspot.com/2011/06/combinator-library-for-design-of.html . The idea is to allow users to specify constraints on their diagram layout (e.g. "A should be no further left than B", "C and D should be at least 2 and at most 8 units apart"), probably using simple linear inequalities, and then solve them to generate an appropriate layout.
  +
  +
A large part of the project would be in simply coming up with a good design for the user API and how to collect constraints; the rest would consist in figuring out how to solve the constraints (either directly, or by hooking up to some other library to e.g. solve systems of linear constraints).
  +
  +
=== 3D diagrams ===
  +
  +
Diagrams notionally supports arbitrary vector spaces, but no one has yet done the necessary work to make three-dimensional diagrams a reality. This project would have two main components:
  +
  +
* Add three-dimensional primitives and functions to [https://github.com/diagrams/diagrams-lib diagrams-lib].
  +
  +
* Work on one (or more) backends that can render 3D diagrams in some way. Options include developing the stub [https://github.com/diagrams/diagrams-povray diagrams-povray] backend, or developing an OpenGL backend.
  +
  +
A related project is to create projections of 3D objects to 2D for use with the current backends. These can be useful for diagrams that go into documentation and can be thought of as illustrations of 3D objects or simple animations. There are many examples of how to do this, one that I found quite accessible can be found [https://www.khanacademy.org/cs/3d-caffeine-molecule/1547272093 here] (hat tip to Joel Burget on twitter for the link).
  +
  +
=== Make Plotting As Easy As Doing It in R ===
  +
  +
From diagram-discuss:
  +
  +
The above code produces four plots: a scatterplot (something you would
  +
often see in statistics), a plot of a function and, well, two empty
  +
grids. As a statistician, I usually work a lot with R together with a
  +
more or less sophisticated plotting package. The currently best
  +
plotting system for R is probably [http://had.co.nz/ggplot2/ ggplot ]. Now, I started using
  +
Bryan O'Sullivan's [http://hackage.haskell.org/package/statistics/ statistics package] for some of my calculations.
  +
Once in Haskell mode, you obviously don't want to switch back and
  +
forth between languages. So, I was wondering if it is possible to
  +
produce professional looking plots with diagrams' DSL, and how
  +
difficult it could be to put together a DSL for (statistical)
  +
plotting.
  +
  +
I was thinking of something similar to ggplot's functionality. Making
  +
it easy to overlay plots, producing and combining legends, etc.
  +
Creating scatterplots and histograms and boxplots. Overlaying them
  +
with error regions and density estimates respectively. Then do the
  +
same for different subsets of the original data. Doing this with
  +
diagrams DSL could proof to be extremely powerful. Each "dot" in a
  +
plot could potentially be any diagram you want, dots, circles, stars,
  +
numbers or characters -- and if plots are nothing but diagrams, you
  +
could even plot plots into a plot. A real pain for most plotting
  +
systems is to combine multiple plots into one and to generate a common
  +
legend for all of them. This, for example, should be trivial to do
  +
within diagrams DSL.
  +
  +
I would be more than happy to help in such a project. As the code
  +
above probably suggests, I am not the strongest Haskell hacker around.
  +
In fact, I am a statistician/mathematician who happens to use Haskell
  +
for some of his projects. That's it. Would anyone be interested in
  +
picking up such a project? As I said, I would be happy to help and
  +
get involved. Because I think there is a real need for something like
  +
this, and it would be very powerful to have eDSL for statistical
  +
plotting within Haskell.
  +
  +
There seems to some interest in this idea:
  +
https://groups.google.com/d/topic/diagrams-discuss/TR9_Q8YnhMo/discussion
  +
  +
'''Interested Students:'''
  +
  +
* Jan Bracker
  +
  +
=== External Rendering ===
  +
  +
The idea here would be to allow for special external rendering of some primitive that Diagrams does not support. For instance, it would be nice to be able to express LaTeX expressions and when the backend renders, offload the work externally then incorporate it with the output. There are several dimensions to supporting this well and making it as backend agnostic as possible. Somewhat related is the idea of external layout such as asking GraphViz to layout some structure then doing the rendering based on those positions. At the simplest this is just turning some new primitive into an `Image` primitive on the fly in the `Renderable` instance.
  +
  +
=== Variable Precision ===
  +
  +
It would be nice to be able to trade off precision of the vector output of some
  +
backend with the size of that output. For instance the factorization diagrams
  +
are rather large when rendered to SVG, but their size could be cut in half by
  +
emitting doubles formatted to two significant digits. There is a nice balance
  +
that could be struck at a high level where we ensure that we are always within
  +
some fraction of what will likely be a pixel in the final output. Then at the
  +
level of the backend we would only need to choose the representation that is
  +
the smallest for any particular number.
  +
  +
This could be aided by generalized R2.
  +
  +
=== Diagrams Paste Site ===
  +
  +
Create a pastebin site where diagrams code is automatically compiled and the output shown alongside the code. This would be cool for sharing experiments, teaching beginners, helping out people having problems, and so on.
  +
  +
Potential sources of inspiration/libraries to use/code to steal:
  +
  +
* [http://hpaste.org hpaste] ([https://github.com/chrisdone/hpaste git source])
  +
* [http://diagrams.alpmestan.com diagrams.alpmestan.com] ([http://hub.darcs.net/alp/factorization-diagrams-happstack darcs source])
  +
* [http://hackage.haskell.org/package/diagrams%2Dbuilder diagrams-builder] ([http://github.com/diagrams/diagrams-builder git source])
  +
* [http://hackage.haskell.org/package/mueval mueval] ([http://code.haskell.org/mubot/ darcs source])
  +
  +
'''Interested Students:'''
  +
  +
* Dan Frumin
  +
  +
=== Auto-generated "simple" prelude ===
  +
  +
The diagrams library is extremely polymorphic---much too polymorphic
  +
for beginning users, perhaps. The goal of this project would be to
  +
write some code to automatically generate a module
  +
Diagrams.Prelude.Simple which re-exports things from Diagrams.Prelude
  +
but with more monomorphic types. This would require obtaining the
  +
types of things exported by Diagrams.Prelude, doing some analysis to
  +
determine what "simpler" type to use, then outputting the appropriate
  +
code. There are some interesting, nontrivial questions to be worked
  +
out in terms of how to generate a "simple" type from a more general
  +
one. There may even be room for multiple "levels" with successively
  +
more polymorphism.
  +
  +
=== Contrib module for graph drawing ===
  +
  +
We have a contrib module for drawing trees; it would be nice to have something for drawing more general graphs. One idea would be to round-trip graph data through Graphviz to do the layout; then it is just a matter of allowing the user to describe how they want their graph styled and visualized.
  +
  +
=== Do a better job combining envelopes ===
  +
  +
Add extra intensional information to help do a better job with combining envelopes? e.g. inner and outer bounding boxes, circles, etc. e.g. if the outer bound of one lies completely inside the inner bound of another, the resulting combined envelope can be optimized to not actually do a max operation.
  +
  +
=== Convert SVG files to diagrams ===
  +
  +
It's impossible to support all the features of SVGs, but for a nontrivial subset of SVG it should be possible to parse an SVG file and convert it into a Path and/or a Diagram. This would be a really cool way to allow importing components more easily generated with some other tool---for example, use something like Inkscape to create some paths (using some of Inkscape's advanced tools, drawing them freehand, or whatever), export as SVG, then import those paths into a diagram and use/process them further.
  +
  +
=== Auto-generate "connect the dots" puzzles
  +
  +
You know those "connect-the-dots" activities for kids? It would be fun to take (say) an SVG as input (this depends on the previous project) and output a "connect-the-dots" version. Fun for the whole family.
  +
  +
==Officially supported backends==
  +
  +
=== Native SVG ===
  +
  +
A Haskell-native backend generating SVG. As of diagrams-0.6 this is the default "out-of-the-box" diagrams backend.
  +
  +
* [http://hackage.haskell.org/package/diagrams%2Dsvg hackage]
  +
* [https://github.com/diagrams/diagrams-svg github repo]
  +
* Status: active development
  +
* Participants: Deepak Jois, Ryan Yates, Felipe Lessa, Brent Yorgey
   
 
=== Cairo ===
  
=== Cairo ===
   
−
Officially supported backend using [http://www.cairographics.org/ cairo].
+
Full-featured backend using [http://www.cairographics.org/ cairo].
   
  +
* [http://hackage.haskell.org/package/diagrams%2Dcairo hackage]
 
* [http://github.com/diagrams/diagrams-cairo github repo]
  
* [http://github.com/diagrams/diagrams-cairo github repo]
 
* Status: active development
  
* Status: active development
 
* Participants: Brent Yorgey, Ryan Yates
  
* Participants: Brent Yorgey, Ryan Yates
   
−
=== Native SVG ===
 +
=== GTK ===
   
  +
Backend built on top of the cairo backend for rendering directly to GTK windows.
−
A Haskell-native backend generating SVG. The intention is for this to eventually replace cairo as the "out-of-the-box" diagrams backend.
  
   
−
* [https://github.com/deepakjois/diagrams-svg github repo]
 +
* [http://hackage.haskell.org/package/diagrams%2Dgtk hackage]
  +
* [http://github.com/diagrams/diagrams-gtk github repo]
 
* Status: active development
  
* Status: active development
−
* Participants: Deepak Jois, Ryan Yates, Felipe Lessa, Brent Yorgey
 +
* Participants: John Lato, Brent Yorgey
   
 
=== Native Postscript ===
  
=== Native Postscript ===
Line 29: Line 208:
 
Very similar to the Cairo backend but only outputting EPS.
  
Very similar to the Cairo backend but only outputting EPS.
   
−
* [https://github.com/fryguybob/diagrams-postscript github repo]
 +
* [http://hackage.haskell.org/package/diagrams%2Dpostscript hackage]
  +
* [https://github.com/diagrams/diagrams-postscript github repo]
 
* Status: active development
  
* Status: active development
 
* Participants: Ryan Yates
  
* Participants: Ryan Yates
  +
  +
== Unofficial backends ==
   
 
=== HTML5 canvas ===
  
=== HTML5 canvas ===
Line 37: Line 219:
 
* [https://github.com/ku-fpg/diagrams-canvas github repo]
  
* [https://github.com/ku-fpg/diagrams-canvas github repo]
 
* [https://github.com/byorgey/diagrams-canvas variant ported to work with blank-canvas]
  
* [https://github.com/byorgey/diagrams-canvas variant ported to work with blank-canvas]
−
* Status: active development
 +
* Status: dormant
 
* Participants: Andy Gill, Brent Yorgey
  
* Participants: Andy Gill, Brent Yorgey
   
 
=== LaTeX/TikZ ===
  
=== LaTeX/TikZ ===
   
−
* original [http://patch-tag.com/r/snwalck/diagrams-tikz darcs repo]
 +
* original [http://patch-tag.com/r/snwalck/diagrams-tikz darcs repo] by Scott Walck
−
by Scott Walck
  
 
* [https://github.com/mahrz/diagrams-tikz updated version] by Malte Harder on github
  
* [https://github.com/mahrz/diagrams-tikz updated version] by Malte Harder on github
−
* Status: active development
 +
* Status: dormant
 
* Participants: Scott Walck, Malte Harder
  
* Participants: Scott Walck, Malte Harder
   

Revision as of 18:37, 14 June 2013

Potential projects

Looking for something to work on? Try one of these!

Port cool examples to diagrams

There is actually quite a lot of value in taking some existing cool graphics or animations and reimplementing them using diagrams, both as a way to obtain some cool examples for the gallery, and to help drive new features in diagrams or active. (So examples that we would like to be able to describe in diagrams but cannot easily do are particularly interesting---what feature(s) would need to be added to make them possible?)

Some possible sources of inspiration:

Include animations in the gallery and user manual

We need some sort of infrastructure for including animations in the gallery and/or user manual. See https://github.com/diagrams/diagrams-doc/issues/1 .

GTK application for creating diagrams interactively

Having a tight feedback loop between coding and seeing the reflected changes in a diagram is important. Right now some of the backends have a "looped" compilation mode, but it's somewhat clunky and still a lot slower than it could be, probably due to overheads of compilation, linking, etc.

The idea would be to develop a GTK application allowing the user to edit diagrams code (either with an in-application editing pane or in their own editor, perhaps using fsnotify to watch for changes) and see the updated diagram immediately. Additional potential features include:

  • the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file
  • using sliders, input boxes, etc. to interactively display parameterized diagrams, perhaps in a type-directed way (see craftwerk-gtk for inspiration)
  • Interactive editing of diagrams, e.g. dragging a displayed component and having an appropriate translation call automatically added to the code, or some other sort of support for interactively generating points, vectors, scaling factors, etc. using mouse input
  • Support for developing animations (e.g. with a slider for moving back+forth in time)

Path operations

It would be nice if diagrams could support various operations on paths such as intersection and union, curve fitting, and path simplification. See also Diagrams/Dev/Paths, which has quite a bit of information on current efforts to implement path offsets and other path-related things.

A student taking this on would probably already need some experience in computational geometry and paths in particular; implementing path algorithms properly is notoriously tricky (though having an incomplete and buggy implementation that nonetheless works "most of the time" would still be better than nothing!).

For more ideas see http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html.

Taking advantage of diagram tree structure

Diagrams are stored using a fancy tree data structure, but currently diagrams backends cannot take advantage of this information: diagrams are simply compiled into a list of primitives with attributes, and these are handed off to the backend. This has some important implications:

  • Sometimes it leads to inefficiency. For example, the diagrams code fc blue (hcat $ replicate 1000 (circle 1)) results in backends setting the fill color 1000 times (once for each circle), when instead the fill color ought to be set just once.
  • There are additional features which could be implemented if backends were able to observe the tree structure, such as grouping for transparency.

The project would consist in first figuring out how best to change the backend interface to allow observing the tree structure, and then implementing new features and improvements to backends based on this new ability.

The devil's in the details: working with the diagram trees can be tricky. This is not a project for the faint of heart, but if you like getting down into tricky details, understanding them, and coming up with creative and elegant ways to achieve a goal given a number of constraints, this could be a fun project with a big impact.

Constraint Based Diagrams

Generate diagrams that meet some declarative constraint specification---perhaps something along the lines of http://wadler.blogspot.com/2011/06/combinator-library-for-design-of.html . The idea is to allow users to specify constraints on their diagram layout (e.g. "A should be no further left than B", "C and D should be at least 2 and at most 8 units apart"), probably using simple linear inequalities, and then solve them to generate an appropriate layout.

A large part of the project would be in simply coming up with a good design for the user API and how to collect constraints; the rest would consist in figuring out how to solve the constraints (either directly, or by hooking up to some other library to e.g. solve systems of linear constraints).

3D diagrams

Diagrams notionally supports arbitrary vector spaces, but no one has yet done the necessary work to make three-dimensional diagrams a reality. This project would have two main components:

  • Add three-dimensional primitives and functions to diagrams-lib.
  • Work on one (or more) backends that can render 3D diagrams in some way. Options include developing the stub diagrams-povray backend, or developing an OpenGL backend.

A related project is to create projections of 3D objects to 2D for use with the current backends. These can be useful for diagrams that go into documentation and can be thought of as illustrations of 3D objects or simple animations. There are many examples of how to do this, one that I found quite accessible can be found here (hat tip to Joel Burget on twitter for the link).

Make Plotting As Easy As Doing It in R

From diagram-discuss:

The above code produces four plots: a scatterplot (something you would often see in statistics), a plot of a function and, well, two empty grids. As a statistician, I usually work a lot with R together with a more or less sophisticated plotting package. The currently best plotting system for R is probably ggplot . Now, I started using Bryan O'Sullivan's statistics package for some of my calculations. Once in Haskell mode, you obviously don't want to switch back and forth between languages. So, I was wondering if it is possible to produce professional looking plots with diagrams' DSL, and how difficult it could be to put together a DSL for (statistical) plotting.

I was thinking of something similar to ggplot's functionality. Making it easy to overlay plots, producing and combining legends, etc. Creating scatterplots and histograms and boxplots. Overlaying them with error regions and density estimates respectively. Then do the same for different subsets of the original data. Doing this with diagrams DSL could proof to be extremely powerful. Each "dot" in a plot could potentially be any diagram you want, dots, circles, stars, numbers or characters -- and if plots are nothing but diagrams, you could even plot plots into a plot. A real pain for most plotting systems is to combine multiple plots into one and to generate a common legend for all of them. This, for example, should be trivial to do within diagrams DSL.

I would be more than happy to help in such a project. As the code above probably suggests, I am not the strongest Haskell hacker around. In fact, I am a statistician/mathematician who happens to use Haskell for some of his projects. That's it. Would anyone be interested in picking up such a project? As I said, I would be happy to help and get involved. Because I think there is a real need for something like this, and it would be very powerful to have eDSL for statistical plotting within Haskell.

There seems to some interest in this idea: https://groups.google.com/d/topic/diagrams-discuss/TR9_Q8YnhMo/discussion

Interested Students:

  • Jan Bracker

External Rendering

The idea here would be to allow for special external rendering of some primitive that Diagrams does not support. For instance, it would be nice to be able to express LaTeX expressions and when the backend renders, offload the work externally then incorporate it with the output. There are several dimensions to supporting this well and making it as backend agnostic as possible. Somewhat related is the idea of external layout such as asking GraphViz to layout some structure then doing the rendering based on those positions. At the simplest this is just turning some new primitive into an `Image` primitive on the fly in the `Renderable` instance.

Variable Precision

It would be nice to be able to trade off precision of the vector output of some backend with the size of that output. For instance the factorization diagrams are rather large when rendered to SVG, but their size could be cut in half by emitting doubles formatted to two significant digits. There is a nice balance that could be struck at a high level where we ensure that we are always within some fraction of what will likely be a pixel in the final output. Then at the level of the backend we would only need to choose the representation that is the smallest for any particular number.

This could be aided by generalized R2.

Diagrams Paste Site

Create a pastebin site where diagrams code is automatically compiled and the output shown alongside the code. This would be cool for sharing experiments, teaching beginners, helping out people having problems, and so on.

Potential sources of inspiration/libraries to use/code to steal:

Interested Students:

  • Dan Frumin

Auto-generated "simple" prelude

The diagrams library is extremely polymorphic---much too polymorphic for beginning users, perhaps. The goal of this project would be to write some code to automatically generate a module Diagrams.Prelude.Simple which re-exports things from Diagrams.Prelude but with more monomorphic types. This would require obtaining the types of things exported by Diagrams.Prelude, doing some analysis to determine what "simpler" type to use, then outputting the appropriate code. There are some interesting, nontrivial questions to be worked out in terms of how to generate a "simple" type from a more general one. There may even be room for multiple "levels" with successively more polymorphism.

Contrib module for graph drawing

We have a contrib module for drawing trees; it would be nice to have something for drawing more general graphs. One idea would be to round-trip graph data through Graphviz to do the layout; then it is just a matter of allowing the user to describe how they want their graph styled and visualized.

Do a better job combining envelopes

Add extra intensional information to help do a better job with combining envelopes? e.g. inner and outer bounding boxes, circles, etc. e.g. if the outer bound of one lies completely inside the inner bound of another, the resulting combined envelope can be optimized to not actually do a max operation.

Convert SVG files to diagrams

It's impossible to support all the features of SVGs, but for a nontrivial subset of SVG it should be possible to parse an SVG file and convert it into a Path and/or a Diagram. This would be a really cool way to allow importing components more easily generated with some other tool---for example, use something like Inkscape to create some paths (using some of Inkscape's advanced tools, drawing them freehand, or whatever), export as SVG, then import those paths into a diagram and use/process them further.

=== Auto-generate "connect the dots" puzzles

You know those "connect-the-dots" activities for kids? It would be fun to take (say) an SVG as input (this depends on the previous project) and output a "connect-the-dots" version. Fun for the whole family.

Officially supported backends

Native SVG

A Haskell-native backend generating SVG. As of diagrams-0.6 this is the default "out-of-the-box" diagrams backend.

  • hackage
  • github repo
  • Status: active development
  • Participants: Deepak Jois, Ryan Yates, Felipe Lessa, Brent Yorgey

Cairo

Full-featured backend using cairo.

GTK

Backend built on top of the cairo backend for rendering directly to GTK windows.

Native Postscript

Very similar to the Cairo backend but only outputting EPS.

Unofficial backends

HTML5 canvas

LaTeX/TikZ

  • original darcs repo by Scott Walck
  • updated version by Malte Harder on github
  • Status: dormant
  • Participants: Scott Walck, Malte Harder

POV-Ray

A POV-Ray backend for 3D diagrams.

  • github repo
  • Status: proof of concept only, needs someone to take it over!

Wanted backends

  • OpenGL

Related packages and tools

command-line/interactive

See also an earlier project in a similar direction:

Build service

diagrams-builder is a library providing the ability to dynamically interpret diagrams code snippets, including utilities for creating temporary files etc. as needed. Useful for making preprocessing tools for embedding diagrams code in other document formats (e.g. LaTeX).

Fonts

The SVGFonts package implements Haskell-native font support (for fonts in the SVG-font format) that can be plugged into diagrams.

Other projects

gtk-toy

Michael Sloan's gtk-toy project is a framework for creating interactive gtk/cairo applications. gtk-toy-diagrams provides tools for using diagrams in conjunction with gtk-toy.

LaTeXgrapher

LaTeXGrapher is a project by Ryan Yates providing a domain-specific language for producing mathematical graphs, backed by the diagrams-postscript backend.

Deepak Jois is working on a logo interpreter written in Haskell, using diagrams as a backend.

Packages using diagrams

Retrieved from "https://wiki.haskell.org/index.php?title=Diagrams/Projects&oldid=56268"