HDTenEightyP/NetNews huggingface dataset:
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: 1 Jan 93 01:25:20 GMT
Organization: CWI, Amsterdam

In article <1hvu79INN4qf@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
 > Dik, i never insisted that all European languages belong to
 > the single group -- how many are the ISO Latin-X sets?
 > My point was that there obviously are identifyable meta-alpahbets
 > covering several languages.
I do think that the number in several is very small.
 > 
 >            Or dutch, where the letter combination ij is sorted either
 > >amongst i as a double letter, or amongst y as a single letter, or
 > >between y and z as a single letter, depending on who does the sorting?
 > 
 > If a combination of letters is treated as a letter IT IS A LETTER.
 > Then add it to the alphabet and let the keyboard driver (which surely
 > knows the language -- simply because there are different keyboard
 > layouts) to handle the matter.
Still wrong.  Take the dutch ij.  I have one typewriter that has the ij
on a single key, but all typewriters sold the last 20 years and all
computer keyboards sold in the Netherlands are not specific dutch.  I
would be surprised if there is even a large number of computer keyboards
sold that is not US, UK or German.  So how would the keyboard driver deal
with the 'ij' combination?  When I enter the combination it can either be
the single letter ij (some dutch people say there is no such single letter),
or two letters, depending on context.  So must the keyboard driver look
at the context (e.g. it is a french loadnword like bijoux so that ij is
really two letters), or what?

Sorting is extremely context sensitive, even in a single language.  As
another person already mentioned in english you sort McNeill as if it
is MacNeill.  Similar the abbreviation St. which can be either Street or
Saint.  (Moreover, when sorting names I would prefer to sort C. van der Bilt
under V if it is an American and under B if it is a Dutchman ;-).)

To me it appears very silly to put more than superficial sorting
information in the encoding.  The remainder must be handled by the
applications (through library programs).  And indeed, that may require
table look-up.
 > 
 > The idea of visual encoding (and one letter-onr glyph is nothing more
 > than a compressed image of the text) is simply wrong because it
 > drops valuable information readily available at the point of the CREATION
 > of the text but not later.
But as I said, such information is not readily available at the point of
creation, only if the system asks everytime.  That would be silly as most
text is not sorted anyway.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.std.internat
Subject: Re: ISO 9000-9004 Software Engineering
Date: 22 Dec 1992 16:17:40 +0100
Organization: Regionales Rechenzentrum Erlangen
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de
Keywords: ISO9000 "Software Engineering"

roger@sun1 (Roger Mosher) writes:
      ^^^^ interesting top level domain. country of the raising sun? ;-)

>Does anyone know the whereabouts of ISO standards on software engineering
>rumoured to be numbered ISO9000-9004 on software engineering?  I have
>been told that these standards are about to be adopted by EEC and are
>being considered by North American governments as well.  If you know where
>I can go from here please email me, as I don't poke around... slow news
>reader.

The ISO 9000 family of standards is about quality assurance in general
and is not a specific software engineering standard. It defines what
documentation a vendor has to provide about his quality control systems
etc. in order to conform to ISO 9000.

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.std.internat
Subject: Re: Data tagging (was: 8-bit representation, plus an X problem)
Summary: utf documents
Date: 26 Dec 92 17:18:45 GMT
Article-I.D.: alice.24486
Organization: AT&T Bell Laboratories, Murray Hill NJ



	I wish to clear up a misunderstanding on my part here.
The Plan 9 manual pages and supporting documents are available
via anonymous ftp from research.att.com. look in the directories
dist/plan9man (for the supporting documents) and dist/plan9doc
(for the manual pages).

	it turns out there are two versions of the UTF paper;
an earlier one in dist/plan9man/09utf.ps.Z and a later one
which is the paper Rob Pike will be giving at Usenix. The
latter paper will only be available after the talk is given.

	However, as far as the discussion in this group goes,
the earlier paper is good enough. the main difference between the
two papers reflects that plan 9 went from utf-1 to fss-utf
between the two versions. when the later is available, i will post
a message saying where.

		andrew hume

