Pango Status Report #2      9 Feb 2000
======================================

General news:

 http://www.pango.org is now online. Thanks to Raph for hosting the
 site on his machine.

 What's up there now is mostly what was on my older pages, but with
 nicer formatting, a more complete design section, and updated API 
 docs.


Recent progress:

 In the last few weeks, I've been concentrating my efforts 
 on the font system, both for the rendering-independent
 interfaces and for X.

 The general design for the font independent stuff is pretty 
 similar to lots of existing systems ... whether Java or
 gnome-font. The exact set of properties is based most
 closely on the font properties from CSS2.

 You can check out the API for this at:

  http://www.pango.org/api/pango-fonts.html

 The X work I've done is mostly implementing this API for the X
 platform, and also improving the selection algorithms for finding
 XLFDs to match a particular PangoFontDescription and size. (I'm now
 just listing all fonts from the X server with XListFonts() and
 doing all the matching client side.)

 The other thing I've been working on is getting fonts to report
 their own coverage maps. This will allow better handling of 
 selecting fonts with fallbacks to other fonts for character
 points not handled by the first font.
 
 The implementation of this is pretty much complete, though it isn't
 yet used by the shaping core.


Releases:

 Pango-0.6 is on available from www.pango.org. The big change is 
 the font stuff. I've also (with Tom Tromey's permission) made a
 release of libunicode from CVS and put it there to make it easier
 to get Pango compiling. 


TODO highlights:

  The projects I intend to tackle next are:

   - Finish up the font stuff API by adding list_families() and list_sizes()
     calls.

   - Make the shaping core use the font coverage code; this will
     involve attributing the text fed into the pango_itemize() with
     font information as well as the current language tags.

   - Change the engine lookup code to be a bit more general than the 
     current mechanism which hard-codes the types of engines available.

  After that, I intend to move on to working on Pango in a GUI enviroment.
  I'll probably simply make a branch of GTK+, start pushing in Pango and
  see what happens.

  Some interesting projects that other people might want to consider:

   - Write a libart based font-system and renderer to go along with
     the X based one. It would be good to have an idea about how
     well the interfaces work with something other than X before
     we get too far along.

   - Write an Arabic shaping module. A simple one shouldn't be too bad.
     With the Tamil and Korean modules, we are already doing more
     sophisticated stuff than are necessary for shaping Arabic characters
     for X, and the basic module already does simple bidirectional 
     reordering for glyphs.

     (caveat: the module interfaces are not currently very documented,
     so this would involve lots of reading code and exploration)

   - Write a shaping engine for whatever language you are interested in.


Misc stuff:

  Another interesting development is that Havoc Pennington has started
  working on a port of the TkText widget to GTK+. (We needed a 
  more sophisticated text widget for various things we are working on
  here at the Red Hat.) Initially I thought that a port of that widget
  wouldn't be appropriate for a Pango-based system, and I'd also be 
  starting over on a new text widget for Pango/GTK+. But having talked
  to Havoc a bunch about the design, it looks like moving that code
  base to Pango would work pretty well:

  There is a pretty clean separation between text storage - which would
  be done before shaping and reordering, and text display, which would be
  done after shaping and reordering. Also, the text storage is essentially
  paragraph-based, which works well as a unit for bidectional reordering.
  Finally, the text storage is already in UTF-8, so no conversion would
  be needed there.

Owen Taylor
  


Last modified 31-May-2000
Owen Taylor <otaylor@redhat.com>