--- Tomas Frydrych <[EMAIL PROTECTED]> wrote: > > > Joaquin Cuenca Abela wrote: > > Tomas, can you also clarify this point? > > I don't see why UTF-8 is unsuitable for the > piecetable. > I want the piecetable and layout engine to be > optimised for speed; > variable character width requires extra processing, > that's why I do > not think it is a good encoding to use here.
I want the piecetable and layout engine to work for all the world's languages. Being optimized for speed is also good. I won't sacrifice #1 for #2. Microsoft Word handles these things well. I am not interested in working on a Word Processor that does not try to equal and beat Microsoft Word. > > UTF-8 has another advantage over UTF-32. In the > gtk & the qnx > > frontend, the format used to output text is UTF-8, > so we'll not need > > to do any conversion to get text displayed. win32 > uses UTF-16/UCS-2 > > (in funcion of the registry?) so anyway you need > to do a conversion > > from UTF-8 or UCS-4 to UCS-2. > We need to make a distinction between the GUI (the > menus and > dialogues, etc) and the main editing space. We are > going to > implement the main editing space using FreeType, > which means > we will not use any calls to the native text drawing > routines. > FreeType API uses unsigned long for Unicode > characters. For the > GUI we will need to use what-ever the OS requires, > and here I > agree that UTF-8 is the logical way to store the > static strings. Well maybe FreeType, maybe Pango. The Gnome guys definitely want us to use Pango: http://news.gnome.org/gnome-news/1016233970/1016357145/1016387936/addPostingForm Andrew Dunbar. > Tomas ===== http://linguaphile.sourceforge.net http://www.abisource.com __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
