Around 8 o'clock on Sep 4, Tomohiro KUBOTA wrote:
> 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.
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.
> The best way would be that all libc would have relyable and
> portable iconv() and XFree86/Xft could use it. This didn't
> occur.
Feel free to write a conversion library that uses either iconv or the
built-in Xlib conversion code. Then your application can read/write files
using your current locale and you can call Xft with the unicode it so
richly deserves.
> 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.
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.
> 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.)
Pango and Qt needn't bother with mb/wc API's for rendering; they also
insist that callers convert data to Unicode.
> 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.
[EMAIL PROTECTED] XFree86 Core Team SuSE, Inc.
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
