Hi,
At Sun, 2 Sep 2001 12:32:17 +0200,
Pablo Saratxaga <[EMAIL PROTECTED]> wrote:
> Xft in unicode only is simple and thiny; is conversion mechanism should be
> added it will be fat very quickly, it will add extra requirements on iconv
> library, etc.
> It would make sense to have that layer in a separate library, not in Xft api
> itself, as that functionality will be needed only by a small portion of
> old programs only.
I think this is the focus of your opinion. I agree that encoding
conversion mechanism will be fat. However, _this_ is why I think
the encoding conversion mechanism should be added to some very
basic libraries. Otherwise, because encoding conversion is
needed by all Unicode-based i18n softwares (for I/O) and by
all mb/wc-based i18n softwares (for Xft), many libraries and
many applications will independently develop and have such fat
conversion mechanisms, which is a waste of resource and a
source of bugs.
The best way would be that all libc would have relyable and
portable iconv() and XFree86/Xft could use it. This didn't
occur. However, fortunately, libX11 has a portable encoding
conversion mechanism. It is portable and relyable, which is
why Juliusz develops luit using it. Since Xft is a part
of XFree86 distribution, it is always avaiable. (Compilation
option not to support conversion in libX11? Then the option
can be supplied also to encoding conversion for Xft.)
Why not use it?
I agree that it is our freedom to write Unicode-based softwares
provided that these softwares support LC_CTYPE for stream I/O.
However, I cannot remember that members of this mailing list
have not stated whether they are for or against my opinion that
we have freedom to write mb/wc-based softwares. I understand
they *recommend* people to write Unicode-based softwares because
it is (they think) easier to write. However, it is *they* who
feel Unicode-based approach is easier than mb/wc-based approach.
There are people who feel opposite to them.
> But unicode + display engine + iconv is full i18n, more i18n than current
> mb/wc display functions which are unable to handle right to left scripts,
> and complex ligaturing scripts.
This is true now. However, this is due to the display engine (Xft).
If Xft has mb/wc APIs, mb/wc applications will have the identical
power to handle RTL and complex scripts. And, don't Pango and Qt
supply mb/wc APIs? (I just don't know.)
I am grad that you agreed that unicode + display engine + _iconv_ is
full i18n. I'd like people here to confirm this idea.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
