HDTenEightyP/NetNews huggingface dataset:
From: sommar@enea.se (Erland Sommarskog)
Subject: Re: Let's develop ISO sorting rules
Organization: Enea Data AB
Date: Sat, 9 Jan 1993 22:20:40 GMT

Markus Kuhn (mskuhn@immd4.informatik.uni-erlangen.de) writes:
>>I believe you.  I'm sure that the analogous statement is true for French.  But
>>I'm almost as sure that Swedish readers won't want "a-circle" to be anywhere
>>near "a".  I think your flexibility on this is a language-relative phenomenon.
>
>This would be really bad news, could someone from Sweden coment on this?

Just adding my voice to the crowd: if you are talking about a default
sort order, maybe. If you are talking about a standard to replace all
existing orders: just forget it!

>My idea is, that there is one latin alphabet, that is known by everyone
>using a latin script:
>
>  abcdefghijklmnopqrstuvwxyz
>
>And the following rule may be understood by every user within less then
>10 seconds:
>
>  sort latin characters with diacritics (e.g. "a, 'a, ^a, ...) near their
>  pure latin version a.

It may not be a very good solution even for a default sort order. Say
you have a catalogue of persons. You've read in the paper about Lech
Walesa and want to see if he is in the catalogue. You find Walde (whoever
that is) and directly after Walde you see Walters, so you conclude
that Walesa is not in the catalogue. But he is - after Walters, since
the name of the Polish president actually is Wal/e,sa, but the papers
you read always replaces the special Polish characters with what they
have in store.

A default sort order should probably sort according to the English
(not Latin!) alphabet and the co-sort look-alikes so that they are
only significant when nothing else is different.

Of course that applies to Latin-based languages only.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Newsgroups: comp.std.internat
From: peter@ferranti.com (peter da silva)
Subject: Re: islands
Organization: Xenix Support, FICC
Date: Wed, 13 Jan 1993 00:31:41 GMT

In article <1993Jan11.190644.29108@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
> The big problem, as Ohta pointed out, is the "cat" problem.

No, the big problem is the "editor" problem. "cat" has no business doing
anything but concatenating files. Why would you expect different character
set monolingual files to change format when you "cat" them? I certainly
wouldn't, any more than I'd expect "cat" to decompress compressed files,
convert a "tar" archice to a "cpio" archive when you cat one onto the other,
and generate a nicely formatted directory listing when you "cat" a directory.
These all make as much sense as your proposal.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.std.internat
From: hpa@eecs.nwu.edu (H. Peter Anvin N9ITP)
Subject: Re: Language tagging
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Organization: You must be kidding!
Date: Fri, 8 Jan 1993 08:18:30 GMT

In article <1ii6bkINNf6c@rodan.UU.NET> of comp.std.internat,
  avg@rodan.UU.NET (Vadim Antonov) writes:
> 
> >A pure locale-system clearly won't do in multilingual environments.
> >Nonetheless some things are, IMHO, best handled with locales.
> >Perhaps it should be possible to specify the default language (like,
> >in an environment variable) separately for each script one is
> >concerned with (setenv LANG 'LATIN:finnish;CYRILLIC:russian;HAN:chinese')
> >or whatever) and fall to a default in the rest.
> 
> It is not enough. Ukrain, say, use characters of both Cyrillic and
> Latin scripts, etc.
> 

I'd suggest some form of multiple locales, i.e. 
setenv LANG ukranian-swedish-ipa-greek-farsi-japanese

In this model, each of the sorting algorithms would assign sorting
values (integers, that may or may not be identical) to each character
recognized in that language.  Any character undefined (e.g. KANJI HITO
for Ukranian) is assigned MAXINT and thus is sorted last.  The sort
proceeds with the first language as the primary key, second language
as the secondary etc.  That means not only that the text in the
different languages will show up in approximately the order listed,
but also that multiscript languages can be easily accommodated.  There
are languages that use characters from at least three scripts, so the
need is there.

	/hpa

