Text abstraction level

Nobody has claimed this yet.

Related to https://github.com/linebender/piet/issues/10: what is the right level of abstraction for text handling that should be provided through the `piet::RenderContext` trait? (And so by every Piet backend.) What should be left to the user, or to separate libraries in the Druid ecosystem that work on top of Piet?

There are three options that I think make sense for enabling high-quality text:

* **Low level: glyph runs.** In cairo this is `cairo_show_glyphs`.

Backends can render a sequence of positioned glyphs, all in the same font face. No text layout is done at all.

Open question: is it in scope to provide access to glyph metrics and other data from fonts?

Bonus: for backends whose output have semantics in addition to visuals (e.g. supporting text search (CTRL+F) in, or copy/paste from, a PDF file generated by a Piet backend), a way to associate a Unicode string with each glyph run. In cairo this is `cairo_show_text_glyphs`.

* **Mid level: text spans.** Or should we call them segments? This is Skribo. (Maybe also Pango’s low level?)

Backends can render a Unicode string that shares a single bidi direction, (also Unicode script?), styling (color or brush, size, weight, stretch, italic, letter-spacing, etc), and ordered list of preferred font families. This does text layout including complex shaping and font fallback. (For example an English sentence with emoji will likely use two font faces.)

There’s a notion of *collections* of fonts available for a given layout. Ideally with a choice of whatever fonts are provided by the system/environment, specific fonts provided by the user/application, or both.

Also useful: rendering only a substring, computing its advance “width”, mapping a position in rendering space back to an index in the Unicode string.

* **High level: paragraphs.** In Pango this is `PangoLayout`.

Backends can render some rich text structure where different parts of the text can have different styles or font preferences, with some space constraints like “available width”. In addition to shaping and fallback, bidi and line breaking are taken care of.

Ideally when a higher level is provided for convenience, all lower levels should also be available for users who want more control. However this may be a problem for the web backend in particular: glyph rendering is simply not available, if using the browser’s fonts and text handling at all.

Start by reading the piet::RenderContext trait and the related piet issue 10. Compare the low-level glyph run, mid-level text span, and high-level paragraph options described here, including the web backend constraint. Done means reaching agreement on the abstraction level and the scope of the RenderContext text API.

Written by the indexing model from the issue text.