HDTenEightyP/NetNews huggingface dataset:
From: mclemore@edsel.eng.gtefsd.com (Ken McLemore)
Newsgroups: comp.std.unix
Subject: 1003.2 Status, manual page conventions ?
Date: 28 Jan 1993 11:11:07 -0800
Organization: Contel Federal Systems
Reply-To: mclemore@edsel.eng.gtefsd.com (Ken McLemore)
NNTP-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: std-unix@uunet.uu.net

Submitted-by: mclemore@edsel.eng.gtefsd.com (Ken McLemore)

i may get flamed but here goes,

i'm looking for a POSIX convention for manual pages (Section 1,2,3,4,5,8)
and 1003.1 alludes to 1003.2 as possibly supplying the manual page
conventions.  does 1003.2 address this issue and what is the current status
of 1003.2 (eg. draft, being published, etc) ?

thanks in advance, ken

Volume-Number: Volume 30, Number 42
Newsgroups: comp.std.mumps
From: DIAMOND.JON@forum.va.gov
Subject: Changes to Proposal Rules
Volume-Issue: X11/1993.info/comp.std.mumps/1
Organization: PFCS Corporation
Date: Sun, 24 Jan 1993 17:08:00 GMT

Having had to look up our Proposal Rules (X11/91-25) I find that  
 
a) we haven't been observing them precisely
b) they are not totally appropriate anyway
  
I would suggest the following changes
 
a) Eliminate the references to SC2 and SC10 (we could update 
these refs to SC12 +, but I think that it should be the responsibility
of all SCs to be checking other SC type A documents)
Delete paras III.D.5 and V.B.2
 
b) Eliminate the automatic "pros" 
Delete III.C
  
c) We need to recognise that their are other documents that we are
handling that are not going to be incorporated into the MUMPS 
Standard.
In the opening section replace all occurences of
"ANSI Standard MUMPS" and "MUMPS standard" with "ANSI Standard MUMPS 
language specification".
 
Add a completely new section to the end
"In addition to Proposals which are to become part of the MUMPS 
standard language specification the MUMPS Development Committee also 
has the following types of documents which are handled in a 
similar manner to these:
 
1. Proposals to be incorporated into standards produced by the
MUMPS Development Committee other than the MUMPS 
language specification (X11.1)
 
2. Specification Guidelines
These are documents which are intended to provide guidance and
direction for persons preparing modifications or extension to one of the 
standards produced by the MUMPS Development Committee
  
3. Technical Reports
These are documents which provide supplementary information
which may be useful to readers or implementors of the standards 
produced by the MUMPS Development Committee.
 
Items in category 1) are handled in exactly the same way as MUMPS
language specifications, except that they are incorporated in or create
new standards documents. 
 
Items in category 2) and 3) are handled in the same way except that 
they remain as standing documents of the MUMPS Development 
Committee once having achieved MDC Type A status. However, they 
may be amended or rescinded only by raising a Subcommittee Type
A document incorporating the amendment/recision to MDC Type A 
status."
 
In all the disclaimers delete all occurences of the word "language".
 
d) We also refer to ANSI in a number of places.
This should probably be replaced by ANSI/ISO with the following
exceptions and every reference to "canvass" replaced by 
"ANSI canvass/ISO approval"
 
-- 
Xref: sparky comp.std.internat:1261 soc.culture.nordic:8373 soc.culture.german:10135 soc.culture.french:9874 alt.folklore.computers:19157 news.future:946 news.admin.misc:1178
From: kankkune@klaava.Helsinki.FI (Risto Kankkunen)
Newsgroups: comp.std.internat,soc.culture.nordic,soc.culture.german,soc.culture.french,alt.folklore.computers,news.future,news.admin.misc
Subject: Re: European characters (was 8-bit news)
Date: 21 Jan 93 18:30:45 GMT
Organization: University of Helsinki, Department of Computer Science