-- 
INTERNET:  hpa@nwu.edu   TALK:      hpa@delta.eecs.nwu.edu
BITNET:    HPA@NUACC     IBMNET:    16331@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  hpa@lenny.acns.nwu.edu
while ( 1 ) ; cp /dev/zero /dev/null & end
From: rap@news (Ross Paterson)
Newsgroups: comp.std.internat
Subject: Re: Unicode Han Characters [was Re: Language tagging]
Date: 7 Jan 1993 10:31:25 GMT
Organization: Dept. of Computing, Imperial College, University of London, UK.
Reply-To: rap@doc.ic.ac.uk
NNTP-Posting-Host: peaberry.doc.ic.ac.uk

From article <1if6lgINN6ri@life.ai.mit.edu>, by glenn@wheat-chex.ai.mit.edu (Glenn A. Adams):
| [...]
| If you would like to obtain (unofficial) mappings between a number of
| these character sets and Unicode, you can find them by anonymous FTP
| on METIS.COM [140.186.33.40] in /pub/csets.

(Actually /pub/csmaps)

Does anyone have a mapping from the old Chinese telegraph code to Unicode?
From: melby@dove.yk.fujitsu.co.jp (John B. Melby)
Newsgroups: comp.std.internat
Subject: Re: Language tagging
Date: 6 Jan 93 11:39:51 GMT
	<2609@titccy.cc.titech.ac.jp> <1iav6tINNee2@life.ai.mit.edu>
Organization: Open Systems Group, Fujitsu Limited, Yokohama
In-reply-to: glenn@wheat-chex.ai.mit.edu's message of 5 Jan 93 03:27:25 GMT

If what I have heard about the Unicode standard is accurate, Chinese
simplified forms are not distinguished from Chinese unsimplified forms
when they are effectively equivalent.  Since the radicals for "eating"
and "metal" have simplified forms radically differing from the unsimplified
printed variants, a Japanese may not be able to distinguish certain
characters displayed using a Chinese character set (although usually
they should be distinguishable through context).

Of course, there is one major flaw in the preliminary Unicode version:  the
Japanese simplified form of "sakura" (ying1hua1 de ying1) is not included.
Since the word "sakura" is common in Japanese surnames, this necessitates
the use of a supplemental character set.  (This omission is blatant enough
that it will probably be corrected in a subsequent version.)

-----
John B. Melby
Fujitsu Limited, Yokohama
melby@yk.fujitsu.co.jp
Newsgroups: comp.std.internat
From: gsc@coombs.anu.edu.au (Sean Case)
Newsgroups: comp.std.internat
Subject: Re: ISO paper sizes
Date: 5 Jan 93 11:00:36 GMT
Organization: Australian National University
NNTP-Posting-Host: 150.203.76.2

ag129@cus.cam.ac.uk (Alasdair Grant) writes:

>1 SI inch is 2.54mm _exactly_, not just to 7 decimal places.
>But the people who don't use ISO paper sizes don't use SI inches
>either, they use NIST inches, which differ from SI inches well before
>the 8th decimal place.  (I don't know the exact details - after all,
>why should I know about American internal standards?)

>Does the persistence of the NIST inch have anything to do with the
>US public's huge stock of old guns needing new ammo machined to low
>tolerances?  Britain had no problems redefining its Imperial measures
>as SI multiples...  I wonder.

The story I heard related to land title.

The whole of the contiguous United States has been surveyed from a
baseline on the East Coast. Changing the value of the inch even
slightly would create major hassles for landowners on the West Coast,
since land boundaries are defined by reference to survey points.

Does anyone from the US know anything about this?

Sean Case
--
Sean Case               gsc@coombs.anu.edu.au
"[...] if a poststructuralist doesn't get you,
 a deconstructionist will."--Ursula K. LeGuin
Newsgroups: comp.std.internat
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: University of Utah Computer Center
Date: Fri, 8 Jan 93 05:26:41 GMT

