Date: Thu, 19 Oct 1995 05:13:22 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su> To: "Kaleb S. KEITHLEY" <kaleb@x.org>, Terry Lambert <terry@lambert.org> Cc: hackers@freefall.FreeBSD.org Subject: Re: xterm dumps core Message-ID: <Zb2HRXmqU1@ache.dialup.demos.ru> In-Reply-To: <199510190052.UAA00286@exalt.x.org>; from "Kaleb S. KEITHLEY" at Wed, 18 Oct 1995 20:52:36 EST References: <199510190052.UAA00286@exalt.x.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199510190052.UAA00286@exalt.x.org> Kaleb S. KEITHLEY
writes:
>> The X locale alias mechanism is
>> indeed an artifact of local extensions (ie: AIX "DOSANSI", HP, etc.)
>> rather than an artifact of the deficiencies in the weel defined naming
>> conventions for locales which are not vendor private.
>An artifact of local extensions? I wouldn't say that. I would say it's
>an implementation detail to overcome the lack of consistency in naming
>locales, e.g.: HP's american.iso88591, Digital's en_US.ISO8859-1, SVR4's
>en_US, SunOS's iso_8859_1 LC_CTYPE, and all the other variations the
>vendors use for their ISO locale names. The X Consortium release of R6
>makes no attempt to cover vendor proprietary locales like HP's roman8
>locales, or AIX and Unixware Codepage 850 locales.
This problem leads to using identifiers which is home-made,
RFC 1700 takes care just of this case, now anybody who want follows
standard here know which charset names he must choose.
>As an aside I would say that I believe all these companies take their
>standards compliance very seriously. Yet none of them have a problem with
>not following RFC 7000 in choosing names for their locales. The switch
RFC 1700 is relatively new, so following expected.
BTW, it uses original ISO charsets names which _always_ exists.
>from foo.ISO8859-1 to foo.ISO_8859-1 seems completely gratuitous. The fact
>that he will compound it by failing to have any sort of backwards
>compatibility is inexcusable.
>Andrey should think about the consequences of upsetting thousands of
>previously happy FreeBSD users when they discover that the X that they've
>been using just fine for a year or more on FreeBSD 2.0/2.0.5 no longer
>works, with problems ranging from xterm dumping core to compose processing
>no longer working.
X shipped on the same CD as FreeBSD and it is newer that
2.0/2.0.5 variant, so upgrading recommended in this case.
I already make neccessary locale.alias additions.
>> On the other hand, I have no problem whatsoever orphaning vendor-private
>> locale naming mechanisms if it buys an additional level of functionality
>> at no other cost.
>This is not a case of X orphaning vendor locale names. It is a case of
>mapping as many vendor locale names as possible to the corresponding X
>locale name. It is a X internal implementation detail. It is not, as Andrey
>claims, a bug that the X Consortium release of R6 does not support the
>locale names used in an as yet unreleased version of FreeBSD.
I mean that X Consotrium not support RFC 1700 names when it should.
FreeBSD unreleased version is working example of it.
--
Andrey A. Chernov : And I rest so composedly, /Now, in my bed,
ache@astral.msk.su : That any beholder /Might fancy me dead -
http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead.
RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Zb2HRXmqU1>