Implementation issues:

* Currently one need to run "bootstrap" two times, to generate "config.h"
  containing "PACKAGE" and "VERSION" defined, (to roozbeh: would you please
  have a look).

* Set autoconf to use fribidi_mini_glib, to compile with DEBUG, and other
  define symbols, and it can set FriBidiStrIndex to be guint32 instead of
  guint16, define FRIBIDI_MAX_STRING_LENGTH based on sizeof(FriBidiStrIndex).

* Design better apis to do reorder based on available levels, remove
  explicit marks then calculate position maps, ....

* Design some tests for each character set.

* Charset convertors and fribidi_analyse change API to allocate mem if
  NULL is passed to them.

BiDi algorithms issues:

* Handle the L3 rule.

General issues:

* Better documentation.

* Write some utility programs.

* Write notes and a reference implementation for the following interactions
  with fribidi:

    - Terminal editing with cursor key interaction, e.g. through curses.
      No mouse or cut and paste interaction.

    - Like above (with fixed width fonts?) but in an GUI environment
      where the mouse may be used to position the cursor.

    - Like above but with the ability to do a mouse selection. At least
      in logical mode, possibly in visual mode.

    - Like above but with proportional fonts.

    - Like above with proportional fonts and character attributes.

    - Like above but with kerning between characters.

* Write a description of the needed steps to convert a LTR editor into a
  BiDi aware editor.

* Make interfaces to other scripting languages if there is any interest.

* Consider the implications of a minimal incremental algorithm for
  adding a single character.

* Add handling of precomposed and presentation unicode chars when converting
  to 8-bit encodings (breaking into several chars, or better match)

* Persian 8-bit encoding ISIRI-3342 has the notion of strong typed chars like
  spaces etc (all the characters in the range 0x00-0x7f are strongly typed
  left-to-right, and sometimes have duplicates in 0x80-0xff as a strongly
  typed right-to-left version.  several chars in the range 0xa0-0xbf have
  exact unicode counterparts; but others (and all in the range 0x80-0x9f,
  and 0xff) have not; so how should that be handled when converting to
  unicode to preserve at best the direction information?

----

mini_glib use < received from Dan K... >

* test executables with mini_glib 
* build execs in Makefile_mini_glib
* create a shared-object library

*** add the mini_glib option to configure, so that whenever no glib is arround,
    mini_glib is used.

* use smarter malloc/free scheme, even with mini_glib