--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 20, 2000 at 07:03:20PM +0000, Robert Brady scribbled:
| On Thu, 21 Dec 2000, Noriyuki Soda wrote:
| > As I repeatedly said here, the feature that Xutf8 APIs provide=20
| > can be provided by already existing Xwc/Xmb APIs by the following=20
| > code fragment:
| > 	current_locale =3D setlocale(LC_CTYPE, NULL);
| > 	setlocale(LC_CTYPE, NAME_OF_en_US_UTF_8_locale);
| > 	... create Unicode FontSet here ...
| > 	setlocale(LC_CTYPE, current_locale);
|=20
| And it has been repeatedly told to you why we do not consider this a
| viable option.
|=20
| If you'd care to address those points, please do so.

As the person importing the FreeBSD wchar* functions from CITRUS,
I think I can perhaps explain the issues here :

Here are the _techinical_ discussions:

1. Hardwired API is bad techinical judgement
The BSD/*Nix/Linux* ages old assumption of ASCII chars in the=20
whole OS has hurt us for years.  They basically hardwired
C locale into the system, and made assumptions on that.=20
Well, I think we can all agree that was a bad idea.=20
So why are we defaulting to UTF chars now?  What is different
from hardwiring UTF to hardwiring C? Can we not simply
implement something that is much cleaner than hardwired API's?
See also:
http://www.xfree86.org/pipermail/i18n/2000-December/000796.html

2. Unicode/UTF-8 is not very satisfactory
I know they are the viable choices, but they do not include=20
all the support for all of the characters.  Chinese
has 50000 frequently used glyphs, Unicode has less than half that.
Unicode does not even attempt to address the problems with
zh_TW and zh_CN locales.  zh_TW.Big5 and zh_CN.GB shares
some glyphs, but the same meaning may be generated by two
different looking glyphs.  They are not mutually compatible
in original form or in Unicode.  i.e.=20
zh_TW -> Unicode -> zh_GB is NOT possible, and vice versa

One day, we may decide that UTF8/Unicode is not sufficient,
why don't we go the clean solution and pave way for the future?
(Is that not good software design practices?)

3. Xutf* breaks CJK encodings and other languages
Why someone would want to intentionally kill a userbase?
CJK legacy encodings are here to stay no matter what we say.
Consider this, if one of the CJK XFree86 developers committed=20
something that broke Russian, French, and ISO-8859* support, what would
we be talking about now? =20

4. Legacy Support for windowmanagers, X applications, toolkits.
You are asking the entire X world to change according to you.
Do you have any idea how many people would have to change literally
millions of lines of code just so that they conform with your API?

There is already a clean way of handling locales, and you refuse
to believe its techinical merit.

5. Adding the Xutf* API in the middle of discussion
The commit was made during the flame war^W^Wdiscussion.
I seem to recall XFree86 having a monolithic development system.
(i.e. core team, developers, peer-evaluation, et al.)

6. People are not going to use this API?
http://www.xfree86.org/pipermail/i18n/2000-December/000802.html
This is not about immediacy, this is about techinical competence
and superiority.

7. Not X.org API
http://www.xfree86.org/pipermail/i18n/2000-December/000807.html
Is this not _X_Free86? Why do you not want to conform to a=20
standard X.org API?  You keep asking for technical merit,
please explain the techinical merit in that.
If you could also explain to me why everybody conforms to IEEE802*
RFC's and such, that would be nice.

8. Let's change the world! _NOT_
http://www.xfree86.org/pipermail/i18n/2000-December/000589.html
Microsoft will not change, neither will MacOS, nor most of
the commercial vendors. =20

9. Denying someone's proposal without giving Techinical Reasons(TM)
http://www.xfree86.org/pipermail/i18n/2000-December/000756.html
And no unncessary political jokes please.
=3D=3D

In conclusion, Xutf* is simply just a *bad* idea.  Please
return the email with the techinical discussions that you have
requested so often.

One last note: Traditional CJK culture usually appeals to emotions
even while having other techinical suggestions.  Please do not
discriminate against cultures.

Thanks,
Michael
--=20
+------------------------------------------------------------------+
| keichii@peorth.iteration.net         | keichii@bsdconspiracy.net |
| http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
+------------------------------------------------------------------+

--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: o5JXpfCEYWh+GlpWlkfPt3hAl4mzjOaN

iQA/AwUBOkEZI3fOKcWPoS4gEQIS7QCZAR0S5g4mDTXPtonU82o/qiQOO7IAoO8Y
A4RQL/KUU6GrhIRGRpOrJJFF
=0K6+
-----END PGP SIGNATURE-----

--+QahgC5+KEYLbs62--