https://wiki.haskell.org/api.php?action=feedcontributions&user=JRosenbluth&feedformat=atomHaskellWiki - User contributions [en]2021-12-01T04:55:51ZUser contributionsMediaWiki 1.27.4https://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59706Diagrams/Dev/Migrate1.32015-05-01T01:06:11Z<p>JRosenbluth: /* diagrams-svg */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.3 API.<br />
<br />
The 1.3 release includes a lot of new features and reorganization; there are surely to be breaking changes that we missed below. Please ask on the diagrams mailing list or IRC channel for help migrating to 1.3, and feel free to edit this page with additional information or better explanations as you upgrade.<br />
<br />
== Linear ==<br />
<br />
Diagrams has switched from <code>vector-space</code> to <code>linear</code> for its linear algebra package. This makes many things nicer, and in particular allows diagrams to now be polymorphic over the underlying numeric type, potentially paving the way for things like automatic differentiation. It does, however, mean that many types are now slightly different.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 (P2) -&gt; Point V2 Double (P2 Double)</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>Transformation R2 -&gt; Transformation V2 Double (T2 Double)</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. It no longer takes a vector space as a parameter; it simply uses the default space and number type for the backend parameter:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>. This means you should replace e.g.<br />
<br />
* <code>Diagram Cairo R2 -&gt; Diagram Cairo</code><br />
<br />
<code>Scalar</code> also no longer exists; you should replace<br />
<br />
* <code>Scalar -&gt; N</code><br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
Other changes from <code>vector-space</code> to <code>linear</code>:<br />
<br />
* <code>magnitude</code> -&gt; <code>norm</code><br />
* <code>magnitudeSq</code> -&gt; <code>quadrance</code><br />
* <code>negateV</code> -&gt; <code>negated</code><br />
* <code>normalized</code> -&gt; <code>signorm</code><br />
<br />
The last is particularly worth noting, since there is also a new <code>normalized</code> function (which constructs <code>Measure</code> values). So code which used <code>normalized</code>, instead of yielding a "not in scope" error, will yield a type error, probably something along the lines of<br />
<br />
<code>Couldn't match type ‘Measured n0 n0’ with ‘V2 Double’</code><br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>, but these have lenses of the same names (<code>_x</code>, <code>_y</code>, <code>_z</code>) so you probably won't notice the difference.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions including <code>arc</code> and <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions. For example, if you had<br />
<br />
<code>arc (0 @@ turn) (1/3 @@ turn)</code><br />
<br />
you should replace it by<br />
<br />
<code>arc xDir (1/3 @@ turn)</code><br />
<br />
As another example,<br />
<br />
<code>arc (1/3 @@ turn) (2/3 @@ turn)</code><br />
<br />
can be replaced by<br />
<br />
<code>arc (angleDir (1/3 @@ turn)) (1/3 @@ turn)</code><br />
<br />
<code>angleBetween</code> is commutative (and always positive). We also introduced <code>signedAngleBetween</code> which reflects a (counterclockwise) ordering on angles.<br />
<br />
<code>rotateAbout</code> used to rotate about a point in 2D; it now rotates about a line in 3D. The old <code>rotateAbout</code> has been replaced by <code>rotateAround</code>.<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructors cannot be used anymore. Instead they have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
<code>mkSizeSpec</code> used to be specific to 2D; it is now generic over any vector space. Use <code>mkSizeSpec2D</code> instead.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lens's snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity errors for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
[https://github.com/diagrams/diagrams-svg diagrams-svg] no longer depends on the [http://hackage.haskell.org/package/blaze-svg blaze.svg] package and instead uses [http://hackage.haskell.org/package/lucid-svg lucid-svg].<br />
<br />
The only difference that should affect diagrams code is that the<br />
<code>SVGOptions</code> record has changed from:<br />
<br />
<code><br />
SVGOptions {_size :: SizeSpec2D, _svgDefinitions :: Maybe S.Svg}<br />
</code><br />
<br />
to:<br />
<br />
<code><br />
SVGOptions { _size :: SizeSpec V2 n, _svgDefinitions :: Maybe SvgM, _idPrefix :: T.Text}<br />
</code>.<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.LinearMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
=== HTML5 backend ===<br />
<br />
The [https://github.com/diagrams/diagrams-html5 <code>diagrams-html5</code>] backend supports most of diagrams’ features including paths, external images , gradients and text. It produces standalone javascript code.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>] and have all of the functions you need.<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write:<br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you would write: <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> were hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59606Diagrams/Dev/Migrate1.32015-04-02T01:27:18Z<p>JRosenbluth: /* diagrams-svg */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
[https://github.com/diagrams/diagrams-svg diagrams-svg] no longer depends on the [http://hackage.haskell.org/package/blaze-svg blaze.svg] package and instead uses [http://hackage.haskell.org/package/lucid-svg lucid-svg].<br />
<br />
The only difference that should affect diagrams code is that the<br />
<code>SVGOptions</code> record has changed from:<br />
<br />
<code><br />
SVGOptions {_size :: SizeSpec2D, _svgDefinitions :: Maybe S.Svg}<br />
</code><br />
<br />
to:<br />
<br />
<code><br />
SVGOptions { _size :: SizeSpec V2 n, _svgDefinitions :: [Attribute], _idPrefix :: T.Text}<br />
</code>.<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
=== HTML5 backend ===<br />
<br />
The [https://github.com/diagrams/diagrams-html5 <code>diagrams-html5</code>] backend supports most of diagrams’ features including paths, external images , gradients and text. It produces standalone javascript code.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>] and have all of the functions you need.<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write:<br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you would write: <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59605Diagrams/Dev/Migrate1.32015-04-02T01:27:02Z<p>JRosenbluth: /* diagrams-svg */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
[https://github.com/diagrams/diagrams-svg diagrams-svg] no longer depends on the [http://hackage.haskell.org/package/blaze-svg blaze.svg] package and instead uses [http://hackage.haskell.org/package/lucid-svg lucid-svg].<br />
<br />
The only difference that should affect diagrams code is that the<br />
<code>SVGOptions</code> record has changed from <br />
<code><br />
SVGOptions {_size :: SizeSpec2D, _svgDefinitions :: Maybe S.Svg}<br />
</code><br />
<br />
to<br />
<br />
<code><br />
SVGOptions { _size :: SizeSpec V2 n, _svgDefinitions :: [Attribute], _idPrefix :: T.Text}<br />
</code>.<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
=== HTML5 backend ===<br />
<br />
The [https://github.com/diagrams/diagrams-html5 <code>diagrams-html5</code>] backend supports most of diagrams’ features including paths, external images , gradients and text. It produces standalone javascript code.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>] and have all of the functions you need.<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write:<br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you would write: <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59604Diagrams/Dev/Migrate1.32015-04-02T01:26:39Z<p>JRosenbluth: /* diagrams-svg */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
[https://github.com/diagrams/diagrams-svg diagrams-svg] no longer depends on the [http://hackage.haskell.org/package/blaze-svg blaze.svg] package and instead uses [http://hackage.haskell.org/package/lucid-svg lucid-svg].<br />
<br />
The only difference that should effect diagrams code is that the<br />
<code>SVGOptions</code> record has changed from <br />
<code><br />
SVGOptions {_size :: SizeSpec2D, _svgDefinitions :: Maybe S.Svg}<br />
</code><br />
<br />
to<br />
<br />
<code><br />
SVGOptions { _size :: SizeSpec V2 n, _svgDefinitions :: [Attribute], _idPrefix :: T.Text}<br />
</code>.<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
=== HTML5 backend ===<br />
<br />
The [https://github.com/diagrams/diagrams-html5 <code>diagrams-html5</code>] backend supports most of diagrams’ features including paths, external images , gradients and text. It produces standalone javascript code.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>] and have all of the functions you need.<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write:<br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you would write: <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59603Diagrams/Dev/Migrate1.32015-04-02T01:25:17Z<p>JRosenbluth: /* diagrams-svg */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
[https://github.com/diagrams/diagrams-svg diagrams-svg] no longer depends on Blaze.Svg11 and instead uses lucid-svg.<br />
<br />
The only difference that should effect diagrams code is that the<br />
<code>SVGOptions</code> record has changed from <br />
<code><br />
SVGOptions {_size :: SizeSpec2D, _svgDefinitions :: Maybe S.Svg}<br />
</code><br />
<br />
to<br />
<br />
<code><br />
SVGOptions { _size :: SizeSpec V2 n, _svgDefinitions :: [Attribute], _idPrefix :: T.Text}<br />
</code>.<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
=== HTML5 backend ===<br />
<br />
The [https://github.com/diagrams/diagrams-html5 <code>diagrams-html5</code>] backend supports most of diagrams’ features including paths, external images , gradients and text. It produces standalone javascript code.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>] and have all of the functions you need.<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write:<br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you would write: <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59602Diagrams/Dev/Migrate1.32015-04-02T01:24:12Z<p>JRosenbluth: /* diagrams-svg */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
diagrams-svg no longer depends on Blaze.Svg11 and instead uses lucid-svg.<br />
<br />
The only difference that should effect diagrams code is that the<br />
<code>SVGOptions</code> record has changed from <br />
<code><br />
SVGOptions {_size :: SizeSpec2D, _svgDefinitions :: Maybe S.Svg}<br />
</code><br />
to<br />
<code><br />
SVGOptions { _size :: SizeSpec V2 n, _svgDefinitions :: [Attribute], _idPrefix :: T.Text}<br />
</code>.<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
=== HTML5 backend ===<br />
<br />
The [https://github.com/diagrams/diagrams-html5 <code>diagrams-html5</code>] backend supports most of diagrams’ features including paths, external images , gradients and text. It produces standalone javascript code.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>] and have all of the functions you need.<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write:<br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you would write: <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59601Diagrams/Dev/Migrate1.32015-04-02T01:15:01Z<p>JRosenbluth: /* New Backends */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
=== HTML5 backend ===<br />
<br />
The [https://github.com/diagrams/diagrams-html5 <code>diagrams-html5</code>] backend supports most of diagrams’ features including paths, external images , gradients and text. It produces standalone javascript code.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>] and have all of the functions you need.<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write:<br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you would write: <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59600Diagrams/Dev/Migrate1.32015-04-02T01:10:39Z<p>JRosenbluth: /* SVGFonts */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>] and have all of the functions you need.<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write:<br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you would write: <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59599Diagrams/Dev/Migrate1.32015-04-02T01:10:01Z<p>JRosenbluth: /* SVGFonts */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>].<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write:<br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you would write: <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59598Diagrams/Dev/Migrate1.32015-04-02T01:09:31Z<p>JRosenbluth: /* SVGFonts */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>].<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write <br />
<br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
<br />
now you write <br />
<br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59597Diagrams/Dev/Migrate1.32015-04-02T01:09:11Z<p>JRosenbluth: /* SVGFonts */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>].<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from <code>TextOptions</code>. So whereas before you might write <br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
now you write <br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59596Diagrams/Dev/Migrate1.32015-04-02T01:08:43Z<p>JRosenbluth: /* SVGFonts */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import [http://hackage.haskell.org/package/SVGFonts-1.4.0.3/docs/Graphics-SVGFonts.html <code>Graphics.SVGFonts</code>].<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from `<code>extOptions</code>. So whereas before you might write <br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
now you write <br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59595Diagrams/Dev/Migrate1.32015-04-02T01:06:51Z<p>JRosenbluth: /* SVGFonts */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams <code>textSVG'</code> and <code>testSVG_</code> have been move out of the <code>ReadFont</code> module into the <code>Text</code> module. You can usually just import <code>Graphics.SVGFonts</code>.<br />
<br />
<code>textSVG'</code> and friends now have the text as a separate argument, distinct from `<code>extOptions</code>. So whereas before you might write <br />
<code>textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)</code> <br />
now you write <br />
<code>textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s</code>.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59594Diagrams/Dev/Migrate1.32015-04-02T01:03:51Z<p>JRosenbluth: /* SVGFonts */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims2D</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>dims2D</code>, <code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== Transform isomorphisms ==<br />
<br />
New transform isomorphisms <code>transformed</code>, <code>translated</code>, <code>movedTo</code>, <code>movedFrom</code> and <code>rotated</code> have been added. These can be used with lens’s <code>under</code> function (see <code>Diagrams.Transform</code> for usage examples). The old <code>under</code> has been renamed to <code>underT</code>.<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
=== PGF backend ===<br />
<br />
[https://www.ctan.org/pkg/pgf?lang=en PGF] is tex a macro package for creating graphics. It’s the low level backend for TikZ.<br />
<br />
The [https://github.com/diagrams/diagrams-pgf <code>diagrams-pgf</code>] backend supports most of diagrams’ features including paths, images (external and embedded), gradients (partial support) and text. It also includes an experimental functions for retrieving the size of the bounding boxes for text (including formulas). See the [https://github.com/diagrams/diagrams-pgf/tree/master/examples examples page] for more details.<br />
<br />
It uses [https://github.com/cchalmers/texrunner <code>texrunner</code>] to produce PDF files and parse tex’s output. Latex, Context and plain Tex outputs are supported.<br />
<br />
== SVGFonts ==<br />
<br />
The most important functions for use in diagrams 9`textSVG'` and `testSVG_` have been move out of the `ReadFont` module into the `Text` module. You can usually just import `Graphics.SVGFonts`.<br />
<br />
`textSVG'` and friends now have the text as a separate argument, distinct from `TextOptions`. So whereas before you might write `textSVG' (TextOpts s lin2 INSIDE_H KERN False d d)` now you write `textSVG' (TextOpts lin2 INSIDE_H KERN False d d) s`.<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Projects&diff=59593Diagrams/Projects2015-04-02T00:51:55Z<p>JRosenbluth: /* Canvas */</p>
<hr />
<div>==Potential projects==<br />
<br />
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].<br />
<br />
=== ggplot ===<br />
<br />
Implementing a "grammar of graphics" should be something at which Haskell excels.<br />
<br />
See<br />
<br />
* http://ggplot2.org<br />
* http://www.cs.uic.edu/~wilkinson/TheGrammarOfGraphics/GOG.html<br />
<br />
=== Port cool examples to diagrams ===<br />
<br />
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?) <br />
<br />
Some possible sources of inspiration:<br />
* http://web.williams.edu/Mathematics/devadoss/papers.html<br />
* http://www.bridgesmathart.org/<br />
* http://recodeproject.com/<br />
* [http://www.joachim-breitner.de/blog/archives/557-A-copying-garbage-collector-animated.html Joachim Breitner's animation of a copying garbage collector]<br />
* [http://www.numbersimulation.com/ Cool animation demonstrating the concept of prime numbers with orbiting segments for each natural]<br />
* [http://youtu.be/ug9fhgy9N60 animation of creating a dragon curve fractal by cutting and sliding blocks]<br />
* [http://www.mathcurve.com/fractals/gosper/gosper.shtml Gosper fractal, aka flowsnake]<br />
* [http://beesandbombs.tumblr.com/ Bees and Bombs]<br />
* [https://upload.wikimedia.org/wikipedia/commons/4/4e/Circle_radians.gif Visual explanation of radians]<br />
<br />
=== Include animations in the gallery and user manual ===<br />
<br />
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 .<br />
<br />
=== Visualization suite for the Haskell ecosystem ===<br />
<br />
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:<br />
<br />
* cabal build plans (especially failures)<br />
* APIs and API diffs<br />
* algebraic data types<br />
* memory layout/usage of data structures<br />
* graph reduction/lazy evaluation<br />
* types<br />
* maps, folds, filters, zips, etc.<br />
* zippers<br />
* Functor/Applicative/Monad operations/types<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== GUI application for creating diagrams interactively ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
* the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file<br />
* 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)<br />
* 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<br />
* Support for developing animations (e.g. with a slider for moving back+forth in time)<br />
<br />
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.<br />
<br />
=== Path operations ===<br />
<br />
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.<br />
<br />
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!).<br />
<br />
For more ideas see http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html.<br />
<br />
=== Constraint Based Diagrams ===<br />
<br />
Generate diagrams that meet some declarative constraint specification---perhaps something<br />
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.<br />
<br />
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). See also https://groups.google.com/d/msg/diagrams-discuss/WBbhB4RXnck/ekSJOnHdBw8J .<br />
<br />
=== Search for Interesting Diagrams ===<br />
<br />
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.<br />
<br />
=== External Rendering ===<br />
<br />
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.<br />
<br />
=== Variable Precision ===<br />
<br />
It would be nice to be able to trade off precision of the vector output of some<br />
backend with the size of that output. For instance the factorization diagrams<br />
are rather large when rendered to SVG, but their size could be cut in half by<br />
emitting doubles formatted to two significant digits. There is a nice balance<br />
that could be struck at a high level where we ensure that we are always within<br />
some fraction of what will likely be a pixel in the final output. Then at the<br />
level of the backend we would only need to choose the representation that is<br />
the smallest for any particular number.<br />
<br />
This could be aided by [https://github.com/diagrams/diagrams-lib/issues/50#issuecomment-23940308 generalized R2].<br />
<br />
=== Auto-generated "simple" prelude ===<br />
<br />
The diagrams library is extremely polymorphic---much too polymorphic<br />
for beginning users, perhaps. The goal of this project would be to<br />
write some code to automatically generate a module<br />
Diagrams.Prelude.Simple which re-exports things from Diagrams.Prelude<br />
but with more monomorphic types. This would require obtaining the<br />
types of things exported by Diagrams.Prelude, doing some analysis to<br />
determine what "simpler" type to use, then outputting the appropriate<br />
code. There are some interesting, nontrivial questions to be worked<br />
out in terms of how to generate a "simple" type from a more general<br />
one. There may even be room for multiple "levels" with successively<br />
more polymorphism.<br />
<br />
=== Contrib module for graph drawing ===<br />
<br />
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.<br />
<br />
=== Do a better job combining envelopes ===<br />
<br />
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.<br />
<br />
=== Convert SVG files to diagrams ===<br />
<br />
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. Note: This is possible now (although not finished). See https://github.com/diagrams/svg-diagrams<br />
<br />
=== Auto-generate "connect the dots" puzzles ===<br />
<br />
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.<br />
<br />
=== DSL for identifying subdiagrams ===<br />
<br />
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.<br />
<br />
=== Port potrace to Haskell ===<br />
<br />
See http://potrace.sourceforge.net/ and in particular http://potrace.sourceforge.net/potrace.pdf .<br />
<br />
=== General curved surfaces in 3D ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Officially supported backends==<br />
<br />
=== Native SVG ===<br />
<br />
A Haskell-native backend generating SVG. As of diagrams-0.6 this is the default "out-of-the-box" diagrams backend.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dsvg hackage]<br />
* [https://github.com/diagrams/diagrams-svg github repo]<br />
* Status: active development<br />
<br />
=== Rasterific ===<br />
<br />
A Haskell-native backend generating raster graphics, using the [http://hackage.haskell.org/package/Rasterific Rasterific] package.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-rasterific hackage]<br />
* [https://github.com/diagrams/diagrams-rasterific github repo]<br />
* Status: active development<br />
<br />
=== Cairo ===<br />
<br />
Full-featured backend using [http://www.cairographics.org/ cairo]. <br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dcairo hackage]<br />
* [http://github.com/diagrams/diagrams-cairo github repo]<br />
* Status: active development<br />
* Participants: Brent Yorgey, Ryan Yates<br />
<br />
=== GTK ===<br />
<br />
Backend built on top of the cairo backend for rendering directly to GTK windows.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dgtk hackage]<br />
* [http://github.com/diagrams/diagrams-gtk github repo]<br />
* Status: active development<br />
* Participants: John Lato, Brent Yorgey<br />
<br />
=== Postscript ===<br />
<br />
Very similar to the Cairo backend but only outputting EPS.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dpostscript hackage]<br />
* [https://github.com/diagrams/diagrams-postscript github repo]<br />
* Status: active development<br />
* Participants: Ryan Yates<br />
<br />
=== PGF ===<br />
<br />
A backend emitting PGF/TikZ TeX code.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-pgf hackage]<br />
* [https://github.com/diagrams/diagrams-pgf github repo]<br />
* Status: active development<br />
* Participants: Chris Chalmers<br />
<br />
=== Canvas ===<br />
<br />
An interactive backend drawing on an HTML5 canvas.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-canvas hackage]<br />
* [https://github.com/diagrams/diagrams-canvas github repo]<br />
* Status: active development<br />
* Participants: Jeff Rosenbluth, Andy Gill<br />
<br />
=== HTML5 ===<br />
<br />
A backend emitting javascript HTML5 canvas output.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-html5 hackage]<br />
* [https://github.com/diagrams/diagrams-html5 github repo]<br />
* Status: active development<br />
* Participants: Jeff Rosenbluth<br />
<br />
== Unofficial backends ==<br />
<br />
=== PDF ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams-pdf Hackage]<br />
* [https://github.com/alpheccar/diagrams-pdf github repo]<br />
* Status: dormant<br />
* Participants: Christophe F<br />
<br />
=== GHCJS/canvas ===<br />
<br />
* [https://github.com/ghcjs/diagrams-ghcjs github repo]<br />
* Status: active development<br />
* Participants: Daniil Frumin, Luite Stegeman, Daniel Bergey<br />
<br />
=== OpenGL ===<br />
<br />
* [https://github.com/bergey/diagrams-opengl github repo]<br />
* Status: dormant<br />
* Participants: Daniel Bergey<br />
<br />
=== POV-Ray ===<br />
<br />
A [http://www.povray.org/ POV-Ray backend] for 3D diagrams.<br />
<br />
* [http://github.com/diagrams/diagrams-povray github repo]<br />
* Status: Alpha, active development<br />
* Participants: Daniel Bergey<br />
<br />
=== HsQML ===<br />
<br />
A backend for painting on a QtQuick Canvas.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dhsqml Hackage]<br />
* [https://github.com/marcinmrotek/diagrams-hsqml github repo]<br />
* Status: active<br />
* Participants: Marcin Mrotek<br />
<br />
== Bitrotted/abandoned/superseded backends ==<br />
<br />
=== LaTeX/TikZ ===<br />
<br />
* original [http://patch-tag.com/r/snwalck/diagrams-tikz darcs repo] by Scott Walck<br />
* [https://github.com/mahrz/diagrams-tikz updated version] by Malte Harder on github<br />
* Yet another version is [http://hackage.haskell.org/package/diagrams%2Dtikz on Hackage]<br />
* Status: dormant<br />
* Participants: Scott Walck, Malte Harder<br />
<br />
=== HTML5 canvas ===<br />
<br />
* [https://github.com/jbracker/diagrams-sunroof github repo]<br />
* Status: dormant<br />
* Participants: Jan Bracker, Andy Gill, Brent Yorgey<br />
<br />
== Related packages and tools ==<br />
<br />
=== command-line/interactive ===<br />
<br />
* [https://github.com/mgsloan/diagrams-ghci diagrams-ghci]<br />
<br />
See also an earlier project in a similar direction:<br />
<br />
* [http://patch-tag.com/r/fryguybob/diagrams-hint diagrams-hint]<br />
<br />
=== Writing ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dhaddock diagrams-haddock] is a tool for embedding diagrams in Haddock documentation.<br />
* [http://hackage.haskell.org/package/BlogLiterately%2Ddiagrams BlogLiterately-diagrams] is a tool for embedding diagrams in blog posts.<br />
<br />
=== Build service ===<br />
<br />
[http://github.com/diagrams/diagrams-builder/ 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).<br />
<br />
=== Fonts ===<br />
<br />
The [http://hackage.haskell.org/package/SVGFonts SVGFonts] package implements Haskell-native font support (for fonts in the SVG-font format) that can be plugged into diagrams.<br />
<br />
== Other projects ==<br />
<br />
=== gtk-toy ===<br />
<br />
Michael Sloan's [https://github.com/mgsloan/gtk-toy gtk-toy project] is a framework for creating interactive gtk/cairo applications. [https://github.com/mgsloan/gtk-toy-diagrams gtk-toy-diagrams] provides tools for using diagrams in conjunction with gtk-toy.<br />
<br />
=== LaTeXgrapher ===<br />
<br />
[http://patch-tag.com/r/fryguybob/LaTeXGrapher LaTeXGrapher] is a project by Ryan Yates providing a domain-specific language for producing mathematical graphs, backed by the diagrams-postscript backend.<br />
<br />
=== hs-logo ===<br />
<br />
Deepak Jois is working on a [https://github.com/deepakjois/hs-logo logo interpreter] written in Haskell, using diagrams as a backend.<br />
<br />
== Packages using diagrams ==<br />
<br />
See the [http://packdeps.haskellers.com/reverse/diagrams-lib reverse dependencies of diagrams-lib].</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Projects&diff=59592Diagrams/Projects2015-04-02T00:51:19Z<p>JRosenbluth: /* HTML5 */</p>
<hr />
<div>==Potential projects==<br />
<br />
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].<br />
<br />
=== ggplot ===<br />
<br />
Implementing a "grammar of graphics" should be something at which Haskell excels.<br />
<br />
See<br />
<br />
* http://ggplot2.org<br />
* http://www.cs.uic.edu/~wilkinson/TheGrammarOfGraphics/GOG.html<br />
<br />
=== Port cool examples to diagrams ===<br />
<br />
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?) <br />
<br />
Some possible sources of inspiration:<br />
* http://web.williams.edu/Mathematics/devadoss/papers.html<br />
* http://www.bridgesmathart.org/<br />
* http://recodeproject.com/<br />
* [http://www.joachim-breitner.de/blog/archives/557-A-copying-garbage-collector-animated.html Joachim Breitner's animation of a copying garbage collector]<br />
* [http://www.numbersimulation.com/ Cool animation demonstrating the concept of prime numbers with orbiting segments for each natural]<br />
* [http://youtu.be/ug9fhgy9N60 animation of creating a dragon curve fractal by cutting and sliding blocks]<br />
* [http://www.mathcurve.com/fractals/gosper/gosper.shtml Gosper fractal, aka flowsnake]<br />
* [http://beesandbombs.tumblr.com/ Bees and Bombs]<br />
* [https://upload.wikimedia.org/wikipedia/commons/4/4e/Circle_radians.gif Visual explanation of radians]<br />
<br />
=== Include animations in the gallery and user manual ===<br />
<br />
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 .<br />
<br />
=== Visualization suite for the Haskell ecosystem ===<br />
<br />
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:<br />
<br />
* cabal build plans (especially failures)<br />
* APIs and API diffs<br />
* algebraic data types<br />
* memory layout/usage of data structures<br />
* graph reduction/lazy evaluation<br />
* types<br />
* maps, folds, filters, zips, etc.<br />
* zippers<br />
* Functor/Applicative/Monad operations/types<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== GUI application for creating diagrams interactively ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
* the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file<br />
* 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)<br />
* 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<br />
* Support for developing animations (e.g. with a slider for moving back+forth in time)<br />
<br />
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.<br />
<br />
=== Path operations ===<br />
<br />
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.<br />
<br />
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!).<br />
<br />
For more ideas see http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html.<br />
<br />
=== Constraint Based Diagrams ===<br />
<br />
Generate diagrams that meet some declarative constraint specification---perhaps something<br />
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.<br />
<br />
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). See also https://groups.google.com/d/msg/diagrams-discuss/WBbhB4RXnck/ekSJOnHdBw8J .<br />
<br />
=== Search for Interesting Diagrams ===<br />
<br />
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.<br />
<br />
=== External Rendering ===<br />
<br />
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.<br />
<br />
=== Variable Precision ===<br />
<br />
It would be nice to be able to trade off precision of the vector output of some<br />
backend with the size of that output. For instance the factorization diagrams<br />
are rather large when rendered to SVG, but their size could be cut in half by<br />
emitting doubles formatted to two significant digits. There is a nice balance<br />
that could be struck at a high level where we ensure that we are always within<br />
some fraction of what will likely be a pixel in the final output. Then at the<br />
level of the backend we would only need to choose the representation that is<br />
the smallest for any particular number.<br />
<br />
This could be aided by [https://github.com/diagrams/diagrams-lib/issues/50#issuecomment-23940308 generalized R2].<br />
<br />
=== Auto-generated "simple" prelude ===<br />
<br />
The diagrams library is extremely polymorphic---much too polymorphic<br />
for beginning users, perhaps. The goal of this project would be to<br />
write some code to automatically generate a module<br />
Diagrams.Prelude.Simple which re-exports things from Diagrams.Prelude<br />
but with more monomorphic types. This would require obtaining the<br />
types of things exported by Diagrams.Prelude, doing some analysis to<br />
determine what "simpler" type to use, then outputting the appropriate<br />
code. There are some interesting, nontrivial questions to be worked<br />
out in terms of how to generate a "simple" type from a more general<br />
one. There may even be room for multiple "levels" with successively<br />
more polymorphism.<br />
<br />
=== Contrib module for graph drawing ===<br />
<br />
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.<br />
<br />
=== Do a better job combining envelopes ===<br />
<br />
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.<br />
<br />
=== Convert SVG files to diagrams ===<br />
<br />
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. Note: This is possible now (although not finished). See https://github.com/diagrams/svg-diagrams<br />
<br />
=== Auto-generate "connect the dots" puzzles ===<br />
<br />
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.<br />
<br />
=== DSL for identifying subdiagrams ===<br />
<br />
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.<br />
<br />
=== Port potrace to Haskell ===<br />
<br />
See http://potrace.sourceforge.net/ and in particular http://potrace.sourceforge.net/potrace.pdf .<br />
<br />
=== General curved surfaces in 3D ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Officially supported backends==<br />
<br />
=== Native SVG ===<br />
<br />
A Haskell-native backend generating SVG. As of diagrams-0.6 this is the default "out-of-the-box" diagrams backend.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dsvg hackage]<br />
* [https://github.com/diagrams/diagrams-svg github repo]<br />
* Status: active development<br />
<br />
=== Rasterific ===<br />
<br />
A Haskell-native backend generating raster graphics, using the [http://hackage.haskell.org/package/Rasterific Rasterific] package.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-rasterific hackage]<br />
* [https://github.com/diagrams/diagrams-rasterific github repo]<br />
* Status: active development<br />
<br />
=== Cairo ===<br />
<br />
Full-featured backend using [http://www.cairographics.org/ cairo]. <br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dcairo hackage]<br />
* [http://github.com/diagrams/diagrams-cairo github repo]<br />
* Status: active development<br />
* Participants: Brent Yorgey, Ryan Yates<br />
<br />
=== GTK ===<br />
<br />
Backend built on top of the cairo backend for rendering directly to GTK windows.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dgtk hackage]<br />
* [http://github.com/diagrams/diagrams-gtk github repo]<br />
* Status: active development<br />
* Participants: John Lato, Brent Yorgey<br />
<br />
=== Postscript ===<br />
<br />
Very similar to the Cairo backend but only outputting EPS.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dpostscript hackage]<br />
* [https://github.com/diagrams/diagrams-postscript github repo]<br />
* Status: active development<br />
* Participants: Ryan Yates<br />
<br />
=== PGF ===<br />
<br />
A backend emitting PGF/TikZ TeX code.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-pgf hackage]<br />
* [https://github.com/diagrams/diagrams-pgf github repo]<br />
* Status: active development<br />
* Participants: Chris Chalmers<br />
<br />
=== Canvas ===<br />
<br />
A backend drawing on an HTML5 canvas.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-canvas hackage]<br />
* [https://github.com/diagrams/diagrams-canvas github repo]<br />
* Status: active development<br />
* Participants: Jeff Rosenbluth, Andy Gill<br />
<br />
=== HTML5 ===<br />
<br />
A backend emitting javascript HTML5 canvas output.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-html5 hackage]<br />
* [https://github.com/diagrams/diagrams-html5 github repo]<br />
* Status: active development<br />
* Participants: Jeff Rosenbluth<br />
<br />
== Unofficial backends ==<br />
<br />
=== PDF ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams-pdf Hackage]<br />
* [https://github.com/alpheccar/diagrams-pdf github repo]<br />
* Status: dormant<br />
* Participants: Christophe F<br />
<br />
=== GHCJS/canvas ===<br />
<br />
* [https://github.com/ghcjs/diagrams-ghcjs github repo]<br />
* Status: active development<br />
* Participants: Daniil Frumin, Luite Stegeman, Daniel Bergey<br />
<br />
=== OpenGL ===<br />
<br />
* [https://github.com/bergey/diagrams-opengl github repo]<br />
* Status: dormant<br />
* Participants: Daniel Bergey<br />
<br />
=== POV-Ray ===<br />
<br />
A [http://www.povray.org/ POV-Ray backend] for 3D diagrams.<br />
<br />
* [http://github.com/diagrams/diagrams-povray github repo]<br />
* Status: Alpha, active development<br />
* Participants: Daniel Bergey<br />
<br />
=== HsQML ===<br />
<br />
A backend for painting on a QtQuick Canvas.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dhsqml Hackage]<br />
* [https://github.com/marcinmrotek/diagrams-hsqml github repo]<br />
* Status: active<br />
* Participants: Marcin Mrotek<br />
<br />
== Bitrotted/abandoned/superseded backends ==<br />
<br />
=== LaTeX/TikZ ===<br />
<br />
* original [http://patch-tag.com/r/snwalck/diagrams-tikz darcs repo] by Scott Walck<br />
* [https://github.com/mahrz/diagrams-tikz updated version] by Malte Harder on github<br />
* Yet another version is [http://hackage.haskell.org/package/diagrams%2Dtikz on Hackage]<br />
* Status: dormant<br />
* Participants: Scott Walck, Malte Harder<br />
<br />
=== HTML5 canvas ===<br />
<br />
* [https://github.com/jbracker/diagrams-sunroof github repo]<br />
* Status: dormant<br />
* Participants: Jan Bracker, Andy Gill, Brent Yorgey<br />
<br />
== Related packages and tools ==<br />
<br />
=== command-line/interactive ===<br />
<br />
* [https://github.com/mgsloan/diagrams-ghci diagrams-ghci]<br />
<br />
See also an earlier project in a similar direction:<br />
<br />
* [http://patch-tag.com/r/fryguybob/diagrams-hint diagrams-hint]<br />
<br />
=== Writing ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dhaddock diagrams-haddock] is a tool for embedding diagrams in Haddock documentation.<br />
* [http://hackage.haskell.org/package/BlogLiterately%2Ddiagrams BlogLiterately-diagrams] is a tool for embedding diagrams in blog posts.<br />
<br />
=== Build service ===<br />
<br />
[http://github.com/diagrams/diagrams-builder/ 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).<br />
<br />
=== Fonts ===<br />
<br />
The [http://hackage.haskell.org/package/SVGFonts SVGFonts] package implements Haskell-native font support (for fonts in the SVG-font format) that can be plugged into diagrams.<br />
<br />
== Other projects ==<br />
<br />
=== gtk-toy ===<br />
<br />
Michael Sloan's [https://github.com/mgsloan/gtk-toy gtk-toy project] is a framework for creating interactive gtk/cairo applications. [https://github.com/mgsloan/gtk-toy-diagrams gtk-toy-diagrams] provides tools for using diagrams in conjunction with gtk-toy.<br />
<br />
=== LaTeXgrapher ===<br />
<br />
[http://patch-tag.com/r/fryguybob/LaTeXGrapher LaTeXGrapher] is a project by Ryan Yates providing a domain-specific language for producing mathematical graphs, backed by the diagrams-postscript backend.<br />
<br />
=== hs-logo ===<br />
<br />
Deepak Jois is working on a [https://github.com/deepakjois/hs-logo logo interpreter] written in Haskell, using diagrams as a backend.<br />
<br />
== Packages using diagrams ==<br />
<br />
See the [http://packdeps.haskellers.com/reverse/diagrams-lib reverse dependencies of diagrams-lib].</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Projects&diff=59591Diagrams/Projects2015-04-02T00:50:43Z<p>JRosenbluth: /* Officially supported backends */</p>
<hr />
<div>==Potential projects==<br />
<br />
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].<br />
<br />
=== ggplot ===<br />
<br />
Implementing a "grammar of graphics" should be something at which Haskell excels.<br />
<br />
See<br />
<br />
* http://ggplot2.org<br />
* http://www.cs.uic.edu/~wilkinson/TheGrammarOfGraphics/GOG.html<br />
<br />
=== Port cool examples to diagrams ===<br />
<br />
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?) <br />
<br />
Some possible sources of inspiration:<br />
* http://web.williams.edu/Mathematics/devadoss/papers.html<br />
* http://www.bridgesmathart.org/<br />
* http://recodeproject.com/<br />
* [http://www.joachim-breitner.de/blog/archives/557-A-copying-garbage-collector-animated.html Joachim Breitner's animation of a copying garbage collector]<br />
* [http://www.numbersimulation.com/ Cool animation demonstrating the concept of prime numbers with orbiting segments for each natural]<br />
* [http://youtu.be/ug9fhgy9N60 animation of creating a dragon curve fractal by cutting and sliding blocks]<br />
* [http://www.mathcurve.com/fractals/gosper/gosper.shtml Gosper fractal, aka flowsnake]<br />
* [http://beesandbombs.tumblr.com/ Bees and Bombs]<br />
* [https://upload.wikimedia.org/wikipedia/commons/4/4e/Circle_radians.gif Visual explanation of radians]<br />
<br />
=== Include animations in the gallery and user manual ===<br />
<br />
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 .<br />
<br />
=== Visualization suite for the Haskell ecosystem ===<br />
<br />
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:<br />
<br />
* cabal build plans (especially failures)<br />
* APIs and API diffs<br />
* algebraic data types<br />
* memory layout/usage of data structures<br />
* graph reduction/lazy evaluation<br />
* types<br />
* maps, folds, filters, zips, etc.<br />
* zippers<br />
* Functor/Applicative/Monad operations/types<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== GUI application for creating diagrams interactively ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
* the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file<br />
* 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)<br />
* 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<br />
* Support for developing animations (e.g. with a slider for moving back+forth in time)<br />
<br />
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.<br />
<br />
=== Path operations ===<br />
<br />
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.<br />
<br />
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!).<br />
<br />
For more ideas see http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html.<br />
<br />
=== Constraint Based Diagrams ===<br />
<br />
Generate diagrams that meet some declarative constraint specification---perhaps something<br />
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.<br />
<br />
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). See also https://groups.google.com/d/msg/diagrams-discuss/WBbhB4RXnck/ekSJOnHdBw8J .<br />
<br />
=== Search for Interesting Diagrams ===<br />
<br />
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.<br />
<br />
=== External Rendering ===<br />
<br />
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.<br />
<br />
=== Variable Precision ===<br />
<br />
It would be nice to be able to trade off precision of the vector output of some<br />
backend with the size of that output. For instance the factorization diagrams<br />
are rather large when rendered to SVG, but their size could be cut in half by<br />
emitting doubles formatted to two significant digits. There is a nice balance<br />
that could be struck at a high level where we ensure that we are always within<br />
some fraction of what will likely be a pixel in the final output. Then at the<br />
level of the backend we would only need to choose the representation that is<br />
the smallest for any particular number.<br />
<br />
This could be aided by [https://github.com/diagrams/diagrams-lib/issues/50#issuecomment-23940308 generalized R2].<br />
<br />
=== Auto-generated "simple" prelude ===<br />
<br />
The diagrams library is extremely polymorphic---much too polymorphic<br />
for beginning users, perhaps. The goal of this project would be to<br />
write some code to automatically generate a module<br />
Diagrams.Prelude.Simple which re-exports things from Diagrams.Prelude<br />
but with more monomorphic types. This would require obtaining the<br />
types of things exported by Diagrams.Prelude, doing some analysis to<br />
determine what "simpler" type to use, then outputting the appropriate<br />
code. There are some interesting, nontrivial questions to be worked<br />
out in terms of how to generate a "simple" type from a more general<br />
one. There may even be room for multiple "levels" with successively<br />
more polymorphism.<br />
<br />
=== Contrib module for graph drawing ===<br />
<br />
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.<br />
<br />
=== Do a better job combining envelopes ===<br />
<br />
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.<br />
<br />
=== Convert SVG files to diagrams ===<br />
<br />
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. Note: This is possible now (although not finished). See https://github.com/diagrams/svg-diagrams<br />
<br />
=== Auto-generate "connect the dots" puzzles ===<br />
<br />
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.<br />
<br />
=== DSL for identifying subdiagrams ===<br />
<br />
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.<br />
<br />
=== Port potrace to Haskell ===<br />
<br />
See http://potrace.sourceforge.net/ and in particular http://potrace.sourceforge.net/potrace.pdf .<br />
<br />
=== General curved surfaces in 3D ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Officially supported backends==<br />
<br />
=== Native SVG ===<br />
<br />
A Haskell-native backend generating SVG. As of diagrams-0.6 this is the default "out-of-the-box" diagrams backend.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dsvg hackage]<br />
* [https://github.com/diagrams/diagrams-svg github repo]<br />
* Status: active development<br />
<br />
=== Rasterific ===<br />
<br />
A Haskell-native backend generating raster graphics, using the [http://hackage.haskell.org/package/Rasterific Rasterific] package.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-rasterific hackage]<br />
* [https://github.com/diagrams/diagrams-rasterific github repo]<br />
* Status: active development<br />
<br />
=== Cairo ===<br />
<br />
Full-featured backend using [http://www.cairographics.org/ cairo]. <br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dcairo hackage]<br />
* [http://github.com/diagrams/diagrams-cairo github repo]<br />
* Status: active development<br />
* Participants: Brent Yorgey, Ryan Yates<br />
<br />
=== GTK ===<br />
<br />
Backend built on top of the cairo backend for rendering directly to GTK windows.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dgtk hackage]<br />
* [http://github.com/diagrams/diagrams-gtk github repo]<br />
* Status: active development<br />
* Participants: John Lato, Brent Yorgey<br />
<br />
=== Postscript ===<br />
<br />
Very similar to the Cairo backend but only outputting EPS.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dpostscript hackage]<br />
* [https://github.com/diagrams/diagrams-postscript github repo]<br />
* Status: active development<br />
* Participants: Ryan Yates<br />
<br />
=== PGF ===<br />
<br />
A backend emitting PGF/TikZ TeX code.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-pgf hackage]<br />
* [https://github.com/diagrams/diagrams-pgf github repo]<br />
* Status: active development<br />
* Participants: Chris Chalmers<br />
<br />
=== Canvas ===<br />
<br />
A backend drawing on an HTML5 canvas.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-canvas hackage]<br />
* [https://github.com/diagrams/diagrams-canvas github repo]<br />
* Status: active development<br />
* Participants: Jeff Rosenbluth, Andy Gill<br />
<br />
=== HTML5 ===<br />
<br />
A backend drawing on an HTML5 canvas.<br />
<br />
* [http://hackage.haskell.org/package/diagrams-html5 hackage]<br />
* [https://github.com/diagrams/diagrams-html5 github repo]<br />
* Status: active development<br />
* Participants: Jeff Rosenbluth<br />
<br />
== Unofficial backends ==<br />
<br />
=== PDF ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams-pdf Hackage]<br />
* [https://github.com/alpheccar/diagrams-pdf github repo]<br />
* Status: dormant<br />
* Participants: Christophe F<br />
<br />
=== GHCJS/canvas ===<br />
<br />
* [https://github.com/ghcjs/diagrams-ghcjs github repo]<br />
* Status: active development<br />
* Participants: Daniil Frumin, Luite Stegeman, Daniel Bergey<br />
<br />
=== OpenGL ===<br />
<br />
* [https://github.com/bergey/diagrams-opengl github repo]<br />
* Status: dormant<br />
* Participants: Daniel Bergey<br />
<br />
=== POV-Ray ===<br />
<br />
A [http://www.povray.org/ POV-Ray backend] for 3D diagrams.<br />
<br />
* [http://github.com/diagrams/diagrams-povray github repo]<br />
* Status: Alpha, active development<br />
* Participants: Daniel Bergey<br />
<br />
=== HsQML ===<br />
<br />
A backend for painting on a QtQuick Canvas.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dhsqml Hackage]<br />
* [https://github.com/marcinmrotek/diagrams-hsqml github repo]<br />
* Status: active<br />
* Participants: Marcin Mrotek<br />
<br />
== Bitrotted/abandoned/superseded backends ==<br />
<br />
=== LaTeX/TikZ ===<br />
<br />
* original [http://patch-tag.com/r/snwalck/diagrams-tikz darcs repo] by Scott Walck<br />
* [https://github.com/mahrz/diagrams-tikz updated version] by Malte Harder on github<br />
* Yet another version is [http://hackage.haskell.org/package/diagrams%2Dtikz on Hackage]<br />
* Status: dormant<br />
* Participants: Scott Walck, Malte Harder<br />
<br />
=== HTML5 canvas ===<br />
<br />
* [https://github.com/jbracker/diagrams-sunroof github repo]<br />
* Status: dormant<br />
* Participants: Jan Bracker, Andy Gill, Brent Yorgey<br />
<br />
== Related packages and tools ==<br />
<br />
=== command-line/interactive ===<br />
<br />
* [https://github.com/mgsloan/diagrams-ghci diagrams-ghci]<br />
<br />
See also an earlier project in a similar direction:<br />
<br />
* [http://patch-tag.com/r/fryguybob/diagrams-hint diagrams-hint]<br />
<br />
=== Writing ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dhaddock diagrams-haddock] is a tool for embedding diagrams in Haddock documentation.<br />
* [http://hackage.haskell.org/package/BlogLiterately%2Ddiagrams BlogLiterately-diagrams] is a tool for embedding diagrams in blog posts.<br />
<br />
=== Build service ===<br />
<br />
[http://github.com/diagrams/diagrams-builder/ 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).<br />
<br />
=== Fonts ===<br />
<br />
The [http://hackage.haskell.org/package/SVGFonts SVGFonts] package implements Haskell-native font support (for fonts in the SVG-font format) that can be plugged into diagrams.<br />
<br />
== Other projects ==<br />
<br />
=== gtk-toy ===<br />
<br />
Michael Sloan's [https://github.com/mgsloan/gtk-toy gtk-toy project] is a framework for creating interactive gtk/cairo applications. [https://github.com/mgsloan/gtk-toy-diagrams gtk-toy-diagrams] provides tools for using diagrams in conjunction with gtk-toy.<br />
<br />
=== LaTeXgrapher ===<br />
<br />
[http://patch-tag.com/r/fryguybob/LaTeXGrapher LaTeXGrapher] is a project by Ryan Yates providing a domain-specific language for producing mathematical graphs, backed by the diagrams-postscript backend.<br />
<br />
=== hs-logo ===<br />
<br />
Deepak Jois is working on a [https://github.com/deepakjois/hs-logo logo interpreter] written in Haskell, using diagrams as a backend.<br />
<br />
== Packages using diagrams ==<br />
<br />
See the [http://packdeps.haskellers.com/reverse/diagrams-lib reverse dependencies of diagrams-lib].</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59569Diagrams/Dev/Migrate1.32015-03-28T19:29:17Z<p>JRosenbluth: </p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
== SVGFonts ==<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59568Diagrams/Dev/Migrate1.32015-03-28T19:28:43Z<p>JRosenbluth: </p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== diagrams-svg ==<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== New Backends ==<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.3&diff=59567Diagrams/Dev/Migrate1.32015-03-28T19:26:44Z<p>JRosenbluth: </p>
<hr />
<div>This page describes breaking API changes between diagrams 1.2 and 1.3, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Linear ==<br />
<br />
The linear algebra package has moved from <code>vector-space</code> to <code>linear</code>.<br />
<br />
The most obvious difference is there are now two type variables for the vector space: <code>v</code>, which gives the space being worked in and <code>n</code>, the number type used. <code>v</code> now has kind <code>* -&gt; *</code>, which means is takes some type (usually <code>n</code>) and makes a concrete vector. Basically this means whenever you saw <code>v</code>, replace it by <code>v n</code>. So:<br />
<br />
* <code>R2 -&gt; V2 Double</code><br />
* <code>Point R2 -&gt; Point V2 Double</code><br />
* <code>Path R2 -&gt; Path V2 Double</code><br />
* <code>QDiagram b v m -&gt; QDiagram b v n m</code><br />
<br />
The <code>Diagram</code> alias has also changed. Now it uses the default space and number type for some backend:<br />
<br />
<code>Diagram b = QDiagram b (V b) (N b) Any</code><br />
<br />
where <code>V b</code> is the default space and <code>N b</code> is the default number type for backend <code>b</code>.<br />
<br />
<code>linear</code>’s functions are very similar to <code>vector-space</code>. The biggest difference is <code>lerp</code> which is defined as<br />
<br />
<pre>lerp alpha u v = alpha *^ u ^+^ (1 - alpha) *^ v</pre><br />
This is the ''opposite'' way round to <code>vector-space</code>’s lerp.<br />
<br />
The old <code>HasX</code>, <code>HasY</code> and <code>HasZ</code> classes have been replaced by linear’s <code>R1</code>, <code>R2</code> and <code>R3</code>.<br />
<br />
== Direction type ==<br />
<br />
A new <code>Direction</code> type has been added to <code>Diagrams.Direction</code>. A <code>Direction</code> is a vector that has forgot its magnitude. Certain functions include <code>arc</code>, <code>reflectAcross</code> have had their types moved from <code>V2 Double</code> to <code>Direction Double</code> to make it clear the magnitude has no impact.<br />
<br />
<code>arc</code> now takes a starting direction and an angle. <code>arcCW</code> and <code>arcCCW</code> give a clockwise or counter clockwise arc between two directions.<br />
<br />
<code>angleBetween</code> is commutative (and always positive).<br />
<br />
== Measure changes ==<br />
<br />
The internal representation of <code>Measure</code> has now changed. The old constructor cannot be used anymore. Instead the have been replaced by:<br />
<br />
* <code>Normalized -&gt; normalized</code> or <code>normalised</code><br />
* <code>Local -&gt; local</code><br />
* <code>Global -&gt; global</code><br />
* <code>Output -&gt; output</code><br />
<br />
== SizeSpec ==<br />
<br />
<code>SizeSpec2D</code> is now <code>SizeSpec V2 Double</code> and has moved to <code>Diagrams.Size</code>. The resizing functions now work for any vector space. The constructors have been replaced with the following functions:<br />
<br />
* <code>Dims -&gt; dims</code><br />
* <code>Width -&gt; mkWidth</code><br />
* <code>Height -&gt; mkHeight</code><br />
* <code>Absolute -&gt; absolute</code><br />
<br />
<code>mkWidth</code> and <code>mkHeight</code> are in <code>Diagrams.TwoD.Size</code>.<br />
<br />
== Names ==<br />
<br />
The qualify with name operator <code>(|&gt;)</code> has moved to <code>(.&gt;&gt;)</code> to make room for lenses snoc operator <code>(|&gt;)</code> (which now works on <code>Line</code>s).<br />
<br />
== ToPath class ==<br />
<br />
A new <code>ToPath</code> class has been added. It takes path-like things (like lines, loops, trails, paths) and converts them to a <code>Path</code>.<br />
<br />
This is very different from the <code>TrailLike</code> class, which is polymorphic in it’s result. Because both these classes are polymorphic, you can’t produce something with the <code>TrailLike</code> class and consume it with <code>ToPath</code> without specifying the type in between.<br />
<br />
Because <code>stroke</code> now uses this class it can cause some ambiguity error for old code. The old (less polymorphic) <code>stroke</code> has moved to <code>strokePath</code> (or <code>strokeP</code>).<br />
<br />
== fsnotify for command line loop ==<br />
<br />
The <code>--loop</code> option for diagrams command line generation uses <code>fsnotify</code> to watch the source file for changes. This means it should now work on Windows.<br />
<br />
Additionally it now works in sandboxes and has a cleaner terminal output.<br />
<br />
== New features ==<br />
<br />
Segment intersections have been added to <code>Diagrams.TwoD.Segment</code>. Functions for intersection points of path-like things are in <code>Diagrams.TwoD.Path</code>.<br />
<br />
There’s a function for finding the convex hull for a list of 2D points in <code>Diagrams.TwoD.Points</code>.<br />
<br />
Affine maps have been added to <code>Diagrams.AffineMap</code> that can map between spaces. The <code>Deformable</code> class has also been generalised to map between spaces. Helper functions have been added to <code>Diagrams.ThreeD.Projection</code> for basic orthographic and perspective projections. These can’t be used on a <code>Diagram</code> yet be can be used on path-like things.<br />
<br />
Some extra functions have been added to <code>Diagrams.Model</code> to help visualise the <code>Trace</code> and <code>Envelope</code> of a diagram.<br />
<br />
== diagrams-svg ==<br />
<br />
== Reorganisation ==<br />
<br />
* <code>LineWidth</code> and <code>Dashing</code> has moved back to <code>Diagrams.Attributes</code>.<br />
* There is no longer a <code>Diagrams.Prelude.ThreeD</code>. Instead all functions are exported by <code>Diagrams.Prelude</code> and functions have had their types generalised to the <code>R1</code>, <code>R2</code> and <code>R3</code> classes.<br />
* <code>Control.Lens</code> and <code>Data.Default</code> are now exported from <code>Diagrams.Prelude</code>. Some names from <code>Control.Lens</code> where hidden.<br />
* A new <code>Diagrams</code> module now only exports functions defined in the diagrams library.<br />
* <code>Diagrams.TwoD.Transform.ScaleInv</code> has moved to <code>Diagrams.Transform.ScaleInv</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Migrate1.2&diff=58269Diagrams/Dev/Migrate1.22014-06-03T16:21:09Z<p>JRosenbluth: /* Images */</p>
<hr />
<div>This page describes breaking API changes between diagrams 1.1 and 1.2, along with explanations of how to migrate to the new 1.2 API.<br />
<br />
== Attributes using Measure ==<br />
<br />
Many distances are now specified using values of type <code>Measure</code>. See the [http://projects.haskell.org/diagrams/doc/manual.html#measurement-units user manual] for full details. The most noticeable effects of this change in porting diagrams code to 1.2 will be type errors on uses of attribute functions like <code>lw</code>, <code>dashing</code>, and <code>fontSize</code>.<br />
<br />
* To simply retain the existing behavior, replace <code>lw</code> with <code>lwG</code>, <code>dashing</code> with <code>dashingG</code>, and <code>fontSize</code> with <code>fontSizeL</code>.<br />
* In many cases, you can simply remove calls to <code>lw</code>, since the default behavior is much more sensible. You can also use the named line weights provided in <code>Diagrams.TwoD.Attributes</code>: <code>none</code>, <code>ultraThin</code>, <code>veryThin</code>, <code>thin</code>, <code>medium</code>, <code>thick</code>, <code>veryThick</code>, or <code>ultraThick</code>. For example, replace <code>lw 0</code> with <code>lw none</code>, and replace (say) <code>lw 0.2</code> with <code>lw veryThick</code> (though note that the relationship between the number used previously and the proper choice of line weight depends on the context, because the old semantics was not very sensible).<br />
<br />
== Removal of <code>freeze</code> ==<br />
<br />
The <code>freeze</code> function has been removed. Most users probably were not using it; if you were, you have several options for replacing it, depending on how you were using it:<br />
<br />
* If you were just using it to get some lines to scale along with a diagram, use a <code>Local</code> line width (''e.g.'' <code>... # lw (Local 2)</code> or <code>... # lwL 2</code>).<br />
* The above will not work if you were doing non-uniform scaling and really care that the lines should come out looking squished and stretched. In that case, use functions in <code>Diagrams.TwoD.Offset</code> to create a path corresponding to the stroked line, and then fill and transform it normally.<br />
<br />
== Arrows ==<br />
<br />
The size of arrow heads and tails is now specified in terms of length instead of the radius of their circumcircle. In addition, the lengths are specified using <code>Measure</code>. For convenience, aliases <code>tiny</code>, <code>verySmall</code>, <code>small</code>, <code>normal</code>, <code>large</code>, <code>veryLarge</code>, and <code>huge</code> have been provided. For example,<br />
<br />
<code> ... & headSize .~ 0.7</code><br />
<br />
might be replaced with<br />
<br />
<code> ... & headLength .~ large</code><br />
<br />
Gaps at the ends of arrows are also specified using <code>Measure R2</code>. Also, the <code>gap</code> traversal has been replaced by <code>gaps</code> for consistency in naming, though <code>gap</code> is still provided for backwards compatibility. For example, replace<br />
<br />
<code> ... & gap .~ 1</code><br />
<br />
by<br />
<br />
<code> ... & gaps .~ Local 1</code><br />
<br />
== Images ==<br />
If you were using the cairo backend to include PNG images in your diagrams then you will need to make some small changes to your code using the new Image API. Diagrams now distinguishes between external and embedded images, cairo (as it has done in previous versions) only supports external images.<br />
For example if you were creating a diagram from a PNG called "myImage.png" using <br />
<br />
<code>image "~/myImage.png" 1 1</code> <br />
<br />
then you can replace it with <br />
<br />
<code>image (uncheckedImageRef "~/myImage.png" 1 1)</code><br />
<br />
and get exactly the same behavior as with 1.1. Additionally, you can now create a "checked" external image with the function <code>loadImageExt</code> which will utilize the Juicy Pixels library to make sure the image exists and calculate its dimension so you don't need to provide a width and height. See the [http://projects.haskell.org/diagrams/doc/manual.html#images user manual] for full details<br />
<br />
== Reorganization ==<br />
<br />
These changes will not affect most users, but are listed here for completeness.<br />
<br />
* The <code>avgScale</code> function has been moved from <code>Diagrams.TwoD.Transform</code> to <code>Diagrams.Core.Transform</code>.<br />
<br />
* Most 2D attributes have been moved from <code>Diagrams.Attributes</code> to <code>Diagrams.TwoD.Attributes</code>.<br />
<br />
* The <code>Angle</code> definition and related functions have moved to a separate module, <code>Diagrams.Angle</code>.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Expression&diff=58125Diagrams/Dev/Expression2014-05-18T19:09:49Z<p>JRosenbluth: /* Pros */</p>
<hr />
<div><br />
= The problem =<br />
<br />
The [http://en.wikipedia.org/wiki/Expression_problem Expression Problem], coined by Phil Wadler, describes a situation where you have a sum type and some operations on it; the problem is to be able to both add new cases to the sum type as well as add new operations. Some approaches, e.g. OOP, make it easy to add new disjuncts (just make a new subclass, and implement all the appropriate methods) but annoying to add new operations (you have to go back through and add a new method implementation for every existing class); others, e.g. algebraic data types, make it easy to add new operations (just write a new function) but annoying to add new disjuncts (you can add a new constructor to your data type but then you have to go through and add a new case to the implementation of every existing function).<br />
<br />
This problem shows up, in a disguised form, in diagrams. Our "sum type" is the set of primitives that can be used to build diagrams; our "operations" are different backends. We have adopted a somewhat more dynamic solution: primitives can be any type, and backends declare which primitives they can handle by implementing an instance of <code>Renderable</code>. This means that new primitives can be easily added (just make a new type; it does not require changing existing backends, which will simply not be able to render it) but also new backends. <br />
<br />
This is sort of like having an algebraic data type for primitives, but allowing the backends (thought of as functions) to have "incomplete pattern matching", i.e. to simply not handle some primitives. Literally implementing it that way would be undesirable, however, because then handing a diagram to a backend which contained primitives it did not handle would cause the program to crash with a runtime pattern match failure.<br />
<br />
Note, if we did away with the ability of different backends to support different primitive types, these problems would all go away. We could just have a single algebraic data type specifying the static list of primitives that all backends must support, and that would be that. (This is the approach taken by many simpler drawing libraries, e.g. gloss.) However, (it seems to me at least) that the added flexibility of backends which can't support certain primitives, or support extra special backend-specific primitives, is a really nice feature that would be very painful to give up.<br />
<br />
= The solution, and a Choice =<br />
<br />
Instead, the "algebraic data type" of primitives is left implicit, with each primitive simply represented by its own type. At this point, however, there are two choices, corresponding, essentially, to static vs. dynamic typing.<br />
<br />
== Static typing ==<br />
<br />
This is the approach currently taken. Each backend has a "token type" and must implement instances of the form <code>Renderable Prim Backend</code>. Prims get wrapped up in an existential wrapper along with an appropriate <code>Renderable</code> instance. When a backend goes to render some primitives, it just unwraps them and uses the enclosed <code>Renderable</code> instance; it doesn't even need to know what type they are.<br />
<br />
This does mean, however, that the backend type ''must'' show up as a parameter to the <code>Diagram</code> type---otherwise the existentially quanitifed <code>Renderable</code> instances would be useless, as there would be no way to know which backend they are for! However, this also makes sense, in a way. If a diagram has type <code>Diagram Foo R2</code>, then we know statically that it can only contain primitives which can be rendered by backend Foo---because any primitive of type <code>P</code> must be wrapped up with a <code>Renderable P Foo</code> instance, and the only way to obtain such an instance is if it is provided by the backend.<br />
<br />
More generally, diagrams can be given polymorphic types like<br />
<br />
<code>(Backend b R2, Renderable (Path R2) b, Renderable Image b) => Diagram b R2</code><br />
<br />
with one constraint for each different type of primitive contained in the diagram.<br />
<br />
=== Pros ===<br />
<br />
* Rendering will never fail at runtime. We know statically that if it typechecks to give a certain diagram to a certain backend, the backend knows what to do with all the primitives it contains.<br />
<br />
* Behavior is more transparent to users: if it typechecks, it will work as expected.<br />
<br />
=== Cons ===<br />
<br />
* The backend type parameter ends up "infecting" quite a lot of types, including UpAnnots, DownAnnots, QDiagram, QDiaLeaf, Subdiagram, SubMap, Prim, DNode, DTree, RNode, RTree.<br />
<br />
* If users want to give type signatures to their diagrams, they have to either write some complicated polymorphic type with lots of constraints, or tie their diagram to a specific backend (or use the <code>B</code> hack, which sort of works, but is not perfect---e.g. it makes it hard to use multiple backends at once).<br />
<br />
== Dynamic typing ==<br />
<br />
The alternative is to use a dynamic typing approach. We do away with the <code>Renderable</code> type class and simply package up each primitive with a <code>Typeable</code> constraint. Then at render time, a backend unwraps each primitive and checks whether it corresponds to a type which that backend knows how to render. If not, it "fails at runtime"---which could mean many different things, e.g.<br />
<br />
* literally crashing (not very nice)<br />
* treating the primitive as if it were <code>mempty</code> (graceful, but might lead to weird hard-to-debug behavior for users who don't realize a certain primitive is not supported by a certain backend)<br />
* the above, plus returning some sort of warning/error message (we could e.g. change the <code>Backend</code> type class to allow/require backends to return errors and warnings).<br />
<br />
There is a sample implementation in the dynamic branches of core, lib, and SVG.<br />
<br />
=== Pros ===<br />
<br />
* No more backend type parameter "infecting" the types. 2D diagrams have the simple type <code>Diagram R2</code>.<br />
<br />
* Would allow getting rid of the dummy "backend token" parameter to many functions<br />
<br />
* The above makes it much easier to hand a diagram to different backends, or even to use multiple backends at once.<br />
<br />
* More graceful degrading of service---if a diagram has a single primitive that is not supported by backend X, it is still possible to use that diagram with backend X, for the price of one missing primitive.<br />
<br />
* In conjunction with the above, this should make it possible to add a choice combinator, <code>orElse :: Diagram v -> Diagram v -> Diagram v</code>, which instructs a backend to use the first diagram it fully supports. This would make it even easier to construct diagrams that are portable between different backends, letting the user explicitly supply fallbacks in cases of differing features.<br />
<br />
* As diagrams continues to grow it is becoming increasingly clear that we will need some testing frameworks. If a diagram is defined as <code>Diagram R2</code> we would be able to create tests that pass if they produce a diagram that matches a reference diagram.<br />
<br />
* Consistency with attributes. We already use dynamic typing for attributes and we may want to have the backends handle attributes and primitives they do not support the same way.<br />
<br />
=== Cons ===<br />
<br />
* Dynamic typing is icky<br />
<br />
* Makes it harder to know which library functions can be used with which backends. Currently, the type of any library function explicitly indicates which primitives it uses; without the help of the compiler/type system, users would have to just rely on documentation to know whether a certain library function will generate a diagram that will be correctly rendered with the backend they are using (or just try it and see whether it works or not).<br />
<br />
* More generally, it would require better tooling/documentation/runtime error messages/etc., which would all need to be maintained and grow along with diagrams.<br />
<br />
= References =<br />
<br />
* [http://ircbrowse.net/browse/diagrams?id=28707&timestamp=1398168740#t1398168740 Relevant #diagrams discussion] <br />
* [http://en.wikipedia.org/wiki/Expression_problem The expression problem]</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Expression&diff=58004Diagrams/Dev/Expression2014-05-02T20:12:16Z<p>JRosenbluth: /* Dynamic typing */</p>
<hr />
<div><br />
= The problem =<br />
<br />
The [http://en.wikipedia.org/wiki/Expression_problem Expression Problem], coined by Phil Wadler, describes a situation where you have a sum type and some operations on it; the problem is to be able to both add new cases to the sum type as well as add new operations. Some approaches, e.g. OOP, make it easy to add new disjuncts (just make a new subclass, and implement all the appropriate methods) but annoying to add new operations (you have to go back through and add a new method implementation for every existing class); others, e.g. algebraic data types, make it easy to add new operations (just write a new function) but annoying to add new disjuncts (you can add a new constructor to your data type but then you have to go through and add a new case to the implementation of every existing function).<br />
<br />
This problem shows up, in a disguised form, in diagrams. Our "sum type" is the set of primitives that can be used to build diagrams; our "operations" are different backends. We have adopted a somewhat more dynamic solution: primitives can be any type, and backends declare which primitives they can handle by implementing an instance of <code>Renderable</code>. This means that new primitives can be easily added (just make a new type; it does not require changing existing backends, which will simply not be able to render it) but also new backends. <br />
<br />
This is sort of like having an algebraic data type for primitives, but allowing the backends (thought of as functions) to have "incomplete pattern matching", i.e. to simply not handle some primitives. Literally implementing it that way would be undesirable, however, because then handing a diagram to a backend which contained primitives it did not handle would cause the program to crash with a runtime pattern match failure.<br />
<br />
Note, if we did away with the ability of different backends to support different primitive types, these problems would all go away. We could just have a single algebraic data type specifying the static list of primitives that all backends must support, and that would be that. (This is the approach taken by many simpler drawing libraries, e.g. gloss.) However, (it seems to me at least) that the added flexibility of backends which can't support certain primitives, or support extra special backend-specific primitives, is a really nice feature that would be very painful to give up.<br />
<br />
= The solution, and a Choice =<br />
<br />
Instead, the "algebraic data type" of primitives is left implicit, with each primitive simply represented by its own type. At this point, however, there are two choices, corresponding, essentially, to static vs. dynamic typing.<br />
<br />
== Static typing ==<br />
<br />
This is the approach currently taken. Each backend has a "token type" and must implement instances of the form <code>Renderable Prim Backend</code>. Prims get wrapped up in an existential wrapper along with an appropriate <code>Renderable</code> instance. When a backend goes to render some primitives, it just unwraps them and uses the enclosed <code>Renderable</code> instance; it doesn't even need to know what type they are.<br />
<br />
This does mean, however, that the backend type ''must'' show up as a parameter to the <code>Diagram</code> type---otherwise the existentially quanitifed <code>Renderable</code> instances would be useless, as there would be no way to know which backend they are for! However, this also makes sense, in a way. If a diagram has type <code>Diagram Foo R2</code>, then we know statically that it can only contain primitives which can be rendered by backend Foo---because any primitive of type <code>P</code> must be wrapped up with a <code>Renderable P Foo</code> instance, and the only way to obtain such an instance is if it is provided by the backend.<br />
<br />
More generally, diagrams can be given polymorphic types like<br />
<br />
<code>(Backend b R2, Renderable (Path R2) b, Renderable Image b) => Diagram b R2</code><br />
<br />
with one constraint for each different type of primitive contained in the diagram.<br />
<br />
=== Pros ===<br />
<br />
* Rendering will never fail at runtime. We know statically that if it typechecks to give a certain diagram to a certain backend, the backend knows what to do with all the primitives it contains.<br />
<br />
* Behavior is more transparent to users: if it typechecks, it will work as expected.<br />
<br />
=== Cons ===<br />
<br />
* The backend type parameter ends up "infecting" quite a lot of types, including UpAnnots, DownAnnots, QDiagram, QDiaLeaf, Subdiagram, SubMap, Prim, DNode, DTree, RNode, RTree.<br />
<br />
* If users want to give type signatures to their diagrams, they have to either write some complicated polymorphic type with lots of constraints, or tie their diagram to a specific backend (or use the <code>B</code> hack, which sort of works, but is not perfect---e.g. it makes it hard to use multiple backends at once).<br />
<br />
== Dynamic typing ==<br />
<br />
The alternative is to use a dynamic typing approach. We do away with the <code>Renderable</code> type class and simply package up each primitive with a <code>Typeable</code> constraint. Then at render time, a backend unwraps each primitive and checks whether it corresponds to a type which that backend knows how to render. If not, it "fails at runtime"---which could mean many different things, e.g.<br />
<br />
* literally crashing (not very nice)<br />
* treating the primitive as if it were <code>mempty</code> (graceful, but might lead to weird hard-to-debug behavior for users who don't realize a certain primitive is not supported by a certain backend)<br />
* the above, plus returning some sort of warning/error message (we could e.g. change the <code>Backend</code> type class to allow/require backends to return errors and warnings).<br />
<br />
There is a sample implementation in the dynamic branches of core, lib, and SVG.<br />
<br />
=== Pros ===<br />
<br />
* No more backend type parameter "infecting" the types. 2D diagrams have the simple type <code>Diagram R2</code>.<br />
<br />
* Would allow getting rid of the dummy "backend token" parameter to many functions<br />
<br />
* The above makes it much easier to hand a diagram to different backends, or even to use multiple backends at once.<br />
<br />
* More graceful degrading of service---if a diagram has a single primitive that is not supported by backend X, it is still possible to use that diagram with backend X, for the price of one missing primitive.<br />
<br />
* In conjunction with the above, this should make it possible to add a choice combinator, <code>orElse :: Diagram v -> Diagram v -> Diagram v</code>, which instructs a backend to use the first diagram it fully supports. This would make it even easier to construct diagrams that are portable between different backends, letting the user explicitly supply fallbacks in cases of differing features.<br />
<br />
* As diagrams continues to grow it is becoming increasingly clear that we will need some testing frameworks. If a diagram is defined as <code>Diagram R2</code> we would be able to create tests that pass if they produce a diagram that matches a reference diagram.<br />
<br />
=== Cons ===<br />
<br />
* Dynamic typing is icky<br />
<br />
* Makes it harder to know which library functions can be used with which backends. Currently, the type of any library function explicitly indicates which primitives it uses; without the help of the compiler/type system, users would have to just rely on documentation to know whether a certain library function will generate a diagram that will be correctly rendered with the backend they are using (or just try it and see whether it works or not).<br />
<br />
* More generally, it would require better tooling/documentation/runtime error messages/etc., which would all need to be maintained and grow along with diagrams.<br />
<br />
= References =<br />
<br />
* [http://ircbrowse.net/browse/diagrams?id=28707&timestamp=1398168740#t1398168740 Relevant #diagrams discussion] <br />
* [http://en.wikipedia.org/wiki/Expression_problem The expression problem]</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Expression&diff=57945Diagrams/Dev/Expression2014-04-24T17:57:51Z<p>JRosenbluth: /* Pros */</p>
<hr />
<div><br />
= The problem =<br />
<br />
The [http://en.wikipedia.org/wiki/Expression_problem Expression Problem], coined by Phil Wadler, describes a situation where you have a sum type and some operations on it; the problem is to be able to both add new cases to the sum type as well as add new operations. Some approaches, e.g. OOP, make it easy to add new disjuncts (just make a new subclass, and implement all the appropriate methods) but annoying to add new operations (you have to go back through and add a new method implementation for every existing class); others, e.g. algebraic data types, make it easy to add new operations (just write a new function) but annoying to add new disjuncts (you can add a new constructor to your data type but then you have to go through and add a new case to the implementation of every existing function).<br />
<br />
This problem shows up, in a disguised form, in diagrams. Our "sum type" is the set of primitives that can be used to build diagrams; our "operations" are different backends. We have adopted a somewhat more dynamic solution: primitives can be any type, and backends declare which primitives they can handle by implementing an instance of <code>Renderable</code>. This means that new primitives can be easily added (just make a new type; it does not require changing existing backends, which will simply not be able to render it) but also new backends. <br />
<br />
This is sort of like having an algebraic data type for primitives, but allowing the backends (thought of as functions) to have "incomplete pattern matching", i.e. to simply not handle some primitives. Literally implementing it that way would be undesirable, however, because then handing a diagram to a backend which contained primitives it did not handle would cause the program to crash with a runtime pattern match failure.<br />
<br />
Note, if we did away with the ability of different backends to support different primitive types, these problems would all go away. We could just have a single algebraic data type specifying the static list of primitives that all backends must support, and that would be that. (This is the approach taken by many simpler drawing libraries, e.g. gloss.) However, (it seems to me at least) that the added flexibility of backends which can't support certain primitives, or support extra special backend-specific primitives, is a really nice feature that would be very painful to give up.<br />
<br />
= The solution, and a Choice =<br />
<br />
Instead, the "algebraic data type" of primitives is left implicit, with each primitive simply represented by its own type. At this point, however, there are two choices, corresponding, essentially, to static vs. dynamic typing.<br />
<br />
== Static typing ==<br />
<br />
This is the approach currently taken. Each backend has a "token type" and must implement instances of the form <code>Renderable Prim Backend</code>. Prims get wrapped up in an existential wrapper along with an appropriate <code>Renderable</code> instance. When a backend goes to render some primitives, it just unwraps them and uses the enclosed <code>Renderable</code> instance; it doesn't even need to know what type they are.<br />
<br />
This does mean, however, that the backend type ''must'' show up as a parameter to the <code>Diagram</code> type---otherwise the existentially quanitifed <code>Renderable</code> instances would be useless, as there would be no way to know which backend they are for! However, this also makes sense, in a way. If a diagram has type <code>Diagram Foo R2</code>, then we know statically that it can only contain primitives which can be rendered by backend Foo---because any primitive of type <code>P</code> must be wrapped up with a <code>Renderable P Foo</code> instance, and the only way to obtain such an instance is if it is provided by the backend.<br />
<br />
More generally, diagrams can be given polymorphic types like<br />
<br />
<code>(Backend b R2, Renderable (Path R2) b, Renderable Image b) => Diagram b R2</code><br />
<br />
with one constraint for each different type of primitive contained in the diagram.<br />
<br />
=== Pros ===<br />
<br />
* Rendering will never fail at runtime. We know statically that if it typechecks to give a certain diagram to a certain backend, the backend knows what to do with all the primitives it contains.<br />
<br />
* Behavior is more transparent to users: if it typechecks, it will work as expected.<br />
<br />
=== Cons ===<br />
<br />
* The backend type parameter ends up "infecting" quite a lot of types, including UpAnnots, DownAnnots, QDiagram, QDiaLeaf, Subdiagram, SubMap, Prim, DNode, DTree, RNode, RTree.<br />
<br />
* If users want to give type signatures to their diagrams, they have to either write some complicated polymorphic type with lots of constraints, or tie their diagram to a specific backend (or use the <code>B</code> hack, which sort of works, but is not perfect---e.g. it makes it hard to use multiple backends at once).<br />
<br />
== Dynamic typing ==<br />
<br />
The alternative is to use a dynamic typing approach. We do away with the <code>Renderable</code> type class and simply package up each primitive with a <code>Typeable</code> constraint. Then at render time, a backend unwraps each primitive and checks whether it corresponds to a type which that backend knows how to render. If not, it "fails at runtime"---which could mean many different things, e.g.<br />
<br />
* literally crashing (not very nice)<br />
* treating the primitive as if it were <code>mempty</code> (graceful, but might lead to weird hard-to-debug behavior for users who don't realize a certain primitive is not supported by a certain backend)<br />
* the above, plus returning some sort of warning/error message (we could e.g. change the <code>Backend</code> type class to allow/require backends to return errors and warnings).<br />
<br />
=== Pros ===<br />
<br />
* No more backend type parameter "infecting" the types. 2D diagrams have the simple type <code>Diagram R2</code>.<br />
<br />
* Would allow getting rid of the dummy "backend token" parameter to many functions<br />
<br />
* The above makes it much easier to hand a diagram to different backends, or even to use multiple backends at once.<br />
<br />
* More graceful degrading of service---if a diagram has a single primitive that is not supported by backend X, it is still possible to use that diagram with backend X, for the price of one missing primitive.<br />
<br />
* In conjunction with the above, this should make it possible to add a choice combinator, <code>orElse :: Diagram v -> Diagram v -> Diagram v</code>, which instructs a backend to use the first diagram it fully supports. This would make it even easier to construct diagrams that are portable between different backends, letting the user explicitly supply fallbacks in cases of differing features.<br />
<br />
* As diagrams continues to grow it is becoming increasingly clear that we will need some testing frameworks. If a diagram is defined as <code>Diagram R2</code> we would be able to create tests that pass if they produce a diagram that matches a reference diagram.<br />
<br />
=== Cons ===<br />
<br />
* Dynamic typing is icky<br />
<br />
* Makes it harder to know which library functions can be used with which backends. Currently, the type of any library function explicitly indicates which primitives it uses; without the help of the compiler/type system, users would have to just rely on documentation to know whether a certain library function will generate a diagram that will be correctly rendered with the backend they are using (or just try it and see whether it works or not).<br />
<br />
* More generally, it would require better tooling/documentation/runtime error messages/etc., which would all need to be maintained and grow along with diagrams.<br />
<br />
= References =<br />
<br />
* [http://ircbrowse.net/browse/diagrams?id=28707&timestamp=1398168740#t1398168740 Relevant #diagrams discussion] <br />
* [http://en.wikipedia.org/wiki/Expression_problem The expression problem]</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Arrows&diff=57717Diagrams/Dev/Arrows2014-03-29T13:19:37Z<p>JRosenbluth: /* ScaleInv */</p>
<hr />
<div>diagrams-lib ought to have a module with some convenient functions for creating arrows pointing from one part of a diagram to another. This page is for gathering ideas and plans for such a module.<br />
<br />
== Arrowheads ==<br />
<br />
There should probably be a collection of "standard" arrowheads for the user to choose from. In addition it ought to be possible for the user to specify any diagram they like for use as an arrowhead.<br />
<br />
=== Scale-invariance ===<br />
<br />
The idea is for arrowheads to be ''scale-invariant'', just like line width. We now have a <code>ScaleInv</code> wrapper for accomplishing this, which works correctly with freezing etc.<br />
<br />
== Drawing arrows ==<br />
<br />
At the most basic level one could imagine an API like<br />
<br />
<code>arrow :: Arrowhead -> P2 -> P2 -> Diagram</code><br />
<br />
and we probably should indeed have such a function, but we'll need to also generalize along several axes.<br />
<br />
First, the most frequent use case will be drawing an arrow ''on top of'' an existing diagram in order to connect two points. So we want something like<br />
<br />
<code>arrow :: IsName n => Arrowhead -> n -> n -> (Diagram -> Diagram)</code><br />
<br />
which draws an arrow between the named points on the given diagram. There are several ways this can be generalized:<br />
<br />
# Instead of drawing an arrow between the named ''points'' one could draw the arrow between the named ''subdiagrams'' (using their traces to find the edges).<br />
# There should also be a way to leave gaps, ''i.e.'' don't draw the arrow precisely from point to point or edge to edge, but leave a gap of a certain absolute size or a certain percentage of the arrow length on either end of the arrow.<br />
<br />
Re: leaving gaps, this will require some generic code to shrink paths. There is already some code to shrink/extend individual segments (and compute the length of segments) [https://github.com/diagrams/diagrams-lib/blob/master/src/Diagrams/Segment.hs#L249 in Diagrams.Segment]. This would need to be extended to shrinking/extending trails and paths appropriately.<br />
<br />
One might also want to have control over the middle of the arrow -- i.e. whether it curves, and if so how much and in which direction, etc.<br />
<br />
== A History of Arrow.hs ==<br />
<br />
=== ScaleInv ===<br />
The original semantics we choose for arrows was for only the shaft length to<br />
change under scaling transformations. This was done not only because we<br />
wanted the head size (from here on what ever I say about head applies to<br />
tail as well) to remain constant, but becuase non-uniorm scalings would cause<br />
the head to point in the wrong direction. See http://projects.haskell.org/diagrams/doc/manual.html#scale-invariance. It<br />
turned out that our solution (wrapping the head in the `ScaleInv` wrapper) was<br />
not enough. Once an arrow was stroked, it would not behave correctly under scales.<br />
We solved the problems of keeping the head size constant and making the arrow<br />
point in the correct direction, but now a scaling could cause the head and shaft<br />
to separate. As explained in https://github.com/diagrams/diagrams-lib/issues/112.<br />
Hence the birth of delayed subtrees.<br />
<br />
=== DelayedLeaf ===<br />
At the risk of stating the obvious,<br />
<code>Diagrams</code> (i.e. <code>DualTree</code>s) are created from the bottom (leaves) up, but <code>DTree</code>s<br />
and <code>RTrees</code> from the top (root) down. Suppose we are creating an arrow using<br />
diagrams functions and combinators. When we are finished we have essentially added<br />
a subtree to a diagram. That subtree cannot use any of the informtion about<br />
transforms and styles above it in the tree (they have not yet been created) so<br />
the arrow is unable to use its final size and location (i.e. accumulated<br />
transform) in its subtree. Brent's elegant solution was twofold:<br />
# To hold off on creating the arrow by creating a new type of leaf, the <code>DelayedLeaf</code> in addition to <code>Prim b v</code> that we already had. The <code>DelayedLeaf</code> contains a funtion <code>DownAnnots v -> QDiagram b v m</code>, in other words a set of instructions about how to create the arrow once its <code>DownAnnots</code> are known.<br />
# A modification of the <code>arrow'</code> function so that it returns a <code>DelayedLeaf</code>. The function wrapped in the <code>DelayedLeaf</code>, <code>delayedArrow</code> takes as parameter the <code>DownAnnots</code> and hence the styles and transforms.<br />
The upshot is that an arrow gets to know the accumulated <code>DownAnnots</code> above it<br />
to use it's conversion to a diagram.<br />
<br />
Since creation of a <code>DTree</code> is top down, by the time<br />
we reach a <code>DelayedLeaf</code> in the `DualTree` we already have all of the accumlated<br />
transforms and styles that will be applied to the arrow. So the <code>DelayedLeaf</code><br />
can be expanded by running the function <code>DownAnnots v -> QDiagram b v m</code> on<br />
the accumulated <code>DownAnnots</code> and recursively calling <code>fromDTree</code> to insert the<br />
arrow into the <code>DTree</code>. It is import ant to note, though at this point the arrow<br />
is essentially finished, all transforms and style have been applied. By the way, I'm pretty sure that at this point we could have removed the <code>scaleInv</code> wrapper from the head.<br />
<br />
(As a side benefit, we are able to use all of the<br />
styles that are applied above the arrow in the tree to do things like change<br />
the color of the entire arrow with functions like <code>lc red</code>.)<br />
<br />
There were still some enhancements we wanted to make,<br />
https://github.com/diagrams/diagrams-lib/issues/162, but for the most part all<br />
was well in Arrow land until ...<br />
<br />
=== Measure ===<br />
With the death of <code>freeze</code> and the switch to <code>Measure</code> in the units branch, it<br />
seems like <code>headSize</code> should have a value of <code>Measure Double</code>. This means that<br />
<code>headSize</code> can have one of four possible units:<br />
# <code>Local</code> which are transformable and in particular scalable. Note that this is in contrast with our original notion of arrows having scale invariant heads. Although it is somewhat similar in behavior to a <code>freeze</code> followed by a uniform scaling.<br />
# <code>Output</code> this is what we have in 1.1.<br />
# <code>Global</code> which scales based on the final size of the diagram.<br />
# <code>Normalized</code> which scales in relation to a logical size.<br />
<br />
See http://www.haskell.org/haskellwiki/Diagrams/Dev/Freezing for more detail<br />
or even better the implementation of `convert` in the units branch,<br />
https://github.com/diagrams/diagrams-core/blob/units/src/Diagrams/Core/Compile.hs#L167.<br />
<br />
The backends should only see <code>Output</code> units therefore before passing an <code>RTree</code><br />
to a backend, all <code>Measure</code>s must be converted to <code>Output</code>. This is done by<br />
traversing the <code>RTree</code> and returning a new <code>RTree</code> where all of the <code>Measure</code>s<br />
have been properly converted. The important thing to notice is that this occurs<br />
after the <code>DelayedLeaf</code> has been expanded and hence the arrow cannot make<br />
any use to the units change to render.<br />
<br />
=== What to do ===<br />
I really don't know but some things to think about are:<br />
# I don't think it is possible to adjust the arrow <code>Measure</code> at the <code>RTree</code> level, since arrows make no further use of units after the <code>delayedArrow</code> function is executed during the conversion to <code>DTree</code>. Unless we can come up with another way of creating arrows.<br />
# Does every attribute with a value of <code>Measure</code> have to implement all 4 value types? In particular is it OK for arrows to only implement <code>Output</code> and <code>Local</code>. If this is what we decide then we are done.<br />
# Move the conversion to <code>Output</code> units back up to the <code>QDiagram -> DTree</code> level. We tried this and decided it was a bad idea.<br />
# Find another way (as opposed to delayed leaves) to handle arrows.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Arrows&diff=57716Diagrams/Dev/Arrows2014-03-29T13:19:15Z<p>JRosenbluth: /* ScaleInv */</p>
<hr />
<div>diagrams-lib ought to have a module with some convenient functions for creating arrows pointing from one part of a diagram to another. This page is for gathering ideas and plans for such a module.<br />
<br />
== Arrowheads ==<br />
<br />
There should probably be a collection of "standard" arrowheads for the user to choose from. In addition it ought to be possible for the user to specify any diagram they like for use as an arrowhead.<br />
<br />
=== Scale-invariance ===<br />
<br />
The idea is for arrowheads to be ''scale-invariant'', just like line width. We now have a <code>ScaleInv</code> wrapper for accomplishing this, which works correctly with freezing etc.<br />
<br />
== Drawing arrows ==<br />
<br />
At the most basic level one could imagine an API like<br />
<br />
<code>arrow :: Arrowhead -> P2 -> P2 -> Diagram</code><br />
<br />
and we probably should indeed have such a function, but we'll need to also generalize along several axes.<br />
<br />
First, the most frequent use case will be drawing an arrow ''on top of'' an existing diagram in order to connect two points. So we want something like<br />
<br />
<code>arrow :: IsName n => Arrowhead -> n -> n -> (Diagram -> Diagram)</code><br />
<br />
which draws an arrow between the named points on the given diagram. There are several ways this can be generalized:<br />
<br />
# Instead of drawing an arrow between the named ''points'' one could draw the arrow between the named ''subdiagrams'' (using their traces to find the edges).<br />
# There should also be a way to leave gaps, ''i.e.'' don't draw the arrow precisely from point to point or edge to edge, but leave a gap of a certain absolute size or a certain percentage of the arrow length on either end of the arrow.<br />
<br />
Re: leaving gaps, this will require some generic code to shrink paths. There is already some code to shrink/extend individual segments (and compute the length of segments) [https://github.com/diagrams/diagrams-lib/blob/master/src/Diagrams/Segment.hs#L249 in Diagrams.Segment]. This would need to be extended to shrinking/extending trails and paths appropriately.<br />
<br />
One might also want to have control over the middle of the arrow -- i.e. whether it curves, and if so how much and in which direction, etc.<br />
<br />
== A History of Arrow.hs ==<br />
<br />
=== ScaleInv ===<br />
The original semantics we choose for arrows was for only the shaft length to<br />
change under a scaling transformations. This was done not only because we<br />
wanted the head size (from here on what ever I say about head applies to<br />
tail as well) to remain constant, but becuase non-uniorm scalings would cause<br />
the head to point in the wrong direction. See http://projects.haskell.org/diagrams/doc/manual.html#scale-invariance. It<br />
turned out that our solution (wrapping the head in the `ScaleInv` wrapper) was<br />
not enough. Once an arrow was stroked, it would not behave correctly under scales.<br />
We solved the problems of keeping the head size constant and making the arrow<br />
point in the correct direction, but now a scaling could cause the head and shaft<br />
to separate. As explained in https://github.com/diagrams/diagrams-lib/issues/112.<br />
Hence the birth of delayed subtrees.<br />
<br />
=== DelayedLeaf ===<br />
At the risk of stating the obvious,<br />
<code>Diagrams</code> (i.e. <code>DualTree</code>s) are created from the bottom (leaves) up, but <code>DTree</code>s<br />
and <code>RTrees</code> from the top (root) down. Suppose we are creating an arrow using<br />
diagrams functions and combinators. When we are finished we have essentially added<br />
a subtree to a diagram. That subtree cannot use any of the informtion about<br />
transforms and styles above it in the tree (they have not yet been created) so<br />
the arrow is unable to use its final size and location (i.e. accumulated<br />
transform) in its subtree. Brent's elegant solution was twofold:<br />
# To hold off on creating the arrow by creating a new type of leaf, the <code>DelayedLeaf</code> in addition to <code>Prim b v</code> that we already had. The <code>DelayedLeaf</code> contains a funtion <code>DownAnnots v -> QDiagram b v m</code>, in other words a set of instructions about how to create the arrow once its <code>DownAnnots</code> are known.<br />
# A modification of the <code>arrow'</code> function so that it returns a <code>DelayedLeaf</code>. The function wrapped in the <code>DelayedLeaf</code>, <code>delayedArrow</code> takes as parameter the <code>DownAnnots</code> and hence the styles and transforms.<br />
The upshot is that an arrow gets to know the accumulated <code>DownAnnots</code> above it<br />
to use it's conversion to a diagram.<br />
<br />
Since creation of a <code>DTree</code> is top down, by the time<br />
we reach a <code>DelayedLeaf</code> in the `DualTree` we already have all of the accumlated<br />
transforms and styles that will be applied to the arrow. So the <code>DelayedLeaf</code><br />
can be expanded by running the function <code>DownAnnots v -> QDiagram b v m</code> on<br />
the accumulated <code>DownAnnots</code> and recursively calling <code>fromDTree</code> to insert the<br />
arrow into the <code>DTree</code>. It is import ant to note, though at this point the arrow<br />
is essentially finished, all transforms and style have been applied. By the way, I'm pretty sure that at this point we could have removed the <code>scaleInv</code> wrapper from the head.<br />
<br />
(As a side benefit, we are able to use all of the<br />
styles that are applied above the arrow in the tree to do things like change<br />
the color of the entire arrow with functions like <code>lc red</code>.)<br />
<br />
There were still some enhancements we wanted to make,<br />
https://github.com/diagrams/diagrams-lib/issues/162, but for the most part all<br />
was well in Arrow land until ...<br />
<br />
=== Measure ===<br />
With the death of <code>freeze</code> and the switch to <code>Measure</code> in the units branch, it<br />
seems like <code>headSize</code> should have a value of <code>Measure Double</code>. This means that<br />
<code>headSize</code> can have one of four possible units:<br />
# <code>Local</code> which are transformable and in particular scalable. Note that this is in contrast with our original notion of arrows having scale invariant heads. Although it is somewhat similar in behavior to a <code>freeze</code> followed by a uniform scaling.<br />
# <code>Output</code> this is what we have in 1.1.<br />
# <code>Global</code> which scales based on the final size of the diagram.<br />
# <code>Normalized</code> which scales in relation to a logical size.<br />
<br />
See http://www.haskell.org/haskellwiki/Diagrams/Dev/Freezing for more detail<br />
or even better the implementation of `convert` in the units branch,<br />
https://github.com/diagrams/diagrams-core/blob/units/src/Diagrams/Core/Compile.hs#L167.<br />
<br />
The backends should only see <code>Output</code> units therefore before passing an <code>RTree</code><br />
to a backend, all <code>Measure</code>s must be converted to <code>Output</code>. This is done by<br />
traversing the <code>RTree</code> and returning a new <code>RTree</code> where all of the <code>Measure</code>s<br />
have been properly converted. The important thing to notice is that this occurs<br />
after the <code>DelayedLeaf</code> has been expanded and hence the arrow cannot make<br />
any use to the units change to render.<br />
<br />
=== What to do ===<br />
I really don't know but some things to think about are:<br />
# I don't think it is possible to adjust the arrow <code>Measure</code> at the <code>RTree</code> level, since arrows make no further use of units after the <code>delayedArrow</code> function is executed during the conversion to <code>DTree</code>. Unless we can come up with another way of creating arrows.<br />
# Does every attribute with a value of <code>Measure</code> have to implement all 4 value types? In particular is it OK for arrows to only implement <code>Output</code> and <code>Local</code>. If this is what we decide then we are done.<br />
# Move the conversion to <code>Output</code> units back up to the <code>QDiagram -> DTree</code> level. We tried this and decided it was a bad idea.<br />
# Find another way (as opposed to delayed leaves) to handle arrows.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Arrows&diff=57713Diagrams/Dev/Arrows2014-03-28T14:57:01Z<p>JRosenbluth: </p>
<hr />
<div>diagrams-lib ought to have a module with some convenient functions for creating arrows pointing from one part of a diagram to another. This page is for gathering ideas and plans for such a module.<br />
<br />
== Arrowheads ==<br />
<br />
There should probably be a collection of "standard" arrowheads for the user to choose from. In addition it ought to be possible for the user to specify any diagram they like for use as an arrowhead.<br />
<br />
=== Scale-invariance ===<br />
<br />
The idea is for arrowheads to be ''scale-invariant'', just like line width. We now have a <code>ScaleInv</code> wrapper for accomplishing this, which works correctly with freezing etc.<br />
<br />
== Drawing arrows ==<br />
<br />
At the most basic level one could imagine an API like<br />
<br />
<code>arrow :: Arrowhead -> P2 -> P2 -> Diagram</code><br />
<br />
and we probably should indeed have such a function, but we'll need to also generalize along several axes.<br />
<br />
First, the most frequent use case will be drawing an arrow ''on top of'' an existing diagram in order to connect two points. So we want something like<br />
<br />
<code>arrow :: IsName n => Arrowhead -> n -> n -> (Diagram -> Diagram)</code><br />
<br />
which draws an arrow between the named points on the given diagram. There are several ways this can be generalized:<br />
<br />
# Instead of drawing an arrow between the named ''points'' one could draw the arrow between the named ''subdiagrams'' (using their traces to find the edges).<br />
# There should also be a way to leave gaps, ''i.e.'' don't draw the arrow precisely from point to point or edge to edge, but leave a gap of a certain absolute size or a certain percentage of the arrow length on either end of the arrow.<br />
<br />
Re: leaving gaps, this will require some generic code to shrink paths. There is already some code to shrink/extend individual segments (and compute the length of segments) [https://github.com/diagrams/diagrams-lib/blob/master/src/Diagrams/Segment.hs#L249 in Diagrams.Segment]. This would need to be extended to shrinking/extending trails and paths appropriately.<br />
<br />
One might also want to have control over the middle of the arrow -- i.e. whether it curves, and if so how much and in which direction, etc.<br />
<br />
== A History of Arrow.hs ==<br />
<br />
=== ScaleInv ===<br />
The original sematics we choose for arrows was for only the shaft length to<br />
change under a scaling transformations. This was done not only because we<br />
wanted the head size (from here on what ever I say about head applies to<br />
tail as well) to remain constant, but becuase non-uniorm scalings would cause<br />
the head to point in the wrong direction. See http://projects.haskell.org/diagrams/doc/manual.html#scale-invariance. It<br />
turned out that our solution (wrapping the head in the `ScaleInv` wrapper) was<br />
not enough. Once an arrow was stroked, it would not behave correctly under scales.<br />
We solved the problems of keeping the head size constant and making the arrow<br />
point in the correct direction, but now a scaling could cause the head and shaft<br />
to separate. As explained in https://github.com/diagrams/diagrams-lib/issues/112.<br />
Hence the birth of delayed subtrees.<br />
<br />
=== DelayedLeaf ===<br />
At the risk of stating the obvious,<br />
<code>Diagrams</code> (i.e. <code>DualTree</code>s) are created from the bottom (leaves) up, but <code>DTree</code>s<br />
and <code>RTrees</code> from the top (root) down. Suppose we are creating an arrow using<br />
diagrams functions and combinators. When we are finished we have essentially added<br />
a subtree to a diagram. That subtree cannot use any of the informtion about<br />
transforms and styles above it in the tree (they have not yet been created) so<br />
the arrow is unable to use its final size and location (i.e. accumulated<br />
transform) in its subtree. Brent's elegant solution was twofold:<br />
# To hold off on creating the arrow by creating a new type of leaf, the <code>DelayedLeaf</code> in addition to <code>Prim b v</code> that we already had. The <code>DelayedLeaf</code> contains a funtion <code>DownAnnots v -> QDiagram b v m</code>, in other words a set of instructions about how to create the arrow once its <code>DownAnnots</code> are known.<br />
# A modification of the <code>arrow'</code> function so that it returns a <code>DelayedLeaf</code>. The function wrapped in the <code>DelayedLeaf</code>, <code>delayedArrow</code> takes as parameter the <code>DownAnnots</code> and hence the styles and transforms.<br />
The upshot is that an arrow gets to know the accumulated <code>DownAnnots</code> above it<br />
to use it's conversion to a diagram.<br />
<br />
Since creation of a <code>DTree</code> is top down, by the time<br />
we reach a <code>DelayedLeaf</code> in the `DualTree` we already have all of the accumlated<br />
transforms and styles that will be applied to the arrow. So the <code>DelayedLeaf</code><br />
can be expanded by running the function <code>DownAnnots v -> QDiagram b v m</code> on<br />
the accumulated <code>DownAnnots</code> and recursively calling <code>fromDTree</code> to insert the<br />
arrow into the <code>DTree</code>. It is import ant to note, though at this point the arrow<br />
is essentially finished, all transforms and style have been applied. By the way, I'm pretty sure that at this point we could have removed the <code>scaleInv</code> wrapper from the head.<br />
<br />
(As a side benefit, we are able to use all of the<br />
styles that are applied above the arrow in the tree to do things like change<br />
the color of the entire arrow with functions like <code>lc red</code>.)<br />
<br />
There were still some enhancements we wanted to make,<br />
https://github.com/diagrams/diagrams-lib/issues/162, but for the most part all<br />
was well in Arrow land until ...<br />
<br />
=== Measure ===<br />
With the death of <code>freeze</code> and the switch to <code>Measure</code> in the units branch, it<br />
seems like <code>headSize</code> should have a value of <code>Measure Double</code>. This means that<br />
<code>headSize</code> can have one of four possible units:<br />
# <code>Local</code> which are transformable and in particular scalable. Note that this is in contrast with our original notion of arrows having scale invariant heads. Although it is somewhat similar in behavior to a <code>freeze</code> followed by a uniform scaling.<br />
# <code>Output</code> this is what we have in 1.1.<br />
# <code>Global</code> which scales based on the final size of the diagram.<br />
# <code>Normalized</code> which scales in relation to a logical size.<br />
<br />
See http://www.haskell.org/haskellwiki/Diagrams/Dev/Freezing for more detail<br />
or even better the implementation of `convert` in the units branch,<br />
https://github.com/diagrams/diagrams-core/blob/units/src/Diagrams/Core/Compile.hs#L167.<br />
<br />
The backends should only see <code>Output</code> units therefore before passing an <code>RTree</code><br />
to a backend, all <code>Measure</code>s must be converted to <code>Output</code>. This is done by<br />
traversing the <code>RTree</code> and returning a new <code>RTree</code> where all of the <code>Measure</code>s<br />
have been properly converted. The important thing to notice is that this occurs<br />
after the <code>DelayedLeaf</code> has been expanded and hence the arrow cannot make<br />
any use to the units change to render.<br />
<br />
=== What to do ===<br />
I really don't know but some things to think about are:<br />
# I don't think it is possible to adjust the arrow <code>Measure</code> at the <code>RTree</code> level, since arrows make no further use of units after the <code>delayedArrow</code> function is executed during the conversion to <code>DTree</code>. Unless we can come up with another way of creating arrows.<br />
# Does every attribute with a value of <code>Measure</code> have to implement all 4 value types? In particular is it OK for arrows to only implement <code>Output</code> and <code>Local</code>. If this is what we decide then we are done.<br />
# Move the conversion to <code>Output</code> units back up to the <code>QDiagram -> DTree</code> level. We tried this and decided it was a bad idea.<br />
# Find another way (as opposed to delayed leaves) to handle arrows.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Hac_NYC/Attendees&diff=57664Hac NYC/Attendees2014-03-14T12:45:32Z<p>JRosenbluth: /* Attendees */</p>
<hr />
<div>= Attendees =<br />
<br />
Feel free to list yourself here -- though this is ''not'' registration. To register, see [https://docs.google.com/forms/d/1taZtjgYozFNebLt1TR2VnKv-ovD2Yv5sOdSZzmi_xFo/viewform this registration form]. Note that while this page is sparse, we have upwards of 40 registered attendees at the moment.<br />
<br />
{| class="wikitable"<br />
! Nickname<br />
! Real Name<br />
! Mobile #<br />
|-<br />
|<br />
| Gershom Bazerman<br />
| <br />
|-<br />
| ozataman<br />
| Ozgun Ataman<br />
|-<br />
| mightybyte<br />
| Doug Beardsley<br />
|-<br />
| vamega<br />
| Varun Madiath<br />
|-<br />
| copumpkin<br />
| Dan Peebles<br />
|-<br />
| carter<br />
| Carter Schonwald<br />
|-<br />
| dolio<br />
| Dan Doel<br />
|-<br />
| peterood<br />
| Peter Rood<br />
|-<br />
| dbp<br />
| Daniel Patterson<br />
|-<br />
| danharaj<br />
| Daniel Haraj<br />
|-<br />
| tlevine<br />
| Thomas Levine<br />
| +1 914 574 1328<br />
|-<br />
| matteo.campanelli<br />
| Matteo Campanelli<br />
|-<br />
| achudnov<br />
| Andrey Chudnov<br />
| <br />
|-<br />
| Rickasaurus<br />
| Richard Minerich<br />
| 860-922-3456<br />
|-<br />
| chrisleague<br />
| Chris League<br />
| league [at] contrapunctus [dot] net<br />
|-<br />
| cgaebel<br />
| Clark Gaebel<br />
| cg.wowus.cg@gmail.com<br />
|-<br />
| katsupnfries<br />
| Kat Chuang<br />
| <br />
|-<br />
| ekmett<br />
| Edward Kmett<br />
| 857-244-1001<br />
|-<br />
| gelisam<br />
| Samuel Gélineau<br />
|-<br />
| amindfv<br />
| Tom Murphy<br />
|-<br />
| zuserm<br />
| Mike Zuser<br />
|-<br />
| imalsogreg<br />
| Greg Hale<br />
| (908)(797)(8281)<br />
|-<br />
| acowley<br />
| Anthony Cowley<br />
|-<br />
| arbn<br />
| Austin Robinson<br />
| 9198891172<br />
|-<br />
| ryantrinkle<br />
| Ryan Trinkle<br />
|-<br />
| martingale<br />
| Jeff Rosenbluth <br />
|-<br />
|}</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Hac_NYC/Projects&diff=57663Hac NYC/Projects2014-03-14T12:42:27Z<p>JRosenbluth: /* Experience */</p>
<hr />
<div>== Sharing your code ==<br />
<br />
If you need a place to host a project so that others can help with it, we suggest [http://hub.darcs.net/ darcs hub], which offers free hosting for public darcs repositories. If you're using git, [http://github.com github] is just dandy as well.<br />
<br />
<br />
== Projects ==<br />
<br />
If you have a project that you want to work on at the Hackathon, please describe it here.<br />
<br />
Since Hackathons are great for teamwork, consider joining one of the projects mentioned below. If you're interested in one of these projects, add your name to the list of hackers under that project.<br />
<!-- Copy this template<br />
=== Project name ===<br />
<br />
I am a project. Love me.<br />
<br />
* Hacker 1<br />
* Hacker 2<br />
--><br />
<br />
<br />
== Experience ==<br />
<br />
Please list projects with which you are familiar. This way, people know whom to contact for more information or guidance on a particular project.<br />
<br />
{| class="wikitable"<br />
! Name<br />
! Projects<br />
|-<br />
| gershom<br />
| [http://www.haskell.org/haskellwiki/Jmacro JMacro]<br />
|-<br />
| mightybyte<br />
| [http://snapframework.com snap], [http://hackage.haskell.org/package/heist heist]<br />
|-<br />
| cgaebel<br />
| [http://hackage.haskell.org/package/network-bitcoin/ Bitcoin]<br />
|- <br />
| carter<br />
| GHC, Numerical Haskell, etc <br />
|-<br />
| Andrey Chudnov<br />
| [http://hackage.haskell.org/package/language-ecmascript language-ecmascript], [http://hackage.haskell.org/package/language-ecmascript-analysis language-ecmascript-analysis], [http://hackage.haskell.org/package/jespresso jespresso], [http://hackage.haskell.org/package/http-encodings http-encodings], [http://hackage.haskell.org/package/haxy haxy]<br />
|-<br />
| martingale<br />
| [http://hackage.haskell.org/package/Rasterific Rasterific] backend for [http://projects.haskell.org/diagrams/ diagrams]<br />
|}<br />
<br />
<br />
[[Category:Community]]</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Freezing&diff=57161Diagrams/Dev/Freezing2013-11-30T22:57:17Z<p>JRosenbluth: /* Units, and getting rid of split transformations */</p>
<hr />
<div>Some rough notes/explanations on freezing and how it relates to optimizing the backend API. Eventually these notes should go into the user manual.<br />
<br />
== The issue ==<br />
<br />
Most often one wants to be able to describe a diagram consisting of a collection of shapes, some of them obtained by transforming (e.g. rotating, shearing, scaling, translating) other shapes, and then draw the whole thing ''using a consistent line width''. It would be strange if, say, a large circle was drawn with a thicker line just because it happened to be generated by scaling a smaller circle. Diagrams are supposed to be scale-invariant but in actuality it would be surprising for them to be truly scale-invariant with regards to line width.<br />
<br />
Another way of thinking about it is that we want to think of diagrams as 'abstract geometric entities' (e.g. perfect circles, etc.) with the details of how they are actually drawn being a separate issue.<br />
<br />
...On the other hand, sometimes we really ''do'' want, say, scaling a diagram to scale the line width proportionally! It really depends on the situation.<br />
<br />
Note that other things in addition to line width may have the same issue, e.g. patterns/textures like gradients, fill patterns, etc. (once we add support for those).<br />
<br />
== Solution #1: transformations always affect attributes ==<br />
<br />
One possible "solution" is to say, in essence, "To heck with thinking of diagrams as abstract geometric entities; transformations will always transform attributes, period." This forces the user to place attribute annotations carefully in order to produce the desired behavior. For example, in order to produce a scene consisting of variously scaled shapes, all drawn with a consistent line width, the user must apply the line width attribute ''after'' doing all the requisite scaling.<br />
<br />
Put more simply, the following snippets of code would produce different output:<br />
<br />
foo # scale 2 # lw 1<br />
foo # lw 1 # scale 2<br />
<br />
This is certainly possible, but has some drawbacks. Most notable is that if a user obtains several diagrams, each of which has already had a line width applied to it, it may be practically impossible to assemble them into a single diagram with consistent-looking lines.<br />
<br />
== Solution #2: 'freeze' ==<br />
<br />
Another solution (the one currently adopted by diagrams) is to have a primitive operation called <code>freeze</code> such that transformations normally do not affect attributes such as line width, but after applying <code>freeze</code>, they do. Intuitively, <code>freeze</code> can be thought of as taking a "snapshot" of the physical realization of a diagram, and from then on transformations apply to the realization/drawing rather than to the abstract geometric ideal underlying it. <br />
<br />
For example, under this scheme<br />
<br />
foo # scale 2 # lw 1<br />
foo # lw 1 # scale 2<br />
<br />
have the same meaning, but<br />
<br />
foo # lw 1 # freeze # scale 2<br />
<br />
is different.<br />
<br />
== Semantics of 'freeze' ==<br />
<br />
One issue is that some backends may not support the ability to do stroking in the context of some transformation (so that e.g. lines come out fatter in some places and thinner in others). It might be nice to define an alternate semantics defined in terms of, e.g. an "average scale factor" for a given transformation, which can be applied directly to the line width attribute itself. The issue would be coming up with a definition which is compositional.<br />
<br />
However, cairo and SVG, at least, both support stroking within transformed contexts, so this hasn't become an issue yet.<br />
<br />
== Implementation of 'freeze' ==<br />
<br />
<code>freeze</code> introduces quite a bit of difficulty into any backend implementation. The reason this is difficult is that some of the transformations ''should'' apply to styles and some ''shouldn't''. But the transformations and styles occur in the tree all mixed up. (Also, transformations can affect some attributes!) The way we handled this in the past was to never give any transformations directly to a backend. We only gave ''fully transformed primitives''. For example, the cairo backend's implementation of <code>withStyle</code> works by ''first'' performing the given rendering operation with ''no'' transformations in effect (since it is given fully transformed primitives), then it applies just the transformations occuring above ''freeze'' (the ones which should affect the line width and so on) before doing the actual stroking.<br />
<br />
However, if we want to be able to apply transformations incrementally while walking down the tree this gets tricky. We can incrementally apply transformations occurring above <code>freeze</code> with no issues, but below a <code>freeze</code> things become problematic since the transformations should apply to primitives but not attributes.<br />
<br />
Even just continuing to fully apply the transformations to primitives and allowing styles to be applied early would go a long way, I think. We could also do some work to coalesce styles. e.g. consider<br />
<br />
foo1 = hcat (map (fc blue . circle) [1,2,3,4,5])<br />
<br />
foo2 = hcat (map circle [1,2,3,4,5]) # fc blue<br />
<br />
It would be nice if these actually generated the same output, ''i.e.'' the programmer didn't have to worry about making such changes to their code in order to "optimize" it.<br />
<br />
== Possible re-implementation of 'freeze' ==<br />
<br />
Not only does <code>freeze</code> adds a significant amount of difficulty into the implementation of backends (although with the new tree based backends, this is somewhat mitigated) but also to the implementation of gradients and patterns as well. Here we discuss a possible alternative to the implementation of <code>freeze</code> that would hopefully simplify dealing with freezing.<br />
<br />
The first step is to eliminate the <code>Split</code> monoid. Then we would rewrite the <code>freeze</code> function so that:<br />
<br />
1. <code>freeze</code> traverses the tree and applies all transformations to styles and primitives leaving a tree with no transform annotations.<br />
<br />
2. Replace attributes that are affected by <code>freeze</code>, e.g. line width with a twin attribute that is <code>Transformable</code>.<br />
<br />
The result is a diagram tree that will respond as expected to all transforms applied after the freeze. One downside is that this implementation may not support non-uniform scaling of line width (although it may be possible by accumulating the transform alongside of line width). One the other hand, the implementation of gradients and patterns should be more straight forward. Furthermore the implementation of an <code>unfreeze</code> function is now possible by traversing the tree and replacing all occurrences of the transformable version of line width by the un-transformable one. The feasibility of this implementation seems plausible, but there remain some issues that need to be addressed including how to handle transforming scale invariant primitives.<br />
<br />
== Units, and getting rid of split transformations ==<br />
<br />
Another possible approach: the key observation is that the heart of the matter is **units**. That is, when we specify that a circle has a radius of 2, or a line has width 0.01, what do these numbers mean---with respect to what are they measured? Right now, the answer is that the 2 is measured with respect to the local coordinate system, and the 0.01 is measured with respect to the final, "absolute" coordinate system. There are at least two other frames of reference with respect to which one could wish to make measurements, and at least for line width, one might wish to specify which reference frame one would like to use to measure it, rather than being forced to use one particular one.<br />
<br />
* A "logical" coordinate system, given by specifying that every diagram has a certain, set, arbitrary size (e.g. 100x100). In fact, it actually makes more sense to measure line width with respect to this logical reference frame by default than with respect to the final coordinate system, since e.g. saying that lines have a default width of 1 (in logical units) would mean that lines are always drawn 1/100 the width of the diagram -- lines would look consistent across all diagrams. Currently, the actual size of the lines depends on the absolute size of the diagram, meaning you often have to adjust the line width to get them to look good.<br />
<br />
* The output coordinate system, i.e. the requested physical output size. One could imagine a situation, for example, where you always want lines that are five pixels wide, no matter how big the diagram is actually rendered.<br />
<br />
The idea is that now each measurement is transformed in some way inherent to its semantics, so <code>freeze</code> can be implemented by a simple traversal which converts some units to others. We can also implement <code>unfreeze</code> easily, and we don't need split transformations anymore. I think this does mean giving up on transforming frozen lines---but I don't feel too bad about that, since (1) I don't know of anyone ever using it, and (2) now that we have path offsets you could always just transform one of those to get the same effect.<br />
<br />
There are a lot of details still to be worked out here, but at the very least I believe that starting to **think** in terms of these different measurement frames of reference will be useful.<br />
<br />
In order to help make this idea more concrete, lets compare the line width of the square in following program using these 4 different units: Absolute, Local, Logical (using an arbitrary size of 1 x 1), and Output. Assume that the diagram is generated with an output width of <code>w</code> and the resulting line width is in output units.<br />
<br />
square x # lw y # scale s<br />
The line widths of each unit would be:<br />
<br />
Absolute: (y * w) / (s * x)<br />
<br />
Local: (y * w) / x<br />
<br />
Logical: y * w<br />
<br />
Output: y<br />
<br />
Note that the type of y would actually have to change to something like:<br />
<br />
data Measurement <br />
= Absolute Double <br />
| Local Double <br />
| Logical Double <br />
| Output Double</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Dev/Freezing&diff=57111Diagrams/Dev/Freezing2013-11-19T15:54:13Z<p>JRosenbluth: </p>
<hr />
<div>Some rough notes/explanations on freezing and how it relates to optimizing the backend API. Eventually these notes should go into the user manual.<br />
<br />
== The issue ==<br />
<br />
Most often one wants to be able to describe a diagram consisting of a collection of shapes, some of them obtained by transforming (e.g. rotating, shearing, scaling, translating) other shapes, and then draw the whole thing ''using a consistent line width''. It would be strange if, say, a large circle was drawn with a thicker line just because it happened to be generated by scaling a smaller circle. Diagrams are supposed to be scale-invariant but in actuality it would be surprising for them to be truly scale-invariant with regards to line width.<br />
<br />
Another way of thinking about it is that we want to think of diagrams as 'abstract geometric entities' (e.g. perfect circles, etc.) with the details of how they are actually drawn being a separate issue.<br />
<br />
...On the other hand, sometimes we really ''do'' want, say, scaling a diagram to scale the line width proportionally! It really depends on the situation.<br />
<br />
Note that other things in addition to line width may have the same issue, e.g. patterns/textures like gradients, fill patterns, etc. (once we add support for those).<br />
<br />
== Solution #1: transformations always affect attributes ==<br />
<br />
One possible "solution" is to say, in essence, "To heck with thinking of diagrams as abstract geometric entities; transformations will always transform attributes, period." This forces the user to place attribute annotations carefully in order to produce the desired behavior. For example, in order to produce a scene consisting of variously scaled shapes, all drawn with a consistent line width, the user must apply the line width attribute ''after'' doing all the requisite scaling.<br />
<br />
Put more simply, the following snippets of code would produce different output:<br />
<br />
foo # scale 2 # lw 1<br />
foo # lw 1 # scale 2<br />
<br />
This is certainly possible, but has some drawbacks. Most notable is that if a user obtains several diagrams, each of which has already had a line width applied to it, it may be practically impossible to assemble them into a single diagram with consistent-looking lines.<br />
<br />
== Solution #2: 'freeze' ==<br />
<br />
Another solution (the one currently adopted by diagrams) is to have a primitive operation called <code>freeze</code> such that transformations normally do not affect attributes such as line width, but after applying <code>freeze</code>, they do. Intuitively, <code>freeze</code> can be thought of as taking a "snapshot" of the physical realization of a diagram, and from then on transformations apply to the realization/drawing rather than to the abstract geometric ideal underlying it. <br />
<br />
For example, under this scheme<br />
<br />
foo # scale 2 # lw 1<br />
foo # lw 1 # scale 2<br />
<br />
have the same meaning, but<br />
<br />
foo # lw 1 # freeze # scale 2<br />
<br />
is different.<br />
<br />
== Semantics of 'freeze' ==<br />
<br />
One issue is that some backends may not support the ability to do stroking in the context of some transformation (so that e.g. lines come out fatter in some places and thinner in others). It might be nice to define an alternate semantics defined in terms of, e.g. an "average scale factor" for a given transformation, which can be applied directly to the line width attribute itself. The issue would be coming up with a definition which is compositional.<br />
<br />
However, cairo and SVG, at least, both support stroking within transformed contexts, so this hasn't become an issue yet.<br />
<br />
== Implementation of 'freeze' ==<br />
<br />
<code>freeze</code> introduces quite a bit of difficulty into any backend implementation. The reason this is difficult is that some of the transformations ''should'' apply to styles and some ''shouldn't''. But the transformations and styles occur in the tree all mixed up. (Also, transformations can affect some attributes!) The way we handled this in the past was to never give any transformations directly to a backend. We only gave ''fully transformed primitives''. For example, the cairo backend's implementation of <code>withStyle</code> works by ''first'' performing the given rendering operation with ''no'' transformations in effect (since it is given fully transformed primitives), then it applies just the transformations occuring above ''freeze'' (the ones which should affect the line width and so on) before doing the actual stroking.<br />
<br />
However, if we want to be able to apply transformations incrementally while walking down the tree this gets tricky. We can incrementally apply transformations occurring above <code>freeze</code> with no issues, but below a <code>freeze</code> things become problematic since the transformations should apply to primitives but not attributes.<br />
<br />
Even just continuing to fully apply the transformations to primitives and allowing styles to be applied early would go a long way, I think. We could also do some work to coalesce styles. e.g. consider<br />
<br />
foo1 = hcat (map (fc blue . circle) [1,2,3,4,5])<br />
<br />
foo2 = hcat (map circle [1,2,3,4,5]) # fc blue<br />
<br />
It would be nice if these actually generated the same output, ''i.e.'' the programmer didn't have to worry about making such changes to their code in order to "optimize" it.<br />
<br />
== Possible re-implementation of 'freeze' ==<br />
<br />
Not only does <code>freeze</code> adds a significant amount of difficulty into the implementation of backends (although with the new tree based backends, this is somewhat mitigated) but also to the implementation of gradients and patterns as well. Here we discuss a possible alternative to the implementation of <code>freeze</code> that would hopefully simplify dealing with freezing.<br />
<br />
The first step is to eliminate the <code>Split</code> monoid. Then we would rewrite the <code>freeze</code> function so that:<br />
<br />
1. <code>freeze</code> traverses the tree and applies all transformations to styles and primitives leaving a tree with no transform annotations.<br />
<br />
2. Replace attributes that are affected by <code>freeze</code>, e.g. line width with a twin attribute that is <code>Transformable</code>.<br />
<br />
The result is a diagram tree that will respond as expected to all transforms applied after the freeze. One downside is that this implementation may not support non-uniform scaling of line width (although it may be possible by accumulating the transform alongside of line width). One the other hand, the implementation of gradients and patterns should be more straight forward. Furthermore the implementation of an <code>unfreeze</code> function is now possible by traversing the tree and replacing all occurrences of the transformable version of line width by the un-transformable one. The feasibility of this implementation seems plausible, but there remain some issues that need to be addressed including how to handle transforming scale invariant primitives.</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Projects&diff=56811Diagrams/Projects2013-09-11T19:08:39Z<p>JRosenbluth: /* DSL for identifying subdiagrams */</p>
<hr />
<div>==Potential projects==<br />
<br />
Looking for something to work on? Try one of these!<br />
<br />
=== Port cool examples to diagrams ===<br />
<br />
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?) <br />
<br />
Some possible sources of inspiration:<br />
* http://web.williams.edu/Mathematics/devadoss/papers.html<br />
* http://www.bridgesmathart.org/<br />
* http://recodeproject.com/<br />
* [http://www.joachim-breitner.de/blog/archives/557-A-copying-garbage-collector-animated.html Joachim Breitner's animation of a copying garbage collector]<br />
* [http://www.numbersimulation.com/ Cool animation demonstrating the concept of prime numbers with orbiting segments for each natural]<br />
* [http://youtu.be/ug9fhgy9N60 animation of creating a dragon curve fractal by cutting and sliding blocks]<br />
* [http://www.mathcurve.com/fractals/gosper/gosper.shtml Gosper fractal, aka flowsnake]<br />
<br />
=== Include animations in the gallery and user manual ===<br />
<br />
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 .<br />
<br />
=== GUI application for creating diagrams interactively ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
* the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file<br />
* 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)<br />
* 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<br />
* Support for developing animations (e.g. with a slider for moving back+forth in time)<br />
<br />
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.<br />
<br />
=== Path operations ===<br />
<br />
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.<br />
<br />
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!).<br />
<br />
For more ideas see http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html.<br />
<br />
=== Taking advantage of diagram tree structure ===<br />
<br />
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:<br />
<br />
* 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.<br />
<br />
* There are additional features which could be implemented if backends were able to observe the tree structure, such as grouping for transparency.<br />
<br />
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. <br />
<br />
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.<br />
<br />
=== Constraint Based Diagrams ===<br />
<br />
Generate diagrams that meet some declarative constraint specification---perhaps something<br />
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.<br />
<br />
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). See also https://groups.google.com/d/msg/diagrams-discuss/WBbhB4RXnck/ekSJOnHdBw8J .<br />
<br />
=== Search for Interesting Diagrams ===<br />
<br />
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.<br />
<br />
=== 3D diagrams ===<br />
<br />
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:<br />
<br />
* Add three-dimensional primitives and functions to [https://github.com/diagrams/diagrams-lib diagrams-lib].<br />
<br />
* 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.<br />
<br />
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).<br />
<br />
=== External Rendering ===<br />
<br />
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.<br />
<br />
=== Variable Precision ===<br />
<br />
It would be nice to be able to trade off precision of the vector output of some<br />
backend with the size of that output. For instance the factorization diagrams<br />
are rather large when rendered to SVG, but their size could be cut in half by<br />
emitting doubles formatted to two significant digits. There is a nice balance<br />
that could be struck at a high level where we ensure that we are always within<br />
some fraction of what will likely be a pixel in the final output. Then at the<br />
level of the backend we would only need to choose the representation that is<br />
the smallest for any particular number.<br />
<br />
This could be aided by generalized R2.<br />
<br />
=== Auto-generated "simple" prelude ===<br />
<br />
The diagrams library is extremely polymorphic---much too polymorphic<br />
for beginning users, perhaps. The goal of this project would be to<br />
write some code to automatically generate a module<br />
Diagrams.Prelude.Simple which re-exports things from Diagrams.Prelude<br />
but with more monomorphic types. This would require obtaining the<br />
types of things exported by Diagrams.Prelude, doing some analysis to<br />
determine what "simpler" type to use, then outputting the appropriate<br />
code. There are some interesting, nontrivial questions to be worked<br />
out in terms of how to generate a "simple" type from a more general<br />
one. There may even be room for multiple "levels" with successively<br />
more polymorphism.<br />
<br />
=== Contrib module for graph drawing ===<br />
<br />
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.<br />
<br />
=== Do a better job combining envelopes ===<br />
<br />
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.<br />
<br />
=== Convert SVG files to diagrams ===<br />
<br />
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.<br />
<br />
=== Auto-generate "connect the dots" puzzles ===<br />
<br />
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.<br />
<br />
=== Website redesign ===<br />
<br />
Do you know something about web design? It would be nice to have a real, modern design for the diagrams website. Any new design should be easy to integrate with our existing website generator built using hakyll.<br />
<br />
=== DSL for identifying subdiagrams ===<br />
<br />
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.<br />
<br />
==Officially supported backends==<br />
<br />
=== Native SVG ===<br />
<br />
A Haskell-native backend generating SVG. As of diagrams-0.6 this is the default "out-of-the-box" diagrams backend.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dsvg hackage]<br />
* [https://github.com/diagrams/diagrams-svg github repo]<br />
* Status: active development<br />
* Participants: Deepak Jois, Ryan Yates, Felipe Lessa, Brent Yorgey<br />
<br />
=== Cairo ===<br />
<br />
Full-featured backend using [http://www.cairographics.org/ cairo]. <br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dcairo hackage]<br />
* [http://github.com/diagrams/diagrams-cairo github repo]<br />
* Status: active development<br />
* Participants: Brent Yorgey, Ryan Yates<br />
<br />
=== GTK ===<br />
<br />
Backend built on top of the cairo backend for rendering directly to GTK windows.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dgtk hackage]<br />
* [http://github.com/diagrams/diagrams-gtk github repo]<br />
* Status: active development<br />
* Participants: John Lato, Brent Yorgey<br />
<br />
=== Native Postscript ===<br />
<br />
Very similar to the Cairo backend but only outputting EPS.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dpostscript hackage]<br />
* [https://github.com/diagrams/diagrams-postscript github repo]<br />
* Status: active development<br />
* Participants: Ryan Yates<br />
<br />
== Unofficial backends ==<br />
<br />
=== PDF ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams-pdf Hackage]<br />
* [https://github.com/alpheccar/diagrams-pdf github repo]<br />
* Status: active<br />
* Participants: Christophe F<br />
<br />
=== GHCJS/canvas ===<br />
<br />
* [https://github.com/ghcjs/diagrams-ghcjs github repo]<br />
* Status: active development<br />
* Participants: Daniil Frumin, Luite Stegeman<br />
<br />
=== OpenGL ===<br />
<br />
* [https://github.com/bergey/diagrams-opengl github repo]<br />
* Status: active development<br />
* Participants: Daniel Bergey<br />
<br />
=== HTML5 canvas ===<br />
<br />
* [https://github.com/jbracker/diagrams-sunroof github repo]<br />
* Status: dormant<br />
* Participants: Jan Bracker, Andy Gill, Brent Yorgey<br />
<br />
=== LaTeX/TikZ ===<br />
<br />
* original [http://patch-tag.com/r/snwalck/diagrams-tikz darcs repo] by Scott Walck<br />
* [https://github.com/mahrz/diagrams-tikz updated version] by Malte Harder on github<br />
* Yet another version is [http://hackage.haskell.org/package/diagrams%2Dtikz on Hackage]<br />
* Status: dormant<br />
* Participants: Scott Walck, Malte Harder<br />
<br />
=== POV-Ray ===<br />
<br />
A [http://www.povray.org/ POV-Ray backend] for 3D diagrams.<br />
<br />
* [http://github.com/diagrams/diagrams-povray github repo]<br />
* Status: proof of concept only, needs someone to take it over!<br />
<br />
== Related packages and tools ==<br />
<br />
=== command-line/interactive ===<br />
<br />
* [https://github.com/mgsloan/diagrams-ghci diagrams-ghci]<br />
<br />
See also an earlier project in a similar direction:<br />
<br />
* [http://patch-tag.com/r/fryguybob/diagrams-hint diagrams-hint]<br />
<br />
=== Writing ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dhaddock diagrams-haddock] is a tool for embedding diagrams in Haddock documentation.<br />
* [http://hackage.haskell.org/package/BlogLiterately%2Ddiagrams BlogLiterately-diagrams] is a tool for embedding diagrams in blog posts.<br />
<br />
=== Build service ===<br />
<br />
[http://github.com/diagrams/diagrams-builder/ 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).<br />
<br />
=== Fonts ===<br />
<br />
The [http://hackage.haskell.org/package/SVGFonts SVGFonts] package implements Haskell-native font support (for fonts in the SVG-font format) that can be plugged into diagrams.<br />
<br />
== Other projects ==<br />
<br />
=== gtk-toy ===<br />
<br />
Michael Sloan's [https://github.com/mgsloan/gtk-toy gtk-toy project] is a framework for creating interactive gtk/cairo applications. [https://github.com/mgsloan/gtk-toy-diagrams gtk-toy-diagrams] provides tools for using diagrams in conjunction with gtk-toy.<br />
<br />
=== LaTeXgrapher ===<br />
<br />
[http://patch-tag.com/r/fryguybob/LaTeXGrapher LaTeXGrapher] is a project by Ryan Yates providing a domain-specific language for producing mathematical graphs, backed by the diagrams-postscript backend.<br />
<br />
=== hs-logo ===<br />
<br />
Deepak Jois is working on a [https://github.com/deepakjois/hs-logo logo interpreter] written in Haskell, using diagrams as a backend.<br />
<br />
== Packages using diagrams ==<br />
<br />
* [http://hackage.haskell.org/package/hierarchical-clustering-diagrams hierarchical-clustering-diagrams]</div>JRosenbluthhttps://wiki.haskell.org/index.php?title=Diagrams/Projects&diff=56810Diagrams/Projects2013-09-11T16:11:36Z<p>JRosenbluth: /* Potential projects */</p>
<hr />
<div>==Potential projects==<br />
<br />
Looking for something to work on? Try one of these!<br />
<br />
=== Port cool examples to diagrams ===<br />
<br />
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?) <br />
<br />
Some possible sources of inspiration:<br />
* http://web.williams.edu/Mathematics/devadoss/papers.html<br />
* http://www.bridgesmathart.org/<br />
* http://recodeproject.com/<br />
* [http://www.joachim-breitner.de/blog/archives/557-A-copying-garbage-collector-animated.html Joachim Breitner's animation of a copying garbage collector]<br />
* [http://www.numbersimulation.com/ Cool animation demonstrating the concept of prime numbers with orbiting segments for each natural]<br />
* [http://youtu.be/ug9fhgy9N60 animation of creating a dragon curve fractal by cutting and sliding blocks]<br />
* [http://www.mathcurve.com/fractals/gosper/gosper.shtml Gosper fractal, aka flowsnake]<br />
<br />
=== Include animations in the gallery and user manual ===<br />
<br />
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 .<br />
<br />
=== GUI application for creating diagrams interactively ===<br />
<br />
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.<br />
<br />
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:<br />
<br />
* the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file<br />
* 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)<br />
* 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<br />
* Support for developing animations (e.g. with a slider for moving back+forth in time)<br />
<br />
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.<br />
<br />
=== Path operations ===<br />
<br />
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.<br />
<br />
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!).<br />
<br />
For more ideas see http://www.cgal.org/Manual/latest/doc_html/cgal_manual/packages.html.<br />
<br />
=== Taking advantage of diagram tree structure ===<br />
<br />
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:<br />
<br />
* 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.<br />
<br />
* There are additional features which could be implemented if backends were able to observe the tree structure, such as grouping for transparency.<br />
<br />
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. <br />
<br />
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.<br />
<br />
=== Constraint Based Diagrams ===<br />
<br />
Generate diagrams that meet some declarative constraint specification---perhaps something<br />
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.<br />
<br />
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). See also https://groups.google.com/d/msg/diagrams-discuss/WBbhB4RXnck/ekSJOnHdBw8J .<br />
<br />
=== Search for Interesting Diagrams ===<br />
<br />
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.<br />
<br />
=== 3D diagrams ===<br />
<br />
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:<br />
<br />
* Add three-dimensional primitives and functions to [https://github.com/diagrams/diagrams-lib diagrams-lib].<br />
<br />
* 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.<br />
<br />
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).<br />
<br />
=== External Rendering ===<br />
<br />
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.<br />
<br />
=== Variable Precision ===<br />
<br />
It would be nice to be able to trade off precision of the vector output of some<br />
backend with the size of that output. For instance the factorization diagrams<br />
are rather large when rendered to SVG, but their size could be cut in half by<br />
emitting doubles formatted to two significant digits. There is a nice balance<br />
that could be struck at a high level where we ensure that we are always within<br />
some fraction of what will likely be a pixel in the final output. Then at the<br />
level of the backend we would only need to choose the representation that is<br />
the smallest for any particular number.<br />
<br />
This could be aided by generalized R2.<br />
<br />
=== Auto-generated "simple" prelude ===<br />
<br />
The diagrams library is extremely polymorphic---much too polymorphic<br />
for beginning users, perhaps. The goal of this project would be to<br />
write some code to automatically generate a module<br />
Diagrams.Prelude.Simple which re-exports things from Diagrams.Prelude<br />
but with more monomorphic types. This would require obtaining the<br />
types of things exported by Diagrams.Prelude, doing some analysis to<br />
determine what "simpler" type to use, then outputting the appropriate<br />
code. There are some interesting, nontrivial questions to be worked<br />
out in terms of how to generate a "simple" type from a more general<br />
one. There may even be room for multiple "levels" with successively<br />
more polymorphism.<br />
<br />
=== Contrib module for graph drawing ===<br />
<br />
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.<br />
<br />
=== Do a better job combining envelopes ===<br />
<br />
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.<br />
<br />
=== Convert SVG files to diagrams ===<br />
<br />
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.<br />
<br />
=== Auto-generate "connect the dots" puzzles ===<br />
<br />
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.<br />
<br />
=== Website redesign ===<br />
<br />
Do you know something about web design? It would be nice to have a real, modern design for the diagrams website. Any new design should be easy to integrate with our existing website generator built using hakyll.<br />
<br />
=== DSL for identifying subdiagrams ===<br />
<br />
It would be extremely useful if subdiagrams could be identified with some "english-like" language. For example, "the smallest circle" or "the third square from the left". 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>"the line connecting the two triangles" # lw 0.2 # lc red</hask>, and perhaps even, <hask>delete "the polygon with 5 sides"</hask> become possible. The idea would be to start with something very simple that we could add to incrementally.<br />
<br />
==Officially supported backends==<br />
<br />
=== Native SVG ===<br />
<br />
A Haskell-native backend generating SVG. As of diagrams-0.6 this is the default "out-of-the-box" diagrams backend.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dsvg hackage]<br />
* [https://github.com/diagrams/diagrams-svg github repo]<br />
* Status: active development<br />
* Participants: Deepak Jois, Ryan Yates, Felipe Lessa, Brent Yorgey<br />
<br />
=== Cairo ===<br />
<br />
Full-featured backend using [http://www.cairographics.org/ cairo]. <br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dcairo hackage]<br />
* [http://github.com/diagrams/diagrams-cairo github repo]<br />
* Status: active development<br />
* Participants: Brent Yorgey, Ryan Yates<br />
<br />
=== GTK ===<br />
<br />
Backend built on top of the cairo backend for rendering directly to GTK windows.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dgtk hackage]<br />
* [http://github.com/diagrams/diagrams-gtk github repo]<br />
* Status: active development<br />
* Participants: John Lato, Brent Yorgey<br />
<br />
=== Native Postscript ===<br />
<br />
Very similar to the Cairo backend but only outputting EPS.<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dpostscript hackage]<br />
* [https://github.com/diagrams/diagrams-postscript github repo]<br />
* Status: active development<br />
* Participants: Ryan Yates<br />
<br />
== Unofficial backends ==<br />
<br />
=== PDF ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams-pdf Hackage]<br />
* [https://github.com/alpheccar/diagrams-pdf github repo]<br />
* Status: active<br />
* Participants: Christophe F<br />
<br />
=== GHCJS/canvas ===<br />
<br />
* [https://github.com/ghcjs/diagrams-ghcjs github repo]<br />
* Status: active development<br />
* Participants: Daniil Frumin, Luite Stegeman<br />
<br />
=== OpenGL ===<br />
<br />
* [https://github.com/bergey/diagrams-opengl github repo]<br />
* Status: active development<br />
* Participants: Daniel Bergey<br />
<br />
=== HTML5 canvas ===<br />
<br />
* [https://github.com/jbracker/diagrams-sunroof github repo]<br />
* Status: dormant<br />
* Participants: Jan Bracker, Andy Gill, Brent Yorgey<br />
<br />
=== LaTeX/TikZ ===<br />
<br />
* original [http://patch-tag.com/r/snwalck/diagrams-tikz darcs repo] by Scott Walck<br />
* [https://github.com/mahrz/diagrams-tikz updated version] by Malte Harder on github<br />
* Yet another version is [http://hackage.haskell.org/package/diagrams%2Dtikz on Hackage]<br />
* Status: dormant<br />
* Participants: Scott Walck, Malte Harder<br />
<br />
=== POV-Ray ===<br />
<br />
A [http://www.povray.org/ POV-Ray backend] for 3D diagrams.<br />
<br />
* [http://github.com/diagrams/diagrams-povray github repo]<br />
* Status: proof of concept only, needs someone to take it over!<br />
<br />
== Related packages and tools ==<br />
<br />
=== command-line/interactive ===<br />
<br />
* [https://github.com/mgsloan/diagrams-ghci diagrams-ghci]<br />
<br />
See also an earlier project in a similar direction:<br />
<br />
* [http://patch-tag.com/r/fryguybob/diagrams-hint diagrams-hint]<br />
<br />
=== Writing ===<br />
<br />
* [http://hackage.haskell.org/package/diagrams%2Dhaddock diagrams-haddock] is a tool for embedding diagrams in Haddock documentation.<br />
* [http://hackage.haskell.org/package/BlogLiterately%2Ddiagrams BlogLiterately-diagrams] is a tool for embedding diagrams in blog posts.<br />
<br />
=== Build service ===<br />
<br />
[http://github.com/diagrams/diagrams-builder/ 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).<br />
<br />
=== Fonts ===<br />
<br />
The [http://hackage.haskell.org/package/SVGFonts SVGFonts] package implements Haskell-native font support (for fonts in the SVG-font format) that can be plugged into diagrams.<br />
<br />
== Other projects ==<br />
<br />
=== gtk-toy ===<br />
<br />
Michael Sloan's [https://github.com/mgsloan/gtk-toy gtk-toy project] is a framework for creating interactive gtk/cairo applications. [https://github.com/mgsloan/gtk-toy-diagrams gtk-toy-diagrams] provides tools for using diagrams in conjunction with gtk-toy.<br />
<br />
=== LaTeXgrapher ===<br />
<br />
[http://patch-tag.com/r/fryguybob/LaTeXGrapher LaTeXGrapher] is a project by Ryan Yates providing a domain-specific language for producing mathematical graphs, backed by the diagrams-postscript backend.<br />
<br />
=== hs-logo ===<br />
<br />
Deepak Jois is working on a [https://github.com/deepakjois/hs-logo logo interpreter] written in Haskell, using diagrams as a backend.<br />
<br />
== Packages using diagrams ==<br />
<br />
* [http://hackage.haskell.org/package/hierarchical-clustering-diagrams hierarchical-clustering-diagrams]</div>JRosenbluth