Newsgroups: comp.std.internat
From: cline@cs.scarolina.edu (Ernest Cline)
Subject: What are the ISO paper sizes? (Was: An alternative I18N paradigm)
Reply-To: cline@usceast.cs.scarolina.edu
Organization: USC  Department of Computer Science
Date: 29 Dec 92 01:52:40 GMT

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

[preamble deleted]

|I suggest that this international local should use existing ISO standards
|where possible. Some conventions for this international locale might be
|
|  - use the metric system (SI units)

A good idea (even if I still use inch, pint, and pound avoidupois.)

|  - use ISO paper sizes (e.g. A4, C5, ...)

Not a good idea. Here in the US it is almost impossible to obtain ISO sized
paper. Most paper is based on two standard sizes letter and legal or a
fraction or multiple therof.
  Letter (8.5" x 11") [21.59cm x 27.94cm]
  Legal  (8.5" x 14") [21.59cm x 35.56cm]

However, what I would like to know is what size is A4 or C5 or the rest
of these map references that ISO uses for paper.
Please reply by e-mail or posting with either the sizes or suggestion on
where to look for a listing of _all_ the sizes.

[remainder of suggestions deleted]

-- 
     Ernest Cline     cline@cs.scarolina.edu     Professional Grad Student
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 1 Jan 1993 02:31:17 -0500
Organization: UUNET Technologies Inc, Falls Church, VA
NNTP-Posting-Host: rodan.uu.net
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages

In article <1992Dec31.203101.5447@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes:
>There are two problems:
>    1. Getting an encoding of the characters.
>    2. Getting local conventions right.
>Problem 2 is hard.  Problem 1 should not address problem 2.

Oops. Nice try. Come again.

The ONLY reason people invent charcter encoding standards is to
"get local conventions right". If you've got your own machine which
does not communicate with others you can choose your own arbitrary
encoding.

A good encoding should support easy (i'd say natural) localization.
It should provide simple algorithms for simple functions
like getting string length, searching a character, case-insensitive
comparison, lexicographical comparison.

Unicode (and for that matter Plan 9 UTF) does not support the last
two mentioned functions. I have yet to see Plan 9 _sort_ which will
sort Russian strings without being told explicitly that it is Russian.

>Plan 9 utf solves Problem 1.

UTF does not solve the problem 1 -- it is merely a way to encode
16-bit unsigned integers in the way which (supposedly) will not
aggravate the ASCII world.

--vadim
Xref: sparky comp.std.internat:918 news.admin.misc:866
From: berger@imag.fr (Gilles BERGER SABBATEL)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 21 Dec 92 14:48:17 GMT
Organization: Institut Imag, Grenoble, France

avg@rodan.UU.NET (Vadim Antonov) writes:

>>  Don't take them out of the spec: you may want them later,and a standard
>>way of doing them is desirable.

>Nobody calls to change SMTP commands. All we need is to get rid of the
>7-bit restriction.

Which restriction?  On SunOs 4.1.2, sendmail transmits 8 bits chars
without problem, and it do use SMTP.  Obviously, if you send messages to
7 bits hosts, the 8th bit will be lost (which give funny chars...), but
there should not be other problem, unless the software is bugged.

Anyway, the problem is no longer that it is difficult to use 8 bits
chars.  We need them, and we will use them.  It is no longer acceptable
in current computer technology to be unable to write one's own language
without spelling mistakes!  This is simply anachronistic.
--
Gilles BERGER SABBATEL                  Tel: (33) 76 57 46 13
Laboratoire d'appartenance : TIM3
IMAG-LGI/INPG, 46 Avenue Felix Viallet, 38031 GRENOBLE CEDEX - FRANCE
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.std.internat
Subject: Re: ISO 8859-X What are the X's?
Date: 30 Dec 1992 19:15:44 +0100
Organization: Regionales Rechenzentrum Erlangen
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de
Keywords: ISO 8859

fvance@airgun.wg.waii.com (Frank Vance) writes:

>Can someone provide a brief overview of what the various parts of ISO
>8859 are?  By this I mean, if 8859-1 is "Western European" and
>-8 is "Hebrew" (as I have seen them called), what are the other parts?

I wrote a FAQ about ISO standards that is posted periodically to
comp.protocols.iso and comp.std.misc. This FAQ also contains a list
of the ISO 8859 parts and other ISO standards relevant to computing.
Perhaps I should add comp.std.internat to the distribution list?

BTW: All the ISO 8859 parts have been derived from previous ECMA
standards. ECMA has recently published the Latin 6 character set
for the baltic and other north european countries. I bet it is
already on the fasttrack procedure to ISO 8859-10.

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----
Newsgroups: comp.std.internat
From: roger@sun1 (Roger Mosher)
Subject: ISO 9000-9004 Software Engineering
Summary: Where are ISO 9000-9004 on Software Engineering?
Keywords: ISO9000 "Software Engineering"
Organization: NSTN Network Operations Centre, Nova Scotia, Canada
X-Newsreader: Tin 1.1 PL4
Date: Mon, 21 Dec 1992 18:26:29 GMT

Does anyone know the whereabouts of ISO standards on software engineering
rumoured to be numbered ISO9000-9004 on software engineering?  I have
been told that these standards are about to be adopted by EEC and are
being considered by North American governments as well.  If you know where
I can go from here please email me, as I don't poke around... slow news
reader.

Thanx :-)

