Difference between revisions of "Diagrams"
Jump to navigation
Jump to search
| Line 13: | Line 13: | ||
* low-level graphical primitives (rectangles, polygons, paths, etc) |
* 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 |
** 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 |
||
| + | ** boolean combination of paths |
||
| − | * |
+ | * input/output backends |
| + | ** pure Haskell SVG loader |
||
** interactive painting via Cairo |
** interactive painting via Cairo |
||
** pure Haskell PDF conversion via HPDF |
** pure Haskell PDF conversion via HPDF |
||
Revision as of 11:32, 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
- 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.