source: trunk/third/pango/TODO.xml @ 18248

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