Difference between revisions of "Diagrams"
Jump to navigation
Jump to search
| Line 9: | Line 9: | ||
Many Haskell graphic libraries are tied to a specific rendering backend (Cairo, OpenGL, libGD etc) which makes collaboration and reuse of code and data strcutreus 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 strcutreus very hard or impossible. |
||
| − | + | A rewrite of diagrams should include separate packages for: |
|
** high-level code (constraint solving) |
** high-level code (constraint solving) |
||
** low-level graphical primitives (rectangles, polygons, paths, etc) |
** low-level graphical primitives (rectangles, polygons, paths, etc) |
||
Revision as of 11:31, 23 October 2009
The diagrams library provides an embedded domain-specific language (EDSL) for creating simple pictures and diagrams in Haskell
Ideas for the rewrite
Many Haskell graphic libraries are tied to a specific rendering backend (Cairo, OpenGL, libGD etc) which makes collaboration and reuse of code and data strcutreus very hard or impossible.
A rewrite of diagrams should include separate packages for:
- high-level code (constraint solving)
- low-level graphical primitives (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 use a primitive like a rectangle as a polygon or a rectangle
- conversion backends
- interactive painting via Cairo
- pure Haskell PDF conversion via HPDF
- pure Haskell PNG conversion via ???
- etc.