Difference between revisions of "Diagrams/Projects"

From HaskellWiki
Jump to navigation Jump to search
(→‎Unofficial backends: add diagrams-wx)
 
(43 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
==Potential projects==
  
==Potential projects==
   
  +
Looking for something to work on? Try one of these! There are also even more (crazy, potentially impossible) project ideas which can be found on the [https://trello.com/b/pL6YdKgz diagrams Trello board]. If you have any questions or want to discuss a potential project, send an email to the [https://groups.google.com/group/diagrams-discuss mailing list].
−
Looking for something to work on? Try one of these!
  
   
  +
=== ggplot ===
−
See also [[Diagrams/GSoC]] which has more ideas.
  
   
  +
Implementing a "grammar of graphics" should be something at which Haskell excels.
−
* Figure out an infrastructure for including animations in the gallery and/or user manual. See https://github.com/diagrams/diagrams-doc/issues/1 .
  
  +
−
* Build some [[example animations]].
  
  +
See
−
* 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.
  
  +
  +
* http://ggplot2.org
  +
* http://www.cs.uic.edu/~wilkinson/TheGrammarOfGraphics/GOG.html
  +
  +
=== 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:
  +
* 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]
  +
* [http://beesandbombs.tumblr.com/ Bees and Bombs]
  +
* [https://upload.wikimedia.org/wikipedia/commons/4/4e/Circle_radians.gif Visual explanation of radians]
  +
  +
=== Include animations in the gallery and user manual ===
  +
  +
We need some sort of infrastdireructure for including animations in the gallery and/or user manual. See https://github.com/diagrams/diagrams-doc/issues/1 .
  +
  +
=== Visualization suite for the Haskell ecosystem ===
  +
  +
There are potentially tons of visualizations that could benefit both people learning Haskell and Haskell developers. Examples of things we might be able to visualize include:
  +
  +
* cabal build plans (especially failures)
  +
* APIs and API diffs
  +
* algebraic data types
  +
* memory layout/usage of data structures
  +
* graph reduction/lazy evaluation
  +
* types
  +
* maps, folds, filters, zips, etc.
  +
* zippers
  +
* Functor/Applicative/Monad operations/types
  +
  +
But there are probably lots of other things that make sense too. The idea would be to create some useful standalone tools---potentially even exposed as a web service, to remove the necessity for users to build them---to benefit all Haskell users.
  +
  +
This project of course would require creativity and a good sense of design and data visualization. See [http://www.edwardtufte.com/tufte/books_vdqi Edward Tufte] for inspiration.
  +
  +
=== GUI 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 GUI 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)
  +
  +
Perhaps this could be built on top of GTK and diagrams-cairo, or for maximal platform independence perhaps it could use something like threepenny-gui and diagrams-sunroof.
  +
  +
=== Search for Interesting Diagrams ===
  +
  +
Inspired by QuickCheck and SmallCheck, the idea is to probe some function that produces a diagram to explore the range of diagrams it can produce. Instead of looking for failures it would be looking for differences (visually, in path complexity, time, space, etc.). Such a tool could be useful for generating galleries displaying the capabilities of some diagram generating function or debugging some function to find inputs that do not produce output in the expected visual range.
  +
  +
=== 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 [https://github.com/diagrams/diagrams-lib/issues/50#issuecomment-23940308 generalized R2].
  +
  +
=== 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.
  +
  +
=== Graph drawing ===
  +
  +
We have a contrib module for drawing trees; we have diagrams-graphviz which can interface with GraphViz to do graph layout. However we are still missing higher-level tools for drawing graphs in general. This might include a language for describing and styling graphs. A big part of it (which would be useful in many contexts) would be building good tools for edge labelling.
  +
  +
=== 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.
  +
  +
=== 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 and output a "connect-the-dots" version. Fun for the whole family.
  +
  +
=== DSL for identifying subdiagrams ===
  +
  +
It would be extremely useful if subdiagrams could be identified using a small combinator DSL. For example, <hask>isLine `which` (connects isTriangle isTriangle)</hask> to return the line in a diagram connecting two triangles. Or <hask>smallest `which` isCircle</hask> the get the smallest circle. Then we would not always need to name subdiagrams and we would gain the ability to modify diagrams and subdiagrams after they have been created. Things like <hask>(isSquare `which` hasEdge 2) # lw 0.2 # fc red</hask>, and perhaps even, <hask>delete $ isPoly `which` (numSides 5)</hask> become possible. The idea would be to start with something very simple that we could add to incrementally.
  +
  +
=== Port potrace to Haskell ===
  +
  +
See http://potrace.sourceforge.net/ and in particular http://potrace.sourceforge.net/potrace.pdf . There do exist Haskell bindings to potrace but the idea would be to reimplement it directly in Haskell.
  +
  +
=== General curved surfaces in 3D ===
  +
  +
We have some basic 3D support in the POV-Ray backend, limited to primitives such as boxes, spheres, and cones. It would be good to have a more general, flexible representation of solids, comparable to the flexibility of Cubic Bezier curves in 2D. Examples of suitable representations include bicubic patches, NURBs, and various implicit surface descriptions. The first step is choosing which representation to implement.
  +
  +
A minimal implementation would be able to calculate Envelope and Trace for the new primitives, and to render in at least one Backend (POV-Ray or OpenGL). More interesting methods of constructing surfaces, including CSG, extrusion, and revolution, can follow.
   
 
==Officially supported backends==
  
==Officially supported backends==
Line 18: Line 132:
 
* [https://github.com/diagrams/diagrams-svg github repo]
  
* [https://github.com/diagrams/diagrams-svg github repo]
 
* Status: active development
  
* Status: active development
  +
−
* Participants: Deepak Jois, Ryan Yates, Felipe Lessa, Brent Yorgey
  
  +
=== Rasterific ===
  +
  +
A Haskell-native backend generating raster graphics, using the [http://hackage.haskell.org/package/Rasterific Rasterific] package.
  +
  +
* [http://hackage.haskell.org/package/diagrams-rasterific hackage]
  +
* [https://github.com/diagrams/diagrams-rasterific github repo]
  +
* Status: active development
   
 
=== Cairo ===
  
=== Cairo ===
Line 38: Line 159:
 
* Participants: John Lato, Brent Yorgey
  
* Participants: John Lato, Brent Yorgey
   
−
=== Native Postscript ===
 +
=== Postscript ===
   
 
Very similar to the Cairo backend but only outputting EPS.
  
Very similar to the Cairo backend but only outputting EPS.
Line 46: Line 167:
 
* Status: active development
  
* Status: active development
 
* Participants: Ryan Yates
  
* Participants: Ryan Yates
  +
  +
=== PGF ===
  +
  +
A backend emitting PGF/TikZ TeX code.
  +
  +
* [http://hackage.haskell.org/package/diagrams-pgf hackage]
  +
* [https://github.com/diagrams/diagrams-pgf github repo]
  +
* Status: active development
  +
* Participants: Chris Chalmers
  +
  +
=== Canvas ===
  +
  +
An interactive backend drawing on an HTML5 canvas.
  +
  +
* [http://hackage.haskell.org/package/diagrams-canvas hackage]
  +
* [https://github.com/diagrams/diagrams-canvas github repo]
  +
* Status: active development
  +
* Participants: Jeff Rosenbluth, Andy Gill
  +
  +
=== HTML5 ===
  +
  +
A backend emitting javascript HTML5 canvas output.
  +
  +
* [http://hackage.haskell.org/package/diagrams-html5 hackage]
  +
* [https://github.com/diagrams/diagrams-html5 github repo]
  +
* Status: active development
  +
* Participants: Jeff Rosenbluth
   
 
== Unofficial backends ==
  
== Unofficial backends ==
   
−
=== HTML5 canvas ===
 +
=== PDF ===
   
−
* [https://github.com/ku-fpg/diagrams-canvas github repo]
 +
* [http://hackage.haskell.org/package/diagrams-pdf Hackage]
−
* [https://github.com/byorgey/diagrams-canvas variant ported to work with blank-canvas]
 +
* [https://github.com/alpheccar/diagrams-pdf github repo]
 
* Status: dormant
  
* Status: dormant
−
* Participants: Andy Gill, Brent Yorgey
 +
* Participants: Christophe F
   
−
=== LaTeX/TikZ ===
 +
=== GHCJS/canvas ===
   
−
* original [http://patch-tag.com/r/snwalck/diagrams-tikz darcs repo] by Scott Walck
 +
* [https://github.com/ghcjs/diagrams-ghcjs github repo]
  +
* Status: active development
−
* [https://github.com/mahrz/diagrams-tikz updated version] by Malte Harder on github
  
  +
* Participants: Daniil Frumin, Luite Stegeman, Daniel Bergey
  +
  +
=== OpenGL ===
  +
  +
* [https://github.com/bergey/diagrams-opengl github repo]
 
* Status: dormant
  
* Status: dormant
−
* Participants: Scott Walck, Malte Harder
 +
* Participants: Daniel Bergey
   
 
=== POV-Ray ===
  
=== POV-Ray ===
Line 68: Line 221:
   
 
* [http://github.com/diagrams/diagrams-povray github repo]
  
* [http://github.com/diagrams/diagrams-povray github repo]
  +
* Status: Alpha, active development
−
* Status: proof of concept only, needs someone to take it over!
  
  +
* Participants: Daniel Bergey
   
−
=== Wanted backends ===
 +
=== HsQML ===
   
  +
A backend for painting on a QtQuick Canvas.
−
* OpenGL
  
  +
  +
* [http://hackage.haskell.org/package/diagrams%2Dhsqml Hackage]
  +
* [https://github.com/marcinmrotek/diagrams-hsqml github repo]
  +
* Status: active
  +
* Participants: Marcin Mrotek
  +
  +
=== wxWidgets ===
  +
  +
Backend built on top of the cairo backend for rendering in wxWidgets (via [[WxHaskell]]).
  +
  +
* [http://hackage.haskell.org/package/diagrams%2Dwx hackage]
  +
* [http://github.com/spinda/diagrams-wx github repo]
  +
* Status: stable
  +
* Participants: Michael Smith
  +
  +
== Bitrotted/abandoned/superseded backends ==
  +
  +
=== LaTeX/TikZ ===
  +
  +
* original [http://patch-tag.com/r/snwalck/diagrams-tikz darcs repo] by Scott Walck
  +
* [https://github.com/mahrz/diagrams-tikz updated version] by Malte Harder on github
  +
* Yet another version is [http://hackage.haskell.org/package/diagrams%2Dtikz on Hackage]
  +
* Status: dormant
  +
* Participants: Scott Walck, Malte Harder
  +
  +
=== HTML5 canvas ===
  +
  +
* [https://github.com/jbracker/diagrams-sunroof github repo]
  +
* Status: dormant
  +
* Participants: Jan Bracker, Andy Gill, Brent Yorgey
   
 
== Related packages and tools ==
  
== Related packages and tools ==
Line 83: Line 267:
   
 
* [http://patch-tag.com/r/fryguybob/diagrams-hint diagrams-hint]
  
* [http://patch-tag.com/r/fryguybob/diagrams-hint diagrams-hint]
  +
  +
=== Writing ===
  +
  +
* [http://hackage.haskell.org/package/diagrams%2Dhaddock diagrams-haddock] is a tool for embedding diagrams in Haddock documentation.
  +
* [http://hackage.haskell.org/package/BlogLiterately%2Ddiagrams BlogLiterately-diagrams] is a tool for embedding diagrams in blog posts.
   
 
=== Build service ===
  
=== Build service ===
Line 108: Line 297:
 
== Packages using diagrams ==
  
== Packages using diagrams ==
   
−
* [http://hackage.haskell.org/package/hierarchical-clustering-diagrams hierarchical-clustering-diagrams]
 +
See the [http://packdeps.haskellers.com/reverse/diagrams-lib reverse dependencies of diagrams-lib].

Latest revision as of 09:10, 10 April 2016

Potential projects

Looking for something to work on? Try one of these! There are also even more (crazy, potentially impossible) project ideas which can be found on the diagrams Trello board. If you have any questions or want to discuss a potential project, send an email to the mailing list.

ggplot

Implementing a "grammar of graphics" should be something at which Haskell excels.

See

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 infrastdireructure for including animations in the gallery and/or user manual. See https://github.com/diagrams/diagrams-doc/issues/1 .

Visualization suite for the Haskell ecosystem

There are potentially tons of visualizations that could benefit both people learning Haskell and Haskell developers. Examples of things we might be able to visualize include:

  • cabal build plans (especially failures)
  • APIs and API diffs
  • algebraic data types
  • memory layout/usage of data structures
  • graph reduction/lazy evaluation
  • types
  • maps, folds, filters, zips, etc.
  • zippers
  • Functor/Applicative/Monad operations/types

But there are probably lots of other things that make sense too. The idea would be to create some useful standalone tools---potentially even exposed as a web service, to remove the necessity for users to build them---to benefit all Haskell users.

This project of course would require creativity and a good sense of design and data visualization. See Edward Tufte for inspiration.

GUI 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 GUI 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)

Perhaps this could be built on top of GTK and diagrams-cairo, or for maximal platform independence perhaps it could use something like threepenny-gui and diagrams-sunroof.

Search for Interesting Diagrams

Inspired by QuickCheck and SmallCheck, the idea is to probe some function that produces a diagram to explore the range of diagrams it can produce. Instead of looking for failures it would be looking for differences (visually, in path complexity, time, space, etc.). Such a tool could be useful for generating galleries displaying the capabilities of some diagram generating function or debugging some function to find inputs that do not produce output in the expected visual range.

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.

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.

Graph drawing

We have a contrib module for drawing trees; we have diagrams-graphviz which can interface with GraphViz to do graph layout. However we are still missing higher-level tools for drawing graphs in general. This might include a language for describing and styling graphs. A big part of it (which would be useful in many contexts) would be building good tools for edge labelling.

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.

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 and output a "connect-the-dots" version. Fun for the whole family.

DSL for identifying subdiagrams

It would be extremely useful if subdiagrams could be identified using a small combinator DSL. For example, isLine `which` (connects isTriangle isTriangle) to return the line in a diagram connecting two triangles. Or smallest `which` isCircle the get the smallest circle. Then we would not always need to name subdiagrams and we would gain the ability to modify diagrams and subdiagrams after they have been created. Things like (isSquare `which` hasEdge 2) # lw 0.2 # fc red, and perhaps even, delete $ isPoly `which` (numSides 5) become possible. The idea would be to start with something very simple that we could add to incrementally.

Port potrace to Haskell

See http://potrace.sourceforge.net/ and in particular http://potrace.sourceforge.net/potrace.pdf . There do exist Haskell bindings to potrace but the idea would be to reimplement it directly in Haskell.

General curved surfaces in 3D

We have some basic 3D support in the POV-Ray backend, limited to primitives such as boxes, spheres, and cones. It would be good to have a more general, flexible representation of solids, comparable to the flexibility of Cubic Bezier curves in 2D. Examples of suitable representations include bicubic patches, NURBs, and various implicit surface descriptions. The first step is choosing which representation to implement.

A minimal implementation would be able to calculate Envelope and Trace for the new primitives, and to render in at least one Backend (POV-Ray or OpenGL). More interesting methods of constructing surfaces, including CSG, extrusion, and revolution, can follow.

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.

Rasterific

A Haskell-native backend generating raster graphics, using the Rasterific package.

Cairo

Full-featured backend using cairo.

GTK

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

Postscript

Very similar to the Cairo backend but only outputting EPS.

PGF

A backend emitting PGF/TikZ TeX code.

Canvas

An interactive backend drawing on an HTML5 canvas.

HTML5

A backend emitting javascript HTML5 canvas output.

Unofficial backends

PDF

GHCJS/canvas

  • github repo
  • Status: active development
  • Participants: Daniil Frumin, Luite Stegeman, Daniel Bergey

OpenGL

  • github repo
  • Status: dormant
  • Participants: Daniel Bergey

POV-Ray

A POV-Ray backend for 3D diagrams.

  • github repo
  • Status: Alpha, active development
  • Participants: Daniel Bergey

HsQML

A backend for painting on a QtQuick Canvas.

wxWidgets

Backend built on top of the cairo backend for rendering in wxWidgets (via WxHaskell).

Bitrotted/abandoned/superseded backends

LaTeX/TikZ

HTML5 canvas

  • github repo
  • Status: dormant
  • Participants: Jan Bracker, Andy Gill, Brent Yorgey

Related packages and tools

command-line/interactive

See also an earlier project in a similar direction:

Writing

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

See the reverse dependencies of diagrams-lib.

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