diff options
Diffstat (limited to 'TODO.xml')
| -rw-r--r-- | TODO.xml | 388 |
1 files changed, 388 insertions, 0 deletions
diff --git a/TODO.xml b/TODO.xml new file mode 100644 index 00000000..45f423c3 --- /dev/null +++ b/TODO.xml @@ -0,0 +1,388 @@ +<!-- This is used to generate the online TODO list for GTK+ using + the script docs/make-todo. Whenever a change to this file is + committed to CVS,the file is run through make-todo and the online + version updated. If you modify this file, you should check for + parse errors by running: + + $ docs/make-todo TODO.xml > /dev/null + + before committing, or you may screw up the online version --> +<todo> + <title>Pango TODO list</title> + <section> + <title>Pango Core</title> + <entry size="medium" status="0%" target="1.0"> + <title>Support proper cluster boundary positioning</title> + <description> + <p> + 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. + </p> + <p> + In Pango currently, only the first mode is implemented. The + commands to do keyboard cursor motion (such as + <function>pango_layout_move_cursor_visually()</function>) + move over entire clusters, and the functions between x/y and + indices in the text buffer always return the character + boundaries not cluster boundaries. + </p> + <p> + The way this probably should work is that the trailing + parameter to functions such as <code>Pango_layout_index_to_x()</code> + should return, for such scripts, 0 or the number of chars + in the cluster rather than 0 or 1. + </p> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + <entry size="medium" status="0%" target="1.0"> + <title>Improve handling of boundary resolution</title> + <description> + <p> + Handling of cluster/line/word breaks needs to be + improved. Pango provides an interface for providing + script-specific modules for doing such <em>boundary + resolution</em>, 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. + </p> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + <entry size="medium" status="0%" target="1.0"> + <title>Improve shaper and font determination algorithms</title> + <description> + <p> + 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.) + </p> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + <entry size="medium" status="0%" target="1.0"> + <title>Squash bugs</title> + <description> + <ul> + <li><code>pango_glyph_string_set_size()</code> does not + handle the fact that n_glyphs can be less than + n_chars!</li> + + <li><code>pango_context_list_fonts()</code> does not + properly suppress duplicates when multiple font maps are + involved</li> + </ul> + </description> + </entry> + <entry size="small" status="0%" target="1.0?"> + <title>Fix API inconsistencies</title> + <description> + <ul> + <li>settle on either _free or _destroy</li> + + <li>s/num_chars/n_chars/ etc. (Always use n_ as enumeration + prefix)</li> + + <li>change pango_context_set_size() to + pango_context_set_font_size()</li> + + <li>Remove the extraneous font argument from the + script_shape virtual function in ShapeEngine.</li> + </ul> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + <entry size="medium" status="0%" target="1.0?"> + <title>Handle error reporting better</title> + <description> + The entire API needs a review for cases where errors should + be propagated back to appliciations. (There is no point + in propagating programming-error errors, like incorrectly + <code>NULL</code> pointers back, those can just be warnings. + For the place where interesting errors should be reported, + we should use <code>GError</code>. + </description> + </entry> + <entry size="big" status="10%" target=">1.0"> + <title>Add support for additional writing directions</title> + <description> + <p> + 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. + </p> + <p> + 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 + <code>PangoLayout</code> 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.) + </p> + </description> + </entry> + <entry size="big" status="0%" target="> 1.0"> + <title>Consider moving to UCS-4 internally</title> + <description> + <p> + The current use of UTF-8 internally needs to be reevaluated. + Using UCS-4 would not have much memory overhead, since + <code>PangoLayout</code> 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.) + </p> + <p> + 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 + <code>PangoAttribute</code> interfaces, where + byte offsets are directly exposed in structures. + </p> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + </section> <!-- Pango Core --> + <section> + <title>PangoLayout</title> + <entry size="small" status="0%" target="1.0"> + <title>Implement the spacing parameter</title> + <description> + The spacing parameter needs to be implemented as illustrated + in the API docs. this should be a quick (10 minute) addition. + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + <entry size="small" status="0%" target="1.0"> + <title>Optimize right-alignment for a single line</title> + <description> + When width == -1 and there is only a single line, then a lot + of the <code>PangoLayout</code> code makes an + unecessary call to <code>pango-layout_get_extents</code>. + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + <entry size="medium" status="0%" target="1.0?"> + <title>Deal with proper change notification for PangoContext</title> + <description> + <p> + <code>pango_layout_context_changed()</code> 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 <code>GSignal</code> getting finished. + </p> + </description> + </entry> + <entry size="medium" status="0%" target="> 1.0"> + <title>Add support for alternate line-break algorithms to <code>PangoLayout</code></title> + <description> + <p> + Support should be added to Pango for alternate line-break + algorithms. Currently the <code>PangoLayout</code> + 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. + </p> + <p> + 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 <code>PangoLayout</code>. This probably + should be done by allowing <code>PangoLayout</code> + to be subclassed. + </p> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + </section> > <!-- PangoLayout --> + <section> + <title>Shaper Modules</title> + <entry size="medium" status="0%" target="1.0"> + <title>Improve support for language-sensitive glyph selection</title> + <description> + <p> + 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, defaulting to the user's locale. + </p> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + </section> + <section> + <title>Fonts and Rendering</title> + <entry size="big" status="10%" target=">1.0"> + <title>Add support for a sophisticated font system</title> + <description> + <p> + 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. + </p> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + </section> + <section> + <title>PangoX</title> + <entry size="medium" status="0%" target="> 1.0"> + <title>Handle multiple screens</title> + <description> + <p> + 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 + <code>pango_x_get_context()</code> and then have some sort of X specific font + loading interface. + </p> + </description> + </entry> + <entry size="medium" status="0%" target="???"> + <title>Fix pangox.c/get_font_metrics_from_string()</title> + <description> + <code>pangox.c/get_font_metrics_from_string()</code> needs to gutted and + replaced with using pango_itemize(); to support this, we need + the ability to specifiy a particular font to use when itemizing. + This probably means adding a attribute type which contains + a PangoFont *, and overrides the description. + </description> + </entry> + <entry size="medium" status="0%" target="> 1.0"> + <title>Handle on-the fly changes to the available fonts</title> + <description> + We don't handle the case where the set of fonts on the server + changes, either for the cached list of fonts, or for for the + information cached on the PANGO_COVERAGE_WIN on the X server. + Fixing this is not easy - even if Pango tracks the change, + applications may have the old set of fonts stored. + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + <entry size="small" status="0%" target="1.0?"> + <title>Improve handling of unknown characters</title> + <description> + Currently unknown characters (characters not present in any + of the available fonts) are shaped with the unknown glyph + from one of the subfonts in the fontlist. Unfortunately, + some fonts have invisible unknown glyph glyphs. We could + fix this in various ways. First, we could institute a + policy of drawing glyph 0 as an actual rectangle. Second, + we could shape unknown glyphs to something more informative + like [U2341]. Finally, we could look into using a font + of substitute glyphs that indicate graphically some information + about the substituted glyph like the block it comes from. + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + <entry size="small" status="0%" target="1.0"> + <title>Squash bugs</title> + <description> + <ul> + <li>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.</li> + </ul> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + </section> <!-- PangoX --> + <section> + <title>Documentation</title> + <entry size="medium" status="20%" target="1.0"> + <title>Document writing a shaper module</title> + <description> + <p> + 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. + </p> + </description> + <contact>Owen Taylor <otaylor@redhat.com></contact> + </entry> + <entry size="small" status="0%" target="1.0"> + <title>Integrate X fonts design doc into API docs</title> + <description> + <p> + Much or all of the X Fonts document from pango.org needs to be moved + into the API reference. + </p> + </description> + <contact>Owen Taylor <otaylor@redhat.com></contact> + </entry> + </section> + <section> + <title>pango.org infrastructure</title> + <entry size="medium" status="0%" target="n.a."> + <title>Move bugs from TODO list to bug tracker</title> + <description> + <p> + 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. + </p> + </description> + <contact>gtk-i18n-list@gnome.org</contact> + </entry> + <entry size="small" status="0%" target="n.a."> + <title>Set up pango-list@pango.org</title> + <description> + <p> + 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. + </p> + </description> + <contact>Owen Taylor <otaylor@redhat.com></contact> + </entry> + </section> +</todo> + |