Removed old file. Filed some bugs out of it.

2006-01-22  Behdad Esfahbod  <behdad@gnome.org>

        * TODO.xml: Removed old file.  Filed some bugs out of it.

        * Makefile.am (EXTRA_DIST): Removed TODO.xml.

3 files changed, 4 insertions, 411 deletions

diff --git a/ChangeLog b/ChangeLog
index 58d8c646..9126136e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -2,6 +2,10 @@
 
 	* TODO: Removed old file.  Filed some bugs out of it.
 
+	* TODO.xml: Removed old file.  Filed some bugs out of it.
+
+	* Makefile.am (EXTRA_DIST): Removed TODO.xml.
+
 2006-01-21  Behdad Esfahbod  <behdad@gnome.org>
 
 	* MAINTAINERS: Added.
diff --git a/Makefile.am b/Makefile.am
index 8810ffbf..f2942985 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,7 +23,6 @@ EXTRA_DIST = 			\
 	ChangeLog.pre-1-6	\
 	ChangeLog.pre-1-8	\
 	MAINTAINERS		\
-	TODO.xml	\
 	README.win32	\
 	pango-zip.sh	\
 	sanitize-la.sh
diff --git a/TODO.xml b/TODO.xml
deleted file mode 100644
index 3e760b32..00000000
--- a/TODO.xml
+++ /dev/null
@@ -1,410 +0,0 @@
-<!-- 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>Determine how to localise numbers</title>
-      <description>
-         Some locales (mainly Arabic and Indic-script languages), 
-         want to localize numbers. How should this be done?
-      </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="small" status="0%" target="1.0?">
-      <title>Error indicator underline</title>
-      <description>
-	It might be interesting to add an error-indicator underline
-	type. (A red squiggle, as seen for auto-spell
-	checking in products like Microsoft Word.) This would
-	mean adding <code>PANGO_UNDERLINE_ERROR</code> to
-	the <code>PangoUnderline</code> enumeration, and then
-	adding the code to draw it to the various renderers
-	for PangoLayout. (Rendering happens in three places now -
-	pangox.c, gtk+/gtk/gtktextdisplay.c gtk+/gdk/gdkpango.c.)
-      </description>
-      <contact>gtk-i18n-list@gnome.org, Gavin Hurley &lt;gavin@audiobasket.com&gt;</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. (For untagged text, a default would
-	  come from user's locale setting.)
-	</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>
-