path: root/TODO.xml

<!-- 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="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>