HDTenEightyP/NetNews huggingface dataset:
From: heiby@chg.mcd.mot.com (Ron Heiby)
Subject: RS-232 and DTR when system dies
Organization: Motorola Computer Group, Schaumburg, IL
Date: Wed, 6 Jan 1993 21:19:38 GMT

I have been having a philosophical discussion with one of my
colleagues, on the subject of the DTR line in the RS-232 standard.
I'm looking for information to help resolve the disagreement that has
emerged.

My interpretation of RS-232 is that the DTR line should be asserted
*only* when the DTE is ready to exchange data.  My colleague believes
that that is an over-strict interpretation.

The exact situation in question is what should be done with DTR on
serial ports coming from a UNIX based computer system that has either
locked up or panic'd.

In my opinion, this circumstance is such that the DTE (the UNIX
computer system) is *not* ready to exchange data, so the DTR line
should not be true.  My colleague believes that it is not important
that the modems attached to the dead computer continue to answer
incoming calls, and that since previous versions of the system
software have behaved in exactly the same way for half a dozen years
or more, that it's no big deal either way.

I'm looking for opinion as to what the *right* thing to do is and how
important it is to do the *right* thing.  I'm also looking for actual
data regarding computer systems from various vendors, and their
treatment of DTR in such a situation.

Thanks!
-- 
Ron Heiby, heiby@chg.mcd.mot.com	Moderator: comp.newprod
"proteus: any of a genus of aerobic ... bacteria that include saprophytes in
 decaying organic matter and forms associated with gastrointestinal disorders"
From: jamiller@kuhub.cc.ukans.edu
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 12 Jan 93 15:38:12 CST
Organization: University of Kansas Academic Computing Services

In article <ISHIKAWA.93Jan8125424@ds5200.personal-media.co.jp>, ishikawa@personal-media.co.jp (Chiaki Ishikawa) writes:
> 
> From a Japanese perspective:
> 

> May I suggest that before going into ISO arena, each country (or
> culture group) codify the existing methods clearly in writing?  And

     [very relevant example of difficultly of sorting with kanjinames]
     [with no furigana phonetic cues]

> I believe the correct approach to sorting is to codify the existing
> rules of each country/culture/whatever, and then publish them in a
> easy to read documents which are understandable by reasonably talented
> programmers of other countries. Code examples for each sorting rules
> will go a long way. This will help I18N from the bottom.

What are you're ideas for a Japanese specific solution?

I've often wondered why JIS level 2 was switched to a radical sorting
routine from the level 1 phonetic orientation.  This has made it quite
cumbersome for me to try to code dictionary utilities, for example.  One must
*construct* radical orderings for level 1 and kana orderings for level
2 manually.  Wouldn't a standard with fields for both radical order
and kana order be more efficient, especially with more of a focus on
international compatability in formats?

> I doubt if it is just a complexity issue. The whole concept of
> language independence sounds like a pipe dream to me. (see the
> discussion of Japanese sorting above.) There is nothing wrong about
> language-specific solutions IMHO as long as such solutions (adopted
> from existing practices) are freely available in understandable
> documentation.

Perhaps it would not be a problem solvable now, but given standards
that were linguistically independent--some abstracted stardard that
would regulate linguistically specific examples--it would be a
possibiliity, right?  Perhaps, the attempt by some to propose the
"default" sorting--read Western romanized sorting--as something
naively approachable may be flawed, but certainly talk should
continue for a solution that is linguistically independent and thereby
inclusive of all linguistic data.


I agree the language-specific solutions are fine for now.  Especially
considering that's all that's really practical. :)

>  Chiaki Ishikawa,  Personal Media Corp.,  MY Bldg, 1-7-7 Hiratsuka,
>  Shinagawa, Tokyo 142, JAPAN. FAX:+81-3-5702-0359, Phone:+81-3-5702-0351
>  UUNET: ishikawa@personal-media.co.jp
-- 
jamiller@kuhub.cc.ukans.edu
James Miller

_chicchai .sig no ho ga ichiban iin janai ka..._
             Enlightenment Happens?
From: hpa@eecs.nwu.edu (H. Peter Anvin N9ITP)
Subject: Re: Let's develop ISO sorting rules
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Organization: You must be kidding!
Date: Fri, 8 Jan 1993 07:52:33 GMT

In article <1ihe8gEINNh5q@uni-erlangen.de> of comp.std.internat,
  mskuhn@immd4.informatik.uni-erlangen.de writes:
> maf@dtek.chalmers.se (Martin Forssen) writes:
> 
> > I'm afraid a lot of Swedes will refuse to accept any sorting order which
> > places aring and adiaeresis adjacent to a. In swedish these are completely
> > different characters and aring and adiaeresis comes after z. All of this
> > IMHO of course.
> 
> Isn't the Swedish convention to sort a-ring after z just as arbitrarily
> as the confusing old convention to sort a-diaresis in Germany as ae?
>

It might be to you, but to a Swede this is alphabetical order.  If you
want to sort A and A-ring together, you might also sort P and R
together based on their visual similarity, also E-F, O-Q, C-G, U-V-W
(V and W are sometimes sorted together in Swedish, although that
practice is becoming less common.  But they still teach in first grade
that the alphabet has 28 letters: A-Z, Aring, Adiaresis, Odiaresis,
excluding W.)

Many Swedes I know that regularly work on US-ASCII terminals prefer
using brackets and braces for the letters after Z, rather than typing
either a-a-o or aa-ae-oe.  At least the brackets are distinct, and
cannot be read as anything else.
 
> There are at least a few real world applications (I don't talk about
> trivialities like UNIX ls), e.g. catalogs of international libraries,
> where an _easy_ to understand language independend sorting standard would
> be extremely useful. Why not standardize one for Unicode in an easy
> _implementable_ way? Then let's see, how many people will adopt it and
> will quickly forget their traditional rules. Perhaps even many users
> in Sweden. There are perhaps already some multilingual sorting rules
> common practice, but I know no one that defines an easy implementable
> deterministic and total ordering for ISO 10646 strings.

For this application, I think English sorting order is rather well
established.  That doesn't mean language-adapted sorting conventions
will disappear, especially in countries like Sweden, Norway and Spain
where characters with diacritical combinations are considered distinct
and inseparable from their "base letters".

	/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
Keyboard not found, press F1 to continue or Ctrl-Esc for setup
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.std.internat
Subject: Re: The ultimate encoding
Date: 10 Jan 93 10:34:19 GMT
Organization: Enea Data AB

Masataka Ohta (mohta@necom830.cc.titech.ac.jp) writes:
>Erland Sommarskog (sommar@enea.se) writes:
>>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?

This last sentence should of course end: "...because it is treated
differently in different languages."

>If an application must neglect language difference, it can do so in the
>application.

It must equalize all the umpteen instances, yes. And it better do if
the user is not going to be violent when he is told "you got the wrong
sort of 'W' here, please replace". But of course the application still
has to follow the language rules preferred by the user. But then what's 
the point with all these umpteen instances? None.

>>Unicode is a tool for complete solutions for the world in the 21st century.
>
>Disagreed. Perhaps, you are trying to force all the people in the world
>(or, at least Japanese) to use Latin alphabet only in the 21st century.

It occurred to me later that I should have said 10646 and not Unicode
here. I don't want to say neither this nor that about the CJK stuff, as 
I know nothing about these languages and scripts, but as I understand
it with 10646 you can later add separate instances for non-unified 
characters.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Newsgroups: comp.std.internat
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: Naval Research Laboratory, DC
Date: Fri, 8 Jan 1993 02:11:24 GMT

In article <1ii0n7INN6ig@life.ai.mit.edu> glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) writes:

>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.  

Glenn is quite right, as usual.  

  But to prevent misunderstanding, folks should realise that for the
last several hundred years Vietnamese has been written using only
romanised letters and a small number of diacritical marks (Quoc Ngu as
distinguished from the former Chu Nom scheme).  Modern Vietnamese is
not an ideogrammatic language at all.

Ran
atkinson@itd.nrl.navy.mil
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.std.internat
Subject: Re: Let's develop ISO sorting rules
Date: 11 Jan 93 18:02:08 GMT
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
Organization: Regionales Rechenzentrum Erlangen
NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de

hpa@eecs.nwu.edu (H. Peter Anvin N9ITP) writes:

>> There are at least a few real world applications (I don't talk about
>> trivialities like UNIX ls), e.g. catalogs of international libraries,
>> where an _easy_ to understand language independend sorting standard would
>> be extremely useful. Why not standardize one for Unicode in an easy
>> _implementable_ way? Then let's see, how many people will adopt it and
>> will quickly forget their traditional rules. Perhaps even many users
>> in Sweden. There are perhaps already some multilingual sorting rules
>> common practice, but I know no one that defines an easy implementable
>> deterministic and total ordering for ISO 10646 strings.

>For this application, I think English sorting order is rather well
>established.

What the hell is this "English sorting order"? Is it a standard that defines
a deterministic total order of all Unicode strings? Where can I get the
document that defines it? Perhaps we are speaking
about the same idea, an international DEFAULT sorting order, that will be
acceptable in many countries. There is no reason, why the USA and China
can't share a common sorting order, there won't be any collisions.
There won't even be collisions if you add France and Germany.
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.
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. I am sure, that this is not possible with character
code based sorting, but that it is possible with a SLIGHTLY more
sophisticated algorithm. Why is everyone so uninterested in this idea?
I posted already many details of my suggested framework for this
standard. It consists of an algorithm and a big table that groups
characters that are sorted together (e.g. a, A, and all As with
diacritics are identified by this table to belong to one single group).
All of the many digit 7 versions in Unicode would be another group.
I don't have the experience to create the whole group table and the
(low priority ordering within the groups for totality of the relation),
but I hope, that the experts for CJK languages will also find suitable
sorting groups for these languages.

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
--- Wer, wie, was? Wieso, weshalb, warum? Wer nichts fragt bleibt dumm. ---
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.std.internat
Subject: Re: Language tagging
Date: 5 Jan 93 00:51:52 GMT
Distribution: na
Organization: Naval Research Laboratory, DC

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?
>
>What if, the mail is stored in some mail box, mixed with Chinese
>mails? How can he print the entire mail box?

  If he can't read it, he has very severe personal problems.  

  I don't have any ability in Japanese whatsoever.  Never tried to
learn the language.  But I can read Japanese Kanji just fine -- no
problems in parsing or understanding the Kanji -- based strictly on my
knowledge of Chinese.  There are differences in stroke order and in
the aesthetic appearance of Chinese and Japanese renderings of the
same character, but those differences do NOT impair readability of the
character.

  Now I have no opinion about what ISO 10646 did and whether it was
right.  I do know that it will not affect readability.
Newsgroups: comp.std.internat
From: tt@tarzan.jyu.fi (Tapani Tarvainen)
Subject: Re: Language tagging
Originator: tt@tarzan.math.jyu.fi
Organization: University of Jyvaskyla
	<1ii6bkINNf6c@rodan.UU.NET> <1993Jan8.081830.15294@eecs.nwu.edu>
Date: Sun, 10 Jan 1993 12:46:18 GMT

In article <1993Jan8.081830.15294@eecs.nwu.edu> hpa@eecs.nwu.edu (H. Peter Anvin N9ITP) writes:

>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.

I like this idea.  Can anybody see any serious problems with it?
(Of course the description above cuts some corners, like multiple
letters sorting as one, but I can't think of any such problem
that couldn't be handled in this scheme.)
--
Tapani Tarvainen  (tt@math.jyu.fi, tarvainen@finjyu.bitnet)
From: jamiller@kuhub.cc.ukans.edu
Newsgroups: comp.std.internat
Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
Date: 8 Jan 93 01:07:59 CST
Organization: University of Kansas Academic Computing Services

In article <1ii3ctINNp4c@rodan.UU.NET>, avg@rodan.UU.NET (Vadim Antonov) writes:
> In article <1993Jan7.063116.14846@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:

> All languages have a default sorting -- namely the one which is used in
> dictionaries. Existance of multiple sorting rules does not nullify
> the necessity of a default sorting which is sufficient for most cases
> and --more imortant-- can be done in an environment lacking the
> locale required for specialized sortings.
> 
> I bet 99% of users will not care WHICH sorting is used as long as they
> used to it. Other can have their own personal locale.

I missed the first part of the discussion so please forgive me if my
remark seems out of context, but default sorting will be appplication
dependent.

The existence of two distinct possible sortings is significant, IMO as
well.  Of course you will find 'words' in an order in a
Japanese-English or a Japanese dictionary arranged phonetically but
when you look in a Kan-Wa (Chinese character to Japanese) dictionary
they will be arranged by radical, fundemental segments of characters.

Users will care which sorting is used and will need both available
depending on the necessary actions.

> I've heard Japanese don't like that unification.

Perhaps because Chinese and Japanese differ in that Japanese have
phonetic and semantic characters.

> --vadim
-- 
jamiller@kuhub.cc.ukans.edu
James Miller

_chicchai .sig no ho ga ichiban iin janai ka..._
             Enlightenment Happens?
Newsgroups: comp.std.internat
From: bad@flatlin.ka.sub.org (Christoph Badura)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Organization: Guru Systems/Funware Department
Date: Tue, 5 Jan 1993 00:35:28 GMT
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages

In <8496@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:

>In article <1i2durINN2pj@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
[I don't know who wrote the following paragraph.]
> > >Moreover, one question: how would you encode the German A-umlaut such that
> > >it sorts properly (i.e. as if it is the letter combination AE)?

You can't. There are several sorting orders in use in Germany.

> > The sorting order should be strict -- if you have two identical words
> > with a-umlaut and ae in the middle is it the same word? If it is then
> > ae IS a variation of a-umlaut and should always be treated as a signle
> > letter.

That depends. The "Duden" (_the_ German Dictionary) considers them to
be distinct.

>I do not think you understand.  From the AVON (Amtliches Verzeichnis der
>Ortnetzkennzahlen) edition 1985, which gives area codes for the places in
>Germany.  The next is a selection of places mentioned ("o is o-umlaut):
>	Modautal
>	M"ockm"uhl
>	...
>	M"ornsheim
>	Moers
>	M"ossingen
>	...
>	M"otzingen
>	Mogendorf
>now come up with a coding that allows this (standard German) sorting.

This is _not_ standard German sorting, it's standard German PTT
sorting (and quite confusing at times).

The Duden treats umlauts as the corresponding vowel with respect to
sorting order (i.e. "o sorts the same as o etc.)

A side note: the German alphabet as teached in elementary school
consists of the letters a-z followed by the umlauts "a, "o, and "u;
the double-s isn't contained in that set. (That's what I remember,
anyway.)

>Note that it is not allowed to spell Moers as M"ors, that is a severe
>spelling error!  On the other hand in the absense of umlauts it is
>allowable to spell "o as oe (because it is in fact a shorthand for it),
>but to do so when there are umlauts available does not look very good.

And is in fact a spelling error. Writing oe instead of "o is only
allowed in the absence of real umlauts in the character set.

-- 
				Christoph Badura  ---  bad@flatlin.ka.sub.org

Personally, I don't care whether someone is cool enough to quote Doug
Gwyn--I only care whether Doug Gwyn is cool enough to quote. -- Larry Wall
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: ISO10646 Unicode
Date: 4 Jan 93 16:05:25 GMT
Organization: Tokyo Institute of Technology

In article <1993Jan1.163927.20277@prl.dec.com>
	boyd@prl.dec.com (Boyd Roberts) writes:

>In Chinese it would be natural if `sort' could sort on stroke count.
>Chinese dictionaries have indexes based on stroke count, as there is
>really no other way of locating a glyph whose reading (pronounciation)
>you do not know.
>
>In Japanese the problem is similar, but you have the kana which helps.

Completely wrong.

That Chinese-Japanese dictioary have several indexes one of which is
based on stroke count does not mean stroke count sorting is natural.

For example, the first half of JIS X 0208 is sorted by main (whatever
main means) pronounciation of each character and the rest is sorted
first by radicals and then by stroke count.

In Japanese, the only natural sorting is on pronouciation, whose
information is missing from character code. Otherwise, any sorting
is almost as good as other sorting.

						Masataka Ohta
Newsgroups: comp.std.internat
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Subject: Re: ISO paper sizes
Organization: U of Cambridge, England
Date: Mon, 4 Jan 1993 17:01:25 GMT

In article <1i9j4gEINN8nd@uni-erlangen.de> mskuhn@immd4.informatik.uni-erlangen.de writes:
>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.

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?)

I believe NIST inches are a standard unit in HyTime.

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.
Newsgroups: comp.std.internat
From: jhelling@cs.ruu.nl (Jeroen Hellingman)
Subject: Re: Future extension of ISO 10646
Date: Mon, 4 Jan 1993 10:24:48 GMT
Organization: Utrecht University, Dept. of Computer Science

[about having an A-umlaut for each language seperately to help sorting...]

I think it would be much wiser to use I higher level coding to indicate the
language of a string of characters. The scheme you propose would mean
indicating the language with every character you type -- I think a bit waste
of resources, whereas other standards (SGML) provide means of tagging a
character stream with this kind of information (although to me the SGML
standard is not fully clear about how to tag the language used)

Jeroen

-- 
Jeroen Hellingman                 E-mail: <jhelling@cs.ruu.nl>
't Zand 2                         Phone: +31-3473-73935 (home)
4133 TB Vianen                    (18.00--21.00 GMT)
The Netherlands                   Answer in English, German, or Dutch.