SC22/WG20 N922 From: Ulrich Drepper [drepper@redhat.com] Sent: Thursday, March 28, 2002 8:44 PM To: Winkler, Arnold F Subject: comment regarding 14652 It has been brought to my attention that one side of the discussion about the continuation of ISO/IEC DTR 14652 is using the GNU C library as an argument. For those who don't know me, I'm the maintainer and main developer of the GNU C library (glibc) and I'm also responsible for developments like GNU gettext. Nobody but me worked on the architecture of the i18n support in glibc so what I'm writing here cannot be disputed. When I started in 1996 adding i18n support I soon realized the, how to put it nicely, limitations of the original POSIX model. Not all required functionality could be implemented with support from the locale. Examples are the wcwidth()/wcswidth() interfaces, transliteration support in iconv(), better default (esp for printers -> paper format). When at that time Keld Simonsen sent me one of the very early drafts for 14652. It contained support for some of the functionality I was missing and inexperienced (both the i18n issues and the user's acceptance of them) I included support for large parts of the draft in glibc. The result was in glibc version 2.1. Today the code is still present (and it will continue to be so) and some of the extensions are actually in use: - the transliteration information is used in iconv() as one possible transliteration mechanism - the paper width/height information is used to make intelligent guesses regarding the default paper format - the character width information is used to implement wcwidth()/wcswidth() - some of the LC_COLLATE input format extensions are needed to more intelligently implement ISO 14651 There might be some other uses which currently slip my mind and some which users of glibc found useful. There are a number of points to note: 1. The fact, that I implemented the extensions back in 1998/1999 does not mean that I endorse the draft standard. It only means that I needed something and used what was available. 2. I have not changed the implementation to follow any of the changes made after the draft I based my work on. This does not mean that I followed that draft blindly in the first place. It contained requirements which didn't make any sense or were contrary to my experiences. As mentioned, I didn't consider the usability aspect back then. 3. Since the time the changes to glibc were made I've learned about the true extend the locale functionality is really used. Most of the proposed new functionality is even less useful than what is already in the POSIX locale. Adding these features would just add costs without the slightest benefit. I am eager to make some more locale information available to users but it first has to be determined who needs what and how it would be used. This all has to wait until the global POSIX locale model is changed. But I digress... The point I'm trying to make here is that nobody should take the argument "glibc uses it" serious. If I as the author who should be the strongest defender say this you might want to believe it. Nobody should support the proposal for the "this is better than nothing" reason since most of the additional information proved to be not usable, at least in the current form. In my opinion it is time to start from scratch and to do this the 14652 draft must be rejected and withdrawn. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------