View source for Gecko2:NewTextAPI

=== Requirements ===

We need a solution to i18n text layout and rendering on each platform.

Since we're trying to use cairo as much as possible, we really want each solution to work with cairo if possible.

We want to depend more on platforms and less on our own fragile i18n code.

The set of solutions we choose should expose a common interface to nsTextFrame, a new GFX interface, part of the nascent "Thebes" APIs [[Mozilla2:NewGFXAPIs]].

The solutions should handle not only existing CSS requirements but also SVG and CSS3 requirements.

I (roc) claim that we do not want to mess with what an nsTextFrame is. In particular, segmentation of text into unidirectional runs can remain as is, at the frame level. CSS text-transform can stay as is. The problem we need to solve is then:
* Input: a string of Unicode text
* Input: (?) Unicode text for the entire block, for context
* Input: language atom
* Input: font specification (including size)
* Input: dominant baseline
* Input: transform matrix (so font can be hinted to device pixel matrix)
* Input: CSS spacing information (justification space, letter-spacing, word-spacing)
* Input: SVG glyph position/orientation override data
* Operation: Measure a substring of the text (ascent, descent, width, leftbearing, rightbearing)
* Operation: Determine where line-breaks may appear within the text
* Operation: Find the longest prefix of the text that fits within a given width
* Operation: Determine which Unicode characters combine to form glyphs (and therefore must be selected atomically)
* Operation: Identify the position and size of each glyph
* Operation: Draw a substring of the text

Some of this work could remain in nsTextFrame, but maybe we should push it all down into Thebes. nsTextFrame is very evil and the more we can shrink it, the better. We could still share code (when appropriate) at the Thebes level.

=== Platforms ===

For Linux/GTK2, the obvious solution is to use Pango/cairo.

For Windows, we'd like to use Uniscribe or fall back to some best-effort code when Uniscribe is not available (possibly a version of our existing code).

For Mac, we should use ATSUI.

Question from biesi: What about other platforms? (OS/2, BeOS)

=== Design ===

Suppose we designed a Thebes API for all the above Inputs and Operations. It would probably grow over time as our CSS and SVG requirements grow but that's OK since Thebes is all us.

Linux/Pango and Windows/Uniscribe could probably share code at the Thebes level.  Pango and Uniscribe can convert a Unicode string to a string of positioned, annotated glyphs; from there we can apply CSS spacing and implement the above operations in shared code. cairo supports drawing a string of positioned glyphs on these platforms, so we can just use that without going back to Pango/Uniscribe.

Mac/ATSUI might need to use a single ATSUI layout object for measurement and rendering, so might need a somewhat different Thebes implementation.

=== Performance ===

We'll be more tied to platform text performance.

We should explore some mechanism for caching the Thebes text layout object in nsTextFrame (which would allow caching of underlying Pango/Uniscribe/ATSUI/font resources). A simple mechanism would be to put the cache in Thebes itself, and use nsTextFrame pointers as abstract keys. When an nsTextFrame was modified, changed style, or destroyed, it would notify Thebes to invalidate any cache entry with that key. We almost certainly don't want to keep a text layout object in every text frame, and the best cache management policy is probably very platform-specific.