--
===========================================================================
Roger Mosher					Phone   (902)584-2226
College of Geographic Sciences			Fax     (902)584-7211
50 Elliott Road				email   roger@sun1.cogs.ns.ca
Lawrencetown N.S.
B0S 1P0
===========================================================================
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: 31 Dec 92 10:44:03 GMT
Organization: CWI, Amsterdam

In article <1hu9v5INNbp1@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
 > Having unique glyphs works ONLY WITHIN a group of languages
 > which are based on variations of a single alphabet with
 > non-conflicting alphabetical ordering and sets of
 > vowels. You can do that for European languages.

Wrong Vadim.  You cannot even do it in the European languages.  You cannot
even do it in German.  How would you assign codes such that the German
A-umlaut sorts as if it is the letter combination AE, and at the same
time the umpteenth letter of Swedish (after Z).  How would you encode
spanish where the letter combinations CH and LL are regarded as single
letters?  Or Maltese where the GH-crossbar combination is a single letter
that does not sort in the neighbourhood of G or H-crossbar but between
P and Q?  Or dutch, where the letter combination ij is sorted either
amongst i as a double letter, or amongst y as a single letter, or
between y and z as a single letter, depending on who does the sorting?
From: tt@tarzan.jyu.fi (Tapani Tarvainen)
Newsgroups: comp.std.internat
Subject: Re: Week Numbering
Date: 21 Dec 92 06:27:07 GMT
	<TML.92Dec18161133@tiuhti.tik.vtt.fi> <keld.724695337@login.dkuug.dk>
	<1992Dec20.193234.8589@ruc.dk>
Organization: University of Jyvaskyla
Originator: tt@tarzan.math.jyu.fi

In article <1992Dec20.193234.8589@ruc.dk> plate@ruc.dk (John Plate) writes:

>In Europe (?) the first week of a year is the week that has more than 
>3 days in it. Weeks goes from monday to sunday.

That's what the ISO standard says, in fact.  Whether anybody outside
Europe knows or cares is another matter.

>If a year starts with a week with less than 4 days, it is week 53 of
>the previous year.

This is not, however, quite correct: it can also be week 52 of the
previous year.  (Let's think ... it happens when the year begins on
a Sunday, or on a Saturday following a non-leap year, right?)
--
Tapani Tarvainen  (tt@math.jyu.fi, tarvainen@finjyu.bitnet)
From: anoosh@mips.com (Anoosh Hosseini)
Newsgroups: comp.std.internat
Subject: Experience with Windows/DOS NLS?
Date: 2 Jan 93 00:11:19 GMT
Organization: SGI/MIPS
NNTP-Posting-Host: wildcat.mti.sgi.com
Originator: anoosh@wildcat.mti.sgi.com

I had few detail questions regarding Internationalization
features of Windows and Dos, in particular table formats
etc..  If you have had in depth experience can you give 
me an Email buzz.

mucho thanks,

-anoosh

