Pangoification Discussion ------------------------- This is a summary of a discussion between mental, bulia and fred on Jabber regarding adoption of Pango and the issues involved.

The principle issue we are facing at this time is that while many of the Pango issues we've identified seem to have doable work-arounds, it's become a little unclear what our eventual goal design-wise is with it in the long term. Specifically, Pango likes to grid-fit its layouts, which makes it a bit inflexible for things like getting undistorted outlines and layouts.

Vertical Text ============= Pango does well with horizontal text but Fred had a question about how multi-byte characters are handled. E.g., an A with an umlaut requires two bytes. Would this render as a single character entity or as two? Certainly we wouldn't want the system to resort to putting the A and umlaut on separate lines.

Mental explained that Pango provides routines for determining how many "codepoints" makes up a particular character. When you pass this routine a UTF-8 string pointer, it will return the pointer advanced by the next full character. A codepoint can consist of one or more bytes. one or more codepoints define a 'glyph'. One or more glyphs define a character.

A glyph like an umlauts is an example of a "composing character". Fonts combine these composing characters with other base characters to form the various characters particular to a given language.

It looks like pango_layout_move_cursor_visually() would be used to determine the positioning of vertical text. This won't be simple if we don't use the Pango glyph positioning. For more info see: http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html#pango...

For our own work this suggests we may need to create PangoLayouts to do our own specialized layout.

Kerning Abilities ================= Control over font kerning is important for Inkscape yet it is uncertain if Pango provides this control. For letter spacing we need to be able to:

* Measure strings * Count characters * Handle pairwise kerning * Glyph width (for things like text-on-path)

Currently, sp-chars creates a NRArenaGlyphGroup for each string, tied to one NRRasterFont, but for things like text-on-path we'll want to have unique transforms for each character. We do not want to have to create a separate GlyphGroup for each glyph though, so need a better solution to this.

The question came up about whether we can eliminate NRRasterFont. This appears to be a necessary step in the pipline, because it is where the transform is taken into account and where glyph caching occurs. There is a question about whether glyph caching is really necessary, or if we could do direct rendering and use performance analysis to determine where such optimizations are really necessary, but since text always has such massive redundancy, caching is likely to prove quite necessary.

Win32 Testing ============= We've very concerned that bugs in font handling are going to reproduce quickly on different platforms unless they're closely tracked by developers on those platforms. Is adopting Pango worth enduring those platform issues?