From HaskellWiki
< Diagrams‎ | Dev
Jump to: navigation, search

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).