Move most all of the TODO items here to the XML file. This needs to be

Sun Aug 20 13:45:08 2000  Owen Taylor  <otaylor@redhat.com>

	* TODO.xml TODO: Move most all of the TODO items here to the XML file.
	This needs to be built using the Python script gtk+/docs/make-todo.

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
+	  &ldquo;neutral&rdquo; 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 &ldquo;ransom-note&rdquo; 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 &lt;otaylor@redhat.com&gt;</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 &lt;otaylor@redhat.com&gt;</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 &lt;otaylor@redhat.com&gt;</contact>
+    </entry>
+  </section>
+</todo>
+