>Another interesting bit:  Some news postings have various punctuations
>in the places of Scandinavian characters that do not exist in the
>American alphabet.  I don't remember the equivalences.  They always
>show as the puncutations, curly braces, vertical bar, etc, on my
>terminals and on the Xerox 4075 laser printer I usually use.

>I'm guessing:
>some writers are substituting US punctuations and probably are on
>machines that can't generate Scandinavian characters but others are
>apparently using machines that actually do create Scandinavian
>characters and are sending them in postings; they appear as US
>punctuations when the high bit is stripped.

No bit stripping here, the character set is a national variant of ISO
646 and is 7 bits wide. It substitutes curly braces etc. with those
national characters. You then need a terminal and printer equiped with
the right character sets to see those character right. Or you just have
to get used to see and type those braces and replace with the right
national glyphs in your mind. This is what many people here do. For
programming you need those braces from ASCII and for other text the
national characters from the 646 variant. It's too tedious to switch the
terminal character set, so you just keep it ASCII. Or, to my disgust,
keep it in 646 mode and type adiaeresis etc. instead of braces in your C
programs.

>I'm still after the ISO 16bit (I hope) _standard_.

ISO 10646 is a 32 bit character set. As part of it it has a 16-bit plane
also known as Unicode.
-- 
                  dos, windows, nt... are you a victim of the MS disease?
Newsgroups: comp.std.internat
From: hpa@merle.acns.nwu.edu (H. Peter Anvin N9ITP)
Subject: Re: European characters (was 8-bit news)
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Organization: You must be kidding!
Date: Sat, 23 Jan 1993 22:23:46 GMT

In article <1993Jan22.113702.24119@odin.diku.dk> of comp.std.internat,
  klaus@diku.dk (Klaus Ole Kristiansen) writes:
> 
> ae, o/ and aa follows z in that order in the alphabet, so they
> get the next characters after z {|}. The Swedish alphabet,
> however, ends "o, "a, aa. So in "Swedish ASCII", the
> letters are not even in alphabetical order. Someone must
> have decided that it was more important to have Swedish
> letters print as the letters with the same pronounciation
> on Danish and Norwegian printers.
> 

Just a correction: the Swedish alphabet ends \ringA (]) \"A ([) \"O
(|).  But it was indeed adapted for automatic transcription into and
from Danish and Norwegian.

	/hpa
From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.std.internat
Subject: Re: Cleanicode
Date: 23 Jan 1993 16:41:19 GMT
Organization: MIT Artificial Intelligence Laboratory
NNTP-Posting-Host: wheat-chex.ai.mit.edu

In article <2790@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>LGC are used mostly by Indo-European languaes. They share the single
>culture, the European culture. They even share the major religion,
>Chiritianity.

Ohta-san,  you need to study writing systems more.  If you bother to look
at the languages of Africa and Indonesia which are written with the Latin
script, you will find that they are perhaps 10-20 times in number as
Indo-European languages which use Latin script.  The same can be said of
Cyrillic: more non-Indo-European languages are written with Cyrillic than
Indo-European languages.

It is also clearly not true that all of these communities (or even a 
majority of them) are Christian.

Glenn Adams
Newsgroups: comp.std.internat
From: mduerst@ifi.unizh.ch (Martin J. Duerst)
Subject: Re: Cleanicode
Organization: University of Zurich, Department of Computer Science
Date: Mon, 25 Jan 93 19:49:38 GMT