In article <1ii0n7INN6ig@life.ai.mit.edu>, glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) writes:
|> In article <1993Jan7.065611.15193@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
|> >This example becomes more of a problem when translated to one of a glyph
|> >variant between Chinese and Japanese.  I agree that the problem is one
|> >of words, not characters -- however, in ideographic languages, words *are*
|> >characters.  The example is not as artificial as you make out.
|> 
|> I'm afraid this is incorrect.  Ideographic characters in Chinese, Japanese,
|> Korean, and Vietnamese (chu+" no>m va! chu+" ha'n) *are not* equivalent
|> to words.  Rather, they are mostly equivalent to morphemes (although there are
|> a number of multiple character morphemes).  Many words in these languages
|> are composed from multiple morphemes, e.g., modern Chinese has about 2.2
|> morphemes (characters) per word on average.  For example, in Chinese
|> "zhong1guo2" 'China' and "ri4ben3" 'Japan' are single words but contain
|> two morphemes each.

Ok, partially bad instances (some characters *are* ideographic, or at least
morphographic with single morphemes.  Pick a non-Chinese and non-Japanese
purely ideographic language, and reapply the example to pass the purity of
example requirements (since it *is* possible to produce a non-contrived
example (ie: "chicken" as in "chicken soup") in Chinese, wherein a single
glyph *does* represent a single word.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.std.internat
From: jenkinsj@blowfish.taligent.com (John H. Jenkins)
Subject: Re: Language tagging
Followup-To: comp.std.internat
Organization: Taligent, Inc.
Date: Wed, 6 Jan 1993 19:02:11 GMT

In article <MELBY.93Jan6113951@dove.yk.fujitsu.co.jp>,
melby@dove.yk.fujitsu.co.jp (John B. Melby) wrote:
> 
> If what I have heard about the Unicode standard is accurate, Chinese
> simplified forms are not distinguished from Chinese unsimplified forms
> when they are effectively equivalent. [...]

I'm not sure what you mean by "effectively equivalent."  If you mean
"they look pretty much the same," this is true -- in which case the
character isn't "simplified" (as the word is used in Taiwan).  The
simplified and traditional forms for Chinese characters are unified if
and only if their glyphs have virtually the same appearance (formally,
the unification rules developed by the CJK-JRG are used), and they do
not both occur in the same national character set standard.  If you
believe mean something else, I believe the statement is wrong.  

In practice, virtually all the simplified forms of Chinese characters
used by mainland China are separated from their traditional/unsimplified
counterparts.  You cannot change simplified Chinese to traditional by
changing fonts, or vice versa, and any font vendor who uses a simplified
Chinese glyph for an unsimplified form would be doing a Very Bad Thing
-- not, of course, that this will stop them.  :-(

> Of course, there is one major flaw in the preliminary Unicode version:
 the
> Japanese simplified form of "sakura" (ying1hua1 de ying1) is not
included.

It is U+685C.  (Unless we misunderstand your meaning here.)  I should
point out also that Unicode is a superset of both JIS 0208 and JIS 0212
(and always has been), so if this were a design flaw in Unicode, it
would also be a design flaw of both JIS sets.  

----
John H. Jenkins
John_Jenkins@taligent.com
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.std.internat
Subject: The ultimate encoding
Date: 9 Jan 93 22:08:18 GMT
Organization: Enea Data AB

Vadim Antonov (avg@rodan.UU.NET) writes:
>Now, i think everybody agrees that the "ultimate encoding" is
>the one which provides the complete information about which
>language is used -- it sovles all the problems.

No, if it doesn't tell which font is used I cannot use it to typeset
the text properly.

Seriously, I disagrees with the statement above, and I think most
other people do. Putting the language into the coding gives more
problems than it solves. How deal with umpteen instances of the
same character because it is treated different language?

My modem - or rather the stinking telephone line - prevented me from
read all of Vadim Antonov's text and hang up when I had gone through
18%. The far I got the article seemed to be based on the same erroneous
presumptions that he has presented before. This horse has been beaten 
dead all over again, so I will be brief.

Vadim, your KOI-8 solution might have been the only possible solution
at the time of its creation, but it was still not able to even support
the former USSR entirely. (Assuming that you could not squeeze in Armenian
and Georgian scripts and the extra letters need for Estonian, Latvian,
and Lithuanian. Even less would have been possible if you want to embed
sort rules with the character code, since for Estonian and English you
would have to duplicate at least parts of the alphabet.)

But Unicode is not a partial solution for the Soviet Union in the 1980s. 
Unicode is a tool for complete solutions for the world in the 21st century.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
From: jamiller@kuhub.cc.ukans.edu
Newsgroups: comp.std.internat
Subject: Unicode History?
Date: 8 Jan 93 00:49:13 CST
Organization: University of Kansas Academic Computing Services

I'm interested in hearing some of the history of the Unicode std.  I'm
quite familiar with JIS but have little knowledge of the other codes.
-- 
jamiller@kuhub.cc.ukans.edu
James Miller

_chicchai .sig no ho ga ichiban iin janai ka..._
             Enlightenment Happens?
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Subject: Re: Let's develop ISO sorting rules
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: University of Helsinki
Date: Tue, 5 Jan 1993 19:22:39 GMT

mskuhn@immd4.informatik.uni-erlangen.de writes:
>No, the answer that NO internationally suitable sorting algorithm (not
>only sorted character table!) is possible is too simple in my eyes.

And making everybody use the same sorting order is not workable in my
eyes.  The English words co-ordinate and co-"ordinate ("o = o with two
dots on top; this is quite correct English) should be sorted together,
but the Swedish words ost (cheese) and "ost (East) should not.  In the
former case, o and "o are the same letter and that's why they should
be kept together, in the latter case they are very, very distinct
letters with only a happenstance similarity in the way they look, and
mixing them is not going to be accepted by more than perhaps one or
two users (and those are probably programmers :).

While it is true that users to have to change when they use computers,
the sorting order is not one of the cases where they will do it.
Actually, if I were willing to change the order of the alphabet to
suit computers, I'd just as soon make everybody start using a common
language (English, Esperanto, or whatever), and make the whole
problem i18n disappear.

I18n seems to be a fun topic: any rational-sounding solution that
looks ideal from an engineering and programming standpoint gets
shouted down by a pack of change-unfriendly users.  :-)

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.std.internat
Subject: Re: ISO paper sizes
Date: 6 Jan 93 05:00:10 GMT
Organization: Computer Science Department, Oregon State University
NNTP-Posting-Host: jade.cs.orst.edu

In article <1993Jan4.170125.3951@infodev.cam.ac.uk>
ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>1 SI inch is [25.4 mm] _exactly_, not just to 7 decimal places.
>But the people who don't use ISO paper sizes don't use SI inches
>either, they use NIST inches, which differ from SI inches well before
>the 8th decimal place.  (I don't know the exact details - after all,
>why should I know about American internal standards?)

The official and legal measure system for the United States is, and has
been since the 19th century, the metric system.  (Little known fact, I
forget exactly where I read it.)  The US "imperial" system was defined
in terms of the metric system.  In this definition, 39.37 inches are
defined to be exactly 1 meter (metre).  If you invert this, you get
25.400050800101603 mm to the inch.

I do not know why the SI definition of an inch was changed from the
long-standing US definition.  I believe it was changed sometime around
1960.

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.internat
Subject: Re: Let's develop ISO sorting rules
Date: 12 Jan 93 01:49:27 GMT
Organization: CWI, Amsterdam

In article <1iscn0EINNhjt@uni-erlangen.de> mskuhn@immd4.informatik.uni-erlangen.de writes:
 > What the hell is this "English sorting order"?
Agreed.

 >                           Perhaps we are speaking
 > about the same idea, an international DEFAULT sorting order, that will be
 > acceptable in many countries.
Might be useful, but what you forget is that sorting is for the users, not
for the programmers (the programmers can sort any way they seem fit, as
long as the user understands it).  What about the user who normally does
not distinguish V and W (as in many scandinavian countries)?  What language
users would accept a sorting where diacritics are ignored and sorting is
done with 26 letters (plus additions for Icelandic Edh and Thorn).  Moreover,
where would you classify the 5 Nama (Hottentot) clicks, represented by: /,
/= (overprint these two), //, ! and #?  I know Unicode has LATIN LETTER
EXCLAMATION POINT for one of these, I do not have the Unicode Standard
(as it was sold out when I tried to buy it), but I would not be surprised
if there are further LATIN LETTER code points for the additional clicks.

 > There won't even be collisions if you add France and Germany.
Perhaps no, but add Spanish and you get problems.

 > But I don't know that any has been defined yet. If people in Sweden need
 > a different order, than they should get their order, no problem.
Ok, where do I sort "!homi" and "//natib"?

 > But it would be a good idea to define a default order that might be 
 > easily refered to (e.g. as an ISO standard) and that satisfies the
 > needs of the greatest set of countries for which this is possible with
 > one sorting order.
This would be ridiculous if the number of users from those countries are
only a minority.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.std.internat
Subject: Re: Language tagging
Date: 5 Jan 1993 03:27:25 GMT
Organization: MIT Artificial Intelligence Laboratory
NNTP-Posting-Host: wheat-chex.ai.mit.edu

In article <2609@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>If I throw away a short e-mail message from Japan to Japanese
>friend living in China, how can my friend read the text with
>the appropriately shaped character?

Ohta-san,

Could you be more specific about this claim that you continue to
make over and over again that a Japanese reader cannot read a
Unicode encoded Japanese text which is displayed with a Chinese
Unihan font versus a Japanese Unihan font.

I would be very interested to see any kind of hard data (other than
your opinion) that would substantiate this claim.  Personally, I
don't believe you will be able to produce any; but I'm very willing
to listen if you can come up with any.

I should add that any data on this topic should be keyed to the
notion of legibility (i.e., readability) and not aesthetic judgment.
I would contend -- also with hard data to back up my claim -- that
you are incorrect in your assertion, and that, indeed, Japanese
readers *can* read Unicode encoded Japanese text displayed with
a Chinese Unihan font.

Glenn Adams




Newsgroups: comp.std.internat
From: nms@newcom.kiae.su (Nickolay M Saukh)
Subject: Re: ISO paper sizes
Date: Mon, 4 Jan 1993 17:58:42 GMT
X-Newsreader: TIN [version 1.1 PL7]
Reply-To: nms@ussr.EU.net
Organization: ?

Markus Kuhn (unrza3@cd4680fs.rrze.uni-erlangen.de) wrote:

: Here for the aprox. 5% of the world population that don't use ISO paper sizes
: the dimensions of 3 of the most popular sizes:
: 
:     A4    210 x 297 mm
:     C5    162 x 229 mm (envelope for A4 folded to A6 format)
:     DL    110 x 220 mm (envelope for A4 folded twice parallel)
: 
: 1 inch is 25.4000000 mm.
            ^^^^^^
I thinked it was 25.412. Is it?
-- 
Nickolay Saukh
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.internat
Subject: Re: Data tagging (was: 8-bit representation, plus an X problem)
Date: 4 Jan 93 17:02:52 GMT
Organization: Tokyo Institute of Technology

In article <24494@alice.att.com> andrew@alice.att.com (Andrew Hume) writes:

>> >japanese better get rendered as japanese no matter what your locale is.
>> 
>> I heard that, microsoft's NT will have a locale mechanism so that
>> it can print Japanes Han as Japanese and Chinese Han as Chinese,
>> which is impossible with bare 10646/Unicode.
>
>	this is a fundamental and persistent misapprehension of
>10646. it was neither designed for, nor can it allowd a system
>to display identical Han characters (same 10646 codepoint)
>in different fonts WITHOUT some other (non-10646) convention.

As it defines the same code point for correnponding Japanese/Chinese
characters, differentiation is impossible.

>10646 simply defines codepoints, allowing the unambiguous specification
>of the characters. if you want to set (or switch) fonts, then you
>have to invent some scheme to do it, as say ISO 2022 does
>(in a slightly clumsy way).

Then, why you use ISO 10646? Can't we use ISO 2022?

>	i claim NT has some convention in addition to the locale
>(perhaps, it is part of the lcoale's definition) so it can do this.
>but i don't know.

Then, how can I create a text file which contains both Chinese
and Japanese?

>> Shouldn't we use error numbers internally and interprete it by local
>> programs?

>	when the protocol was updated, this was taken out
>and errors are now just text strings (64 bytes i think).

Making everything English text is another fatal misdesign of Plan 9
as an internationalized OS.

>	the bottom line is, when you connect to remote services,
>there is simply no way to know what they might report as errors.

If you are connecting to some server, you know the protocol you use
in which meanings on error numbers are contained.

>the problem is that a file server, say, may have an arbitrary
>number of error conditions, many of which may not be known locally.

Or, how can the client program know the severity of the error? Should
client program retry on error? How many times? Or should the client
abort the current transaction and retry? Or should the client
abort the entire job?

Even if the version of the server is updated and new error codes are added,
the server should know the version of the client and return old error code.
Or, how can the client program behave? Of course, for purely
informational purpose only, you can still report it, say, as "unknown
error # 42", which is of no help.

						Masataka Ohta