Hi,
At Mon, 03 Sep 2001 20:32:17 -0700,
Keith Packard <[EMAIL PROTECTED]> wrote:
> Adding encoding conversion to the basic rendering libraries means that we
> can never be rid of them. I think we can all agree that we'd like to
> reach UTF-8 nirvana at some point.
It is true that we will not able to be rid of them. However, libX11
already has Unicode <-> locale encodings converters which was introduced
for Xutf8* functions. Since Xutf8* functions can never be removed,
libX11 (or other library which is distributed with libX11 - like your
plan) will continue to supply the converter. My idea never increases
the complexity of XFree86. What's wrong with calling the features from
Xft library?
And, even if I agree we'd like to reach UTF-8 world, I think it is a
dream which need long time to achieve.
> You certainly have the freedom to code your software however you feel most
> appropriate. I encourage you to publish libraries and utilities that you
> find useful in such an endevour, please don't expect the rest of us to
> weigh down our internal libraries with functionality we find unnecessary.
>
> Placing such conversions inside Xft doesn't make mb/wc approaches any
> easier to write, it only forces the rest of the world to pay your price
> for compatibility with legacy i18n software.
It makes mb/wc approach easier. Mb/wc softwares can completely
free from encoding handling. Since mb/wc softwares support UTF-8
also, I cannot understand why you don't like this approach.
Think about the number of (1) XFree86, (2) wrapper libraries such
as Qt and Gtk+, and (3) application softwares. Obviously there
is only one XFree86 distribution. There are a few major wrapper
libraries. There are a lot of application softwares. Now, many
applications need encoding conversion. Which layer is the best
to reduce the Reinvention of the Wheel? I.e., to reduce the number
of large encoding tables in a system, which layer of (1), (2), or
(3) is appropriate to implement the converter? The answer is
obviously (1).
> Pango and Qt needn't bother with mb/wc API's for rendering; they also
> insist that callers convert data to Unicode.
That's too bad. Then you cannot suggest me to use Pango/Qt for
the purpose we are discussing now.
> > I am grad that you agreed that unicode + display engine + _iconv_ is
> > full i18n. I'd like people here to confirm this idea.
>
> As long as we all agree on this point, I think the arrangement of which
> library does which part of the work can be dictated by our own good
> judgement.
Then which layer is appropriate for encoding conversion, do you think?
---
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