In article <MELBY.93Jan21142028@dove.yk.fujitsu.co.jp>, melby@dove.yk.fujitsu.co.jp (John B. Melby) writes:
> >In summation, it is clear to me that LGC should not be unified, but I
> >would feel more comfortable if I could articulate what it means to be
> >an autonomous script. Suggestions welcome, as always.
> 
> This is essentially the same message that I posted in a Japanese newsgroup
> this morning, but anyway...
> 
> Latin, Greek and Cyrillic typefaces have traditionally been developed
> separately, and ("TeX" notwithstanding) they are generally not combined
> with each other to form words.  When a Greek or Russian word appears
> in English text using an entirely different font from the Latin font,
> it does not necessarily look out of place.
> 
> When a Chinese place name appears inside Japanese text using a Chinese
> typeface (ignoring for the moment differences in official simplified
> characters), it is legible but looks slightly out of place.  Whether
> this means that Chinese and Japanese characters may be treated as a
> single script, or that Japanese usage involves the "translation" of
> Chinese place names from the Chinese script to the Japanese script,
> depends on one's political bias.
> 
> -----
> John B. Melby
> Fujitsu Limited, Yokohama
> melby@yk.fujitsu.co.jp
In addition, pronounciation is changed to one of the Japanese readings too,
for most Chinese names. Makes it pretty complicated if you want to discuss
Chinese politics (or whatever) in Japan as a foreigner. You know a (bad)
approximation of the Chinese pronounciation, but neither the writing (Kanji)
nor the Japanese pronounciation. But for Koreans, at least magazines
give furigana (or should I say furikana, as these are katakana?), whereas
I don't remember the newspapers.


----
Dr.sc.  Martin J. Du"rst			    ' , . p y f g c R l / =
Institut fu"r Informatik			     a o e U i D h T n S -
der Universita"t Zu"rich			      ; q j k x b m w v z
Winterthurerstrasse  190			     (the Dvorak keyboard)
CH-8057   Zu"rich-Irchel   Tel: +41 1 257 43 16
 S w i t z e r l a n d	   Fax: +41 1 363 00 35   Email: mduerst@ifi.unizh.ch

----

Newsgroups: comp.std.internat
From: bygg@sunet.se (Johnny Eriksson)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Personal flaming
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Fri, 22 Jan 1993 09:05:30 GMT

In article <2770@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:

>I have come again. I'll be happy if you stop dreaming and shut up.
>
>						Masataka Ohta

We can only notice that you have come here again, and we are very
unhappy about it.  You are the one that should keep shut up, since
you obviously can't behave in a public medium.  If you learned to
behave in a civilized manner, perhaps some people would listen to
what you have to say.  Right now the only thing you succed to do
is provoking anger.

Followups to alt.flame, please.

--Johnny
Newsgroups: comp.std.internat
From: nordin@qucis.queensu.ca (Brent Nordin)
Subject: Re: ISO standard for icons?
Organization: Computing & Information Science, Queen's University at Kingston
Date: Thu, 28 Jan 1993 16:33:56 GMT


In article <2440@miranda> you write:
>I'm sure I saw somewhere recently that there is an ISO standard for
>icons available. Could someone please tell me the standard number.
>
(I tried mailing to you directly, but without success - I tried both the
return address in the header, and the one in your signature)

I expect this is the document you are looking for:

ISO/IEC CD 11581 Information Technology - Text and Office Systems - Graphical
Symbols Used on Screens: Interactive Icons.

This document is in the development phase and may have been renamed and/or
renumbered last November.  Hope this helps you in your search.

Brent Nordin
nordin@qucis.queensu.ca
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.internat
Subject: Re: The ultimate encoding
Date: 21 Jan 93 17:02:58 GMT
Organization: Tokyo Institute of Technology

In article <1993Jan10.103419.2364@enea.se>
	sommar@enea.se (Erland Sommarskog) writes:

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

What? How do you think about a system which distigushes 'A's in
Latin/Greek/Cyrillic and tells "you got the wrong sort of 'A' here,
please replace"?

The system is just poorly desinged.

>But of course the application still
>has to follow the language rules preferred by the user.

Applications just says there is something wrong in applications' own way.
In good applications, the error messages should be smart. Then, users
correct errors as they like. That's all.

>But then what's 
>the point with all these umpteen instances?

For almost all purposes, there is only one correct instance.

But, sometimes, it is necessary to make ambiguious serach of, say,
personal names in Han characters. Then, the language information should
be dropped. BUT, at the same time, it is necessary to unify many characters
which have different code points in Unicode. Many Han characters which
have quite different forms share the common origin and should be
considered equal for the ambiguious search.

						Masataka Ohta
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.std.internat
Subject: Re: Cleanicode
Date: 24 Jan 93 17:14:47 GMT
Organization: Enea Data AB

David J Birnbaum (djbpitt+@pitt.edu) writes:
>Things get messier one character over, however,
>where L <B> corresponds in form to GC <V>, so that the form and
>phonetics are not aligned. 

This is a bogus argument. There are only a handful characters in 
the Latin script which have have a unified phonetic value. Of the
mainstream characters only F, M and P seems to qualify on an initial 
inventory. With a little more generosity we can add N, L and R. (If
we in the latter case change "phonetic" to "phomenic".)

Had you taken the shape P you would at least had something which
looked like a case, but in the case of B the reason for the difference
is simply the same sort phonetic evulotion which is the reason for
most of the varying usages of the Latin letters.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
From: andersa@Riga.DoCS.UU.SE (Anders Andersson)
Newsgroups: comp.std.internat
Subject: Re: Character Sets Need Smiley
Date: 24 Jan 1993 05:01:37 GMT
Organization: Uppsala University, Sweden
Distribution: world
NNTP-Posting-Host: riga.docs.uu.se

In article <1993Jan20.232413.19449@fcom.cc.utah.edu>, terry@cs.weber.edu (A Wizard of Earth C) writes:
> In article <1jhokpEINNmhm@uni-erlangen.de> mskuhn@immd4.informatik.uni-erlangen.de writes:
> >BTW: I just discovered a few seconds ago, that xterm X11R5 can't display with
> >font -b&h-lucidatypewriter-medium-r-normal-sans-12-*-*-*-m-*-iso8859-1 the
> >NBSP (0xa0) character. Is this a well known bug?
> 
> The font you reference is not a fixed-width font; you probably shouldn't
> be using it with xterm (which expects fixed character cells) anyway.

The "m" in field #11 of the font description supposedly indicates
that the font is monospaced; doesn't that imply that all printable
characters (including space) have the same width (as you may expect
from a `typewriter' font)?  Whether NBSP counts as a printable
character is of course debatable.  I happen to use this very font
for reading Usenet News, where articles often require fixed-width
character display...
--
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: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.internat
Subject: Re: Alphabets
Date: 24 Jan 93 23:31:26 GMT
Organization: CWI, Amsterdam

In article <1jutusINNlfa@life.ai.mit.edu> glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) writes:
 > >There are about as many Latin alphabets as there are languages written
 > >with the Latin script, however many of them coincide. But if even if
 > >they coincide, the languages may use different modifiers.
 > 
 > I believe your terminology is problematic here.  There is only one Latin
 > alphabet, namely, the one used by the Romans.  What I think you want to
 > say is that there are many Latin script-based alphabets.  We can distinguish
 > between the Latin alphabet (as used by the romans), and a somewhat
 > artificial construct, the Latin script (as used by various alphabets).
I think Erland meant this indeed.
 > 
 > The Latin script can be though of as the union of symbols contained in
 > all alphabets which are predominantly derived from the symbols used in
 > the Roman alphabet.
I have no problems with this and what followed.  But now my question becomes:
"What is Unicode encoding?".  Scripts?  Writing system?  It is not encoding
the Latin script I think.  Consider for instance the German writing systems
that have been used.  Fraktur.  Is that a different font?  Suetterlin.  Is
that a different font?  Many would think the latter not predominantly derived
from the symbols used in the Roman alphabet.  I see them as being more
derived from the Germanic Runes.  Still, there is a 1<->1 corespondence
between the symbols in the Suetterlin script and the German version of the
Latin script (I think).  (I have some printed stuff in the Suetterlin script.
I think there are very few people on the net able to read it, even in
Germany.  Below follows an approximation of lower case e:
	/| /|
	 |/ |
	 |  |
	 |  |
When there is interest I could scan in an advertisement in Suetterlin and
mail it around.)

 > The decision on whether to unify the symbols drawn from a collection of
 > alphabets (i.e., to form a unified script which can represent the
 > different alphabets) should be based on the utility of performing
 > unification and not on linguistic or cultural relations among the
 > different alphabets [see my previous message on Script unification].
I think you should add that unification of different scripts is possible
iff the scripts can be viewed as just being font changes (although the
derivation of the scripts can be completely different).  So while you
can unify the Suetterlin and the Latin script, you can not unify Latin
and Greek script although Latin is derived from Greek.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.std.internat
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Cleanicode
Organization: Weber State University  (Ogden, UT)
Date: Mon, 25 Jan 93 00:16:33 GMT

In article <ISHIKAWA.93Jan21204416@ds5200.personal-media.co.jp> ishikawa@personal-media.co.jp writes:
>   The problem is one of an existing character sets having multiple
>   possible reverse translations of a single code point.
>
>   A similar condition would be a Japanese/Chinese character set standard
>   which had seperate code points for characters unified by Unicode; if
>   such existed, then there would be no round-trip for characters translated
>   from that character set to the Unicode character set -- the correct code
>   point within the Japanese/Chinese combined set could not be identified
>   by the Unicode character itself.  No such example exists.
>
>I am an ignorant programmer. So bear with me. There is no such
>example, is there?  [From what I heard, strictly hearsay, mind you,
>there seem to be a few characters that would look slightly differently
>on printed paper and yet were put into the same code point. This
>slight difference might be big enough for some to scream and small
>enough for others to ignore.  If someone knowledgeable could shed some
>light on this mattter, I would be grateful.]

This is only true if the "round-tripping" were done from a character
recognition standpoint, where the input character could not be recognized
becuase of it being drawn differently.  While I can think of several
examples here, they are pretty much non-applicable because the seperation
of the rendering engine technology from the storage and process coding
of the data.

A particular example would be a font with both Chinese and Japanese
characters which did not chare code points, ie:

	--------		--------

	  ----  		  ----  

	--------		--------

	0x9915			0x9272
	(Japanese)		(Chinese)


I don't believe such a font exists.  It's possible to create one, but
unless it ends up widely accepted, I expect that this would not impact
future revisions of Unicode.

>Wonder if there was such combined
>Latin/Cyrillic/Greek standard at the time of Unicode design.

ISO 8859-5 and IS 8859-7 seem to me to qualify.


					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

>This is what I was proposing.  Each character would require a sequence
>of code points, but the same is true of any English word.

And this is the fault of decomposition schemes.  They do not reduce the
number of distinct encodings needed to represent characters, and so do
not reduce the number of bits.  They simply rearrange the bits
differently.

The only issue is that in a UNIFIED character set, like UNICODE, fully
composed Han characters take most of the space.  Well, too bad.  UNICODE
was not developed in Asia, and had no *initial* Asian input [flame away
guys, this is my opinion and I have been fairly well roasted in the past
for it :-) ]

The reason this issue bothers me so much is what I perceive as the process:

1> A somewhat novel idea (a universal character encoding) is developed
in the US.

2> It does not address the needs of Asian users very well.

3> It is marketed agressively in the US.

4> *US* developers like it, but must meet the needs of their Asian customers.

5> To meet this need more Han characters are put in the set than was
envisioned by the original developers.

6> The Asian customers are blamed for this.

Blaming customers for not liking your product is economic suicide!  How
well do you think Honda would be doing in the US if they had kept on
pushing their original "rollerskate-with-an-engine" entry into the US
market?  How well would Microsoft be doing if they had continued to
ignore the popularity of GUI's and stuck with the original DOS?  If the
customers want something other than you are delivering then that is 100%
your problem, period.

Personally (and I mean this, this is is strictly my opinion) I think
that the entire 16K hole in UNICODE should be filled with Han characters
and all of the silliness about Hieroglyphics, etc be pushed into some
character plane in hyperspace.  This has much to to with the proportion
of my salary which comes from HP sales to East Asians vs. the
proportion of my salary which comes from HP sales to ancient Egyptians.

I am not an idealist, I am in this to make money... :-)

--arne

DISCLAIMER:  These opinions are completely my own and have no relationship
to any position or view of the Hewlett-Packard Company.