Diagrams/Dev/Text

See issue 29.

Issues making text support difficult:

• Diagrams are scale-invariant, but text is not really scale-invariant for several reasons:
  • Glyphs can be different for different font sizes
  • Users might not actually want font size to scale along with a diagram, for the same reasons that they might not want line width to scale -- it requires non-local thinking to get all the sizes to match up.
• Fonts are complicated.

Below is a suggested plan of attack for font support.

Phase 1

• Font size is an attribute just like line width. However, in Phase 1 font size will not be affected by transformations _at all_, even in frozen diagrams. (See phase 2 below).
• Text objects take up no space. To leave a fixed amount of space, text can be composed with e.g. a phantom box. Combinators can be provided to make producing such a text + phantom box easy.
• Diagrams does not know anything about fonts, other than having a font attribute. Selection and rendering of fonts is left up to backends.

Phase 2

• Allow "reification" of text into a path. Obviously this requires being able to deal with fonts. There are some issues here to be worked out re: IO/purity. (For the Cairo backend, it seems Pango can do this.)
• Freezing a diagram results in reification of any text objects.
• With respect to spacing/bounds:
  • Explicitly reifying a text object into a path will result in a normal path with a normal bounding function.
  • However, text objects which are implicitly reified into a path using "freeze" take up no space.

Phase 3

• Text objects take up a variable amount of space, depending on the final scaling factor. Solve for the positioning and spacing of diagrams using a constraint solver.
• This phase requires some sort of constraint-solving module first (issue 12).