-- 
| Silicon Graphics Inc./MIPS Technology Inc.   	| anoosh@mti.sgi.com  | 
| 2011 N. Shoreline Blvd. M/S 10U-178           | anoosh@sgi.com      |
| Mountain View, CA  94039 USA.               	| 415-390-4497	      |
From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 2 Jan 1993 05:57:17 GMT
Organization: MIT Artificial Intelligence Laboratory
NNTP-Posting-Host: wheat-chex.ai.mit.edu
Keywords: ISO10646 Unicode

In article <1i13rrINNars@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:

>Somehow i had introduced my "own" cyrillic encoding and it lived (and
>still lives) and was used by a lot of people (it became obsolete nearly
>at the time it was approved as a national standard). The company i worked
>before managed to create a totally bilingual family of Unix-like systems --
>something unheard of in the West.

You're uninformed.  Try looking at Xerox Viewpoint (West European,
East European, Greek, Arabic, Hebrew, Chinese, Japanese, Korean, et al);
try looking at BB&N Slate (West & East European, Greek, Hebrew, Arabic,
Korean, Thai).  There are others: Nota Bene, Multilingual Scholar,
AlKatiib, etc.

Tell me how to sort Tibetan, Burmese, Khmer, and Japanese, providing
all established culturally expected orderings.  After you've done
this, let me know whether you think a character set can handle the
burden of correct sorting.  Its not that this isn't an admirable goal;
its just that it is untenable given the overall design goals
of Unicode -- or any other character set that could stand a chance of
becoming a universal character set standard, and not being horribly
inefficient.

You might want to read a paper entitled "Collating Unicode Data"
by Alain LaBonte, Ministry of Communications, Quebec, before
arguing further.  It is contained in the proceedings of the Unicode
Implementors Workshop.  It will verily destroy all the arguments
you've offered so far.

If you are interested in a paper discussing the architecture of a
multilingual toolkit in which sorting *is* handled, and which *does*
support Unicode, and which *does* facilitate language tagging, then
see the file /pub/mlt2-overview.ps.Z (a compressed postscript file) on
METIS.COM [140.186.33.40] by anonymous FTP.  [If you have no FTP access,
let me know and I can uuencode and email it.]

Glenn Adams
From: amanda@intercon.com (Amanda Walker)
Newsgroups: comp.std.internat
Subject: A comment on character set standards and internationalization
Date: Sun,  3 Jan 1993 03:41:52 -0500
Organization: InterCon Systems Corporation
Reply-To: amanda@intercon.com (Amanda Walker)
NNTP-Posting-Host: chaos.intercon.com
X-Newsreader: InterCon TCP/Connect II 1.1b31

I've been following the character set debate for years, and have finally 
arrived at the conclusion that in the long run, it doesn't matter--that the 
goal of constructing a universal character set, a universal mapping of 
numeric values to fundamental units of written language, can only be 
approximated and not achieved.

The problem is that units of written language are not as discrete as they 
seem, any more than units of spoken language are.  Just as no single phonetic 
alphabet can capture all nuances of spoken language, no single assignment of 
code points is going to apply to all representations of written language.  
This is not due to lack of diligence on the part of standards committees, but 
to the fact that different things are important in different circumstances.

Half of the heated argument about text representation seems to stem from the 
idea that we have to solve "the whole problem."  But we can't--the best we 
can do is improve on what we have now, so that we end up with fewer schemes, 
each of which covers more ground.

UNICODE will make some things easier, but it's not a universal panacea.
Neither will ISO 10646 be one, or any other scheme.  They're both just 
distinct improvements over the status quo for many applications.  However, 
the fact that they aren't suited for other applications is not a defect with 
them, but with the attempt to force-fit them into places they won't go.

The criterion against which we should be judging them is utility, not 
perfection.



Amanda Walker
InterCon Systems Corporation
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 3 Jan 93 16:39:00 GMT
Organization: Enea Data AB

Andrew Hume (andrew@alice.att.com) writes:
>But what about text which has French/German/Italian/English mixed together? 
>Or as Erland pointed out, text with a bunch of Scandanavian languages mixed
>together? Being able to have several almost identical but distinguishable 
>fonts on the screen at once is a fairly difficult task (although not
>very difficult).

Depends for whom you are talking about, the implementor or the user.
For the user it's not a question on whether it's difficult or not -
it's simply not acceptable.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Jag gav en k{ck tjeck en check.
Xref: sparky comp.std.internat:939 news.admin.misc:929
From: andersa@Riga.DoCS.UU.SE (Anders Andersson)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 28 Dec 92 16:53:05 GMT
Organization: Uppsala University, Sweden
NNTP-Posting-Host: riga.docs.uu.se

In article <berger.725045292@gram>, berger@imag.fr (Gilles BERGER SABBATEL) writes:
> dhd@exnet.co.uk (Damon) writes:
> >IE, don't be parochial and assume that because it solves *your* problem
> >it's more then moving from a 1% solution to a 1.1% solution...
> 
> Sure!  But the problem is that we could relatively easily move to
> ISO-latin-1, (many softwares appear to work with 8 bits chars) so that
> it would be a first step to experiment and solve the problems.  Whenever

Experiments along your lines are going on, in the sense that a lot
of old software *is* being used with 8 bits today, with or without
modification.  It's hardly even a 'first step', as I18N in some
form has been going on ever since vendors started shipping computers
across national borders.  So, isn't everyone happy then?

> First, ISO-latin-1 appear to require a minimal conversion of softwares,

Well, 'minimal' is not very well defined here.  It may be a minimal
change in terms of source code lines, but distributing the output is
a whole different matter.  Without any factual evidence for my claims,
I assume it would be easier to update every piece of software at a
single large site (say, MIT) than to get the updated version of a
single piece of software (say, sendmail) out to every user who would
need to install it (end-user or not).  Haven't we been through this
already?

> able to write japanese at all!  So, the use of ISO-latin-1 in France
> would not disturb anybody outside of France, and it contributes to the
> solution of the problem - at least it poses it!

Controlled experiments in a limited environment is fine; I'll leave
it to the French computer users to decide whether they want to take
part in that experiment.  However, I imagine some people outside
France want to make it quite clear that they are not going to support
whatever local conventions are established locally, especially when
they can provide superior solutions.

As for your statement that use of ISO-latin-1 in France won't
disturb anyone outside France, well, I prefer to remain silent
until I understand what it means, or I notice disturbances...

However, I don't see the real need for your experiments here.
I consider it an obvious fact that a serial line can handle 8
(or even 9) bits just as well as 7, so what is it that still
needs to be tested before you can go into production use? :-)
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 325, S-751 05 UPPSALA, Sweden
Phone: +46 18 183170   EMail: andersa@DoCS.UU.SE
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 1 Jan 1993 17:39:40 -0500
Organization: UUNET Technologies Inc, Falls Church, VA
NNTP-Posting-Host: rodan.uu.net

In article <TT.93Jan1135637@tarzan.jyu.fi> tt@tarzan.jyu.fi (Tapani Tarvainen) writes:
>>Unicode (and for that matter Plan 9 UTF) does not support the last
>>two mentioned functions. I have yet to see Plan 9 _sort_ which will
>>sort Russian strings without being told explicitly that it is Russian.
>
>So what?
>I've yet to see anything even planned that would allow sorting
>both Finnish and German without being told which is wanted.  
>In fact I can't even imagine one that would make any sense.
>In the case of a list of names, the very same data could be
>sorted differently depending on where it is going to be used.

Pfrr, take a look at DEMOS Unix-likes -- they do sort both Russian and English
without being told which is wanted. [<ah>-<ya>]* in shell really selects
				      ^    ^ -- imagine real cyrillic letters here
all files startting from lowercase russian letter. lex generates correct
parsers for languages with russian keywords. Grep works as it is supposed to.
So far no user complained that there are two o's and two A's in the code.

It is not impossible -- it's rather easy if the right code is choosen.

>Tying sorting rules to character sets is not a good idea, IMHO.

Would you like to specify the language for every range in every regular
expression you use?

Embedding sorting rules to character sets is not a "good idea" -- it's
a necessity and you can do nothing about it.

--vadim