Support for correct positioning at cluster boundaries has not yet been implemented. In some languages, like Arabic, the cursor can be positioned within a cluster. In other languages, notably the languages of Southeast Asia, such as Thai, positioning within a cluster is incorrect. A single arrow key press should take the cursor over the entire cluster.

In Pango currently, only the first mode is implemented. The commands to do keyboard cursor motion (such as pango_layout_move_cursor_visually()) move over entire clusters, and the functions between x/y and indices in the text buffer always return the character boundaries not cluster boundaries.

The way this probably should work is that the trailing parameter to functions such as Pango_layout_index_to_x() should return, for such scripts, 0 or the number of chars in the cluster rather than 0 or 1.

Handling of cluster/line/word breaks needs to be improved. Pango provides an interface for providing script-specific modules for doing such boundary resolution, but doesn't actually call the modules at present when doing break detection. Beyond this simple-to-fix oversight, both the default algorithm and script-specific algorithms need improvement. A better default algorithm is described in the Unicode 3.0 specification; that algorithm gets word motion correct in CJK scripts which the current algorithm doesn't. Having languages-specific algorithms for languages that need them, such as Thai, would also be nice.

Support needs to be added for identifying characters as “neutral” with respect to the choice of language engine, needs to be added. Currently, a block of, say Arabic text, will be split into one-word runs of Arabic, with intervening one-character runs for the Basic shaper for the space character. This is, as might be imagined, a fairly major performance problem. In addition, it would be nice to improve the coherency of font choice across larger blocks of text to avoid “ransom-note” effects. Currently, if a single character in a block of text needs an accent not in the default font, then only that character will be chosen from a different font, which looks poor. (The other solution is simply to make sure that the default fonts are have reasonably complete sets of accents.)

• pango_glyph_string_set_size() does not handle the fact that n_glyphs can be less than n_chars!
• pango_context_list_fonts() does not properly suppress duplicates when multiple font maps are involved

• settle on either _free or _destroy
• s/num_chars/n_chars/ etc. (Always use n_ as enumeration prefix)
• change pango_context_set_size() to pango_context_set_font_size()
• Remove the extraneous font argument from the script_shape virtual function in ShapeEngine.

Pango needs support for additional writing directions. In the initial version of Pango, support is only present for right-to-left and left-to-right text. However, vertical writing is also important in many applications.

One reason why vertical text has not been implemented in Pango-1.0 is that the target rendering system, X, has week facilities for handling text in other than a horizontal location. The obvious, though not the only, way of treating vertical writing is to keep the logic in PangoLayout the same, but to have an implicit transformation of the coordinate system. Doing it this way, the only extra code in Pango that is needed is to transform glyph metrics as appropriate. (some characters will rotate, some not), and also to handle selecting appropriate glyph variants when a font has separate variants for vertical and horizontal text. (CJK punctuation being a common example of this.)

The current use of UTF-8 internally needs to be reevaluated. Using UCS-4 would not have much memory overhead, since PangoLayout objects are not kept around in most cases. This change would simplify the internal code, and might make Pango more palatable to use for people who represent characters using UCS-2 or UCS-4 (for instance Java). (Note that mapping position in a UTF-16 string to and from position in a UTF-32 string is still an O(n) operation.)

The main problem is that the current interfaces for mapping glyph position to and from byte offset would become O(n) and new interfaces would have to be added to map to and from character index. The worst breakage would be in the PangoAttribute interfaces, where byte offsets are directly exposed in structures.

pango_layout_context_changed() is a hack. Either the context should have change-notification, or else the layout should make a copy of the context when the context is set. Use signals for change-notification needs to wait on GSignal getting finished.

Support should be added to Pango for alternate line-break algorithms. Currently the PangoLayout object supports on the simplest greedy algorithm for line breaking, and has no concept of hyphenation. While this is sufficient for simple applications such as text editors and entry widgets, it is is not sufficient for use in such settings as page-layout programs and even word processors.

There are essentially two parts to this. First, we need to add ways of getting sufficient information about how the text behaves when hyphenated. We need some way of being able to determine the glyph deltas when the line is broken at a particular position. The second part is adding a mechanism to allow customizing the line-break algorithm of PangoLayout. This probably should be done by allowing PangoLayout to be subclassed.

Support for language tagging and for selecting appropriate glyphs for a user's locale is not yet complete. The shaping engine needs to modify the fonts it chooses based on the language tag for text. (For untagged text, a default would come from user's locale setting.)

Pango needs to have well-integrated support for a sophisticated font system such as OpenType. The reference font implementation for Pango 1.0 has been X fonts, which really are not up to either producing high-quality output or providing sufficient information for internationalization. X fonts don't provide information about available ligatures or alternate glyph forms. They don't provide information about baseline positioning. They don't provide information about how to attach composing accents to base characters.

Right now we assume a single resolution for all fonts on a display; but in theory, the resolution could be per-screen. To solve this, we would probably want to add a window argument to pango_x_get_context() and then have some sort of X specific font loading interface.

• It is not clear that X is interpreting the ink_rect the same way as we are. There is a bit of fudging in the underline drawing code to deal with this and make the underlines look symetric.

The process of writing a shaper needs to be documented. I've started on this a bit already, and the Thai shaper was written to serve as a straightforward example for this document.

Much or all of the X Fonts document from pango.org needs to be moved into the API reference.

When the GNOME bug tracker is reliable again and moved to something like bugzilla, some of the small items on this page should be moved there. This page should really be about only major areas of enhancement.

Set up pango-list@pango.org (redirect to pango-list@gnome.org). Some people are apparently not wanting to send general Pango questions to gtk-i18n-list.