Implementation issues:

* Add const keywords all over the source.

* with --without-charsets, fribidi char set converters use iconv internally.

* Update CapRTL with new Unicode reference version.

* Revise Reorder api, in fribidi_main.c reorder after link break.

* Add an option to fribidi_main.c to assume two consecutive returns as
  paragraph separators.

* Change fribidi_main.c to act like 'bidiv' if argv[0] == "bidiv".

* Fix iconv problem: Check for old iconvs (without wchar_t, without
  byteorder UTF-32 or UCS-4 types).

* When there is no glibc, libiconv should be linked when --without-charset
  is enabled.

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

* Revise fribidi_util.c, add some functions, update other to support explicit
  marks, and too many embedding levels, eg. fribidi_map_range.

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

BiDi algorithms issues:

General issues:

* Better documentation.

* 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?