Difference between revisions of "Diagrams"

From HaskellWiki
Jump to navigation Jump to search
m
Line 6: Line 6:
   
   
== Ideas for the rewrite ==
+
== Rerwite ==
  +
  +
=== Inspiration ===
  +
  +
* [http://asymptote.sourceforge.net/ Asymptote]
  +
* [http://www.tug.org/metapost.html MetaPost]
  +
* [http://www.texample.net/tikz/examples/ TikZ]
  +
  +
=== Ideas ===
   
 
Many Haskell graphic libraries are tied to a specific rendering backend (Cairo, OpenGL, libGD etc) which makes collaboration and reuse of code and data structures very hard or impossible.
 
Many Haskell graphic libraries are tied to a specific rendering backend (Cairo, OpenGL, libGD etc) which makes collaboration and reuse of code and data structures very hard or impossible.

Revision as of 11:40, 23 October 2009

The diagrams library provides an embedded domain-specific language (EDSL) for creating simple pictures and diagrams in Haskell


Rerwite

Inspiration

Ideas

Many Haskell graphic libraries are tied to a specific rendering backend (Cairo, OpenGL, libGD etc) which makes collaboration and reuse of code and data structures very hard or impossible.

Also some dependencies are hard to fulfill. Cairo is very difficult to install on Mac OS 10.6. If you just need to generate PDF diagrams, you could choose the pure HPDF library where e.g. Hieroglyph can not be installed because of its Cairo dependence.

A rewrite of diagrams should include separate packages for:

  • high-level code (constraint solving)
  • low-level graphical primitives (fill, stroke, gradients, rectangles, polygons, paths, etc)
    • imho there should be primitive shape typeclass like circles and rectangles having a "convertToPath" function. Backends like SVG can then choose to convert shapes like a rectangle to a polygon or to a SVG rectangle
    • boolean combination of paths
  • input/output backends
    • pure Haskell SVG loader
    • interactive painting via Cairo
    • pure Haskell PDF conversion via HPDF
    • pure Haskell PNG conversion via ???
    • etc.