|Portability||GHC with TypeFamilies and more|
|Maintainer||Stephen Tetley <firstname.lastname@example.org>|
Common interface to Wumpus.Core.
This module re-exports types and functions from:
Named colours ( black, white etc.) are hidden from Wumpus.Core.Colour to avoid collisions with modules that define colour sets (e.g. all the SVG colours).
Some data types are exported from Wumpus.Core.PictureInternal but are made opaque.
- module Wumpus.Core.AffineTrans
- module Wumpus.Core.BoundingBox
- module Wumpus.Core.Colour
- module Wumpus.Core.FontSize
- module Wumpus.Core.Geometry
- module Wumpus.Core.GraphicsState
- module Wumpus.Core.OutputPostScript
- module Wumpus.Core.OutputSVG
- module Wumpus.Core.Picture
- module Wumpus.Core.PictureLanguage
- module Wumpus.Core.TextEncoder
- data Picture u
- type DPicture = Picture Double
- data Primitive u
- type DPrimitive = Primitive Double
- data Path u
- type DPath = Path Double
- data PathSegment u
- type DPathSegment = PathSegment Double
- data Label u
- type DLabel = Label Double
- type PathProps = (PSRgb, DrawPath)
- type LabelProps = (PSRgb, FontAttr)
- type EllipseProps = (PSRgb, DrawEllipse)
- data DrawPath
- data DrawEllipse
Picture is a leaf attributed tree - where atttibutes are colour, line-width etc. It is parametric on the unit type of points (typically Double).
Wumpus's Picture, being a leaf attributed tree, is not ideally matched to PostScript's picture representation, which might be considered a node attributed tree if you recast graphics state updates as syntactic commands encountered during top-down evaluation.
Currently this mismatch means that the PostScript code
generated by Wumpus has significant overuse of PostScript's
At some point a tree-rewriting step might be added to coalesce some of the repeated graphics state updates.
Apropos the constructors, Picture is a simple non-empty leaf-labelled rose tree via
Single (aka leaf) | Picture (OneList tree)
Where OneList is a variant of the standard list type that disallows empty lists.
The additional constructors are convenience:
PickBlank has a bounding box but no content and is useful for
some picture language operations (e.g.
Clip nests a picture (tree) inside a clipping path.
|Eq u => Eq (Picture u)|
|Show u => Show (Picture u)|
|(Num u, Pretty u) => Pretty (Picture u)|
|(Num u, Ord u, Horizontal (Picture u), Vertical (Picture u)) => Move (Picture u)|
|(Num u, Ord u) => Vertical (Picture u)|
|(Num u, Ord u) => Horizontal (Picture u)|
|(Num u, Ord u) => Blank (Picture u)|
|(Num u, Ord u) => Composite (Picture u)|
|(Num u, Ord u) => Translate (Picture u)|
|(Num u, Ord u) => Scale (Picture u)|
|(Floating u, Real u) => RotateAbout (Picture u)|
|(Floating u, Real u) => Rotate (Picture u)|
|Boundary (Picture u)|
Wumpus's drawings are built from two fundamental primitives: paths (line segments and Bezier curves) and labels (single lines of text).
Ellipses are a included as a primitive only for optimization
- drawing a reasonable circle with Bezier curves needs at
least eight curves. This is inconvenient for drawing dots
which can otherwise be drawn with a single
Wumpus does not follow PostScript and employ arcs as general path primitives - they are used only to draw ellipses. This is because arcs do not enjoy the nice properties of Bezier curves, whereby the affine transformation of a Bezier curve can simply be achieved by the affine transformation of it's control points.
Ellipses are represented by their center, half-width and half-height. Half-width and half-height are used so the bounding box can be calculated using only multiplication, and thus initially only obliging a Num constraint on the unit. Though typically for affine transformations a Fractional constraint is also obliged.
Note when drawn filled and drawn stroked the same polygon will have (slightly) different size:
- A filled shape fills within the boundary of the shape
- A stroked shape draws a pen line around the boundary of the shape. The actual size depends on the thickness of the line (stroke width).