(copy notes on text support over from google code wiki)
m (→Phase 2)
Latest revision as of 01:31, 13 February 2013
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.
 1 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.
 2 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.
 3 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).