HDTenEightyP/NetNews huggingface dataset:
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 7 Jan 1993 15:43:51 +0100
Organization: Regionales Rechenzentrum Erlangen
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages

terry@cs.weber.edu (A Wizard of Earth C) writes:

>Consider that Runic encoding is antithetical in terms of single character
>changes for fixed record length files by virtue of it's ability to either
>change record size (destroying the seek-offset record addressing) or by
>changing the amount of data representable in a field (destroying the
>ability to use fixed-length fields for input in the front end client).

The C type Rune has been defined in the Tompson paper about Plan 9 Unicode
encoding as "unsigned short" = 16bit per character. The 1+ byte encoding is
called by all people UTF (there are different versions, Plan 9 uses UTF-2).
I believe you mixed up the meanings of UTF encoded and Runic encoding.

It seems to be absolutely obvious that there are many applications,
where a fixed length runic encoding with 16 bit/character is useful.
That's also the reason, why UTF <-> Rune translation routines (which
are very easy to implement) have been included in Plan 9 libraries.

There are also very good reasons to use UTF, especially, where 
compatibility with ASCII is of benefit.

Sorry, I don't understand your problem at all.

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. ---
Newsgroups: comp.std.internat
From: Erik Naggum <erik@naggum.no>
Reply-To: Erik Naggum <enag@ifi.uio.no>
Date: 10 Jan 1993 22:46:12 +0100
Subject: Re: ISO paper sizes

[Alasdair Grant]
:
|   1 SI inch is 2.54mm _exactly_, not just to 7 decimal places.

There is no Systeme International "inch".

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

"NIST" inches were aligned with the SI units well before 1982 (my earliest
reference to 1 inch = 2.54 cm), except for the US Survey foot, which is
~1.000002 ft, and reflects the old inch, for very sound reasons.

|   I believe NIST inches are a standard unit in HyTime.

The HyTime inch is 254/100 cm, or 2.54 cm, exactly.  There is no other
definition of inch in HyTime.  Of course.

Best regards,
</Erik>
--
Erik Naggum                 ISO  8879 SGML                    +47 295 0313
Oslo, Norway                ISO 10744 HyTime
<erik@naggum.no>            ISO  9899 C                 Memento, terrigena
<SGML@ifi.uio.no>           ISO 10646 UCS             Memento, vita brevis
Newsgroups: comp.std.internat
From: walters@HQ.Ileaf.COM (Tim Walters)
Subject: Re: ISO paper sizes
Organization: Interleaf, Inc.
Date: Tue, 5 Jan 93 19:18:40 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)

Printers in Germany and Japan use different sizes for the B series.
The German value is specified by DIN; I believe the Japanese value is
specified by some JIS standard:

        DIN             JIS    
B4      250x353         257x364
B5      176x250         182x257
B6      125x176         128x182
-- 
Tim Walters, Interleaf          uunet!leafusa!walters, walters@HQ.Ileaf.com
Newsgroups: comp.std.internat
From: doi@jrd.dec.com (Hitoshi Doi)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: ISO10646 Unicode
Organization: DEC Japan Research and Development Center
Date: Tue, 5 Jan 1993 02:00:08 GMT

In article <1993Jan4.214109.8143@prl.dec.com>, boyd@prl.dec.com (Boyd Roberts) writes:
# In article <2605@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
# > 
# > 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.
# > 
# 
# Applying your argument to languages that use the glyphs 0, 1, 2, 3, 4, 5,
# 6, 7, 8 and 9 to represent integers then it is only `natural' to sort
# them based on their pronounciation.
# 
# So in Japanese I will find myself sorting them in ascending order:
# 
#     1 ichi
#     9 kyu
#     5 go
#     3 san
#     4 shi
#     7 shichi
#     0 zero
#     2 ni
#     8 hachi

true, if that is how the numbers are intended to be read.

# But that would be wrong, because I can pronounce:
           ^^^^^ could

#     0 as rei
#     4 as yon
#     7 as nana
#     9 as ku

# So just how will you sort these glyphs based on `natural' pronounciation?

you have to know how it is intended to be read (pronounced).
otherwise you can't sort.

an example (sorted in ascending order):

 3rd (3 is read 'saa')
 sankaku
 3gatu (3 is read 'san')
 30 (30 is read 'sanjuu')
 4kaku (4 is read 'shi')
 13 (13 is read 'juusan')
 12 (12 is read 'juuni')
 3D (3 is read 'surii')
 3tsu (3 is read 'mi')
 4do (4 is read 'yon')
 123 (123 is read 'wan tsuu surii')

silly?

sorting Japanese using a mixture of kanji, kana, numbers, alphabets
can be really difficult.
--
Hitoshi Doi, International Open Systems Engineering        doi@jrd.dec.com
Japan Research and Development Center               decwrl!jrd.dec.com!doi
Digital Equipment Corporation Japan      [from JUNET: doi@jrd.dec-j.co.jp]
Newsgroups: comp.std.internat

Markus Kuhn writes:

>My vision is NOT a sorting order that is embedded in the character set.
>That would be too trivial, of course. The Unicode developpers had good
>reasons to embed one into the code table. No, I have a slightly more clever
>algorithm in mind, that will do 2 passes:
>
>   1. ignore punctuations etc. and group letters together before
>      comparing the strings.
>
>   2. No. 1 will not offer a total order, which should be supplied by a
>      beautiful sorting standard. So if 1 fails than compare the strings
>      completely without throwing any trivial information away. Rule 2 must not
>      conflict with rule 1, the partial ordering must only be completed.
>
>I am playing around with an algorithm that works this way since a few
>days, and the results are very promising and easy to understand intuitively.
:
:
>The method deals fine with punctuations in the strings (e.g. in
>bibliographic references and person names), is pretty efficient and
>easy to implement. Word lists produced by my algorithm are pretty easy
>to scan for human eyes. The solution is much more general than simple
>upcase conversion before lexicographic character code comparison which
>is often used today with US-ASCII.
>
>I still don't know, whether I should post the algorithm here, or whether
>I should write a paper or techreport first, as it is much more promising
>than all character code based lexical orderings that have been proposed here
>so far.

Markus,

   I must admit severe scepticism here, but I am sincerely interested
in what you are doing.  Please post details if you feel you can.

   My scepticism is basically this:  I guess you have probably come up
with a method which you believe is more-or-less acceptable to Europeans
and North/South Americans.  What about Chinese, Japanese, Korean,
Hebrew, Arabic, all the Indic languages, Thai, etc?  These are all
commercially important markets, and they have very different sorting
requirements.  Some things you mention, like ignoring "punctuation",
simply won't work for some languages.  For example, in Japanese there
are "punctuation" marks like the "ditto" mark (which means duplicate the
last Kanji) or the Katakana "dash" (which means extend the previous
vowel).  These (should) affect collations.  I am sure there are dozens,
if not hundreds, of similar cases.

  Personally (and professionally :-) I believe that the support of
multiple and complex collation algorithms is a necessary and permanent
feature of internationalized programs.  This problem cannot be wished away.

  For *internal* purposes (B-trees, etc) a simple sort based on numeric
character codes (8, 16 or whatever bits) will always work, and is the
fastest method possible.

  I don't see a market need for the kind of "in-between" solution you
are proposing (but I am still interested...)

--arne

Arne Thormodsen
CSO Internationalization
Hewlett-Packard

DISCLAIMER:  These views are my own and do not necessarily represent
any views of the Hewlett-Packard Company.
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.std.internat
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: 10 Jan 93 03:34:26 GMT
Organization: Tokyo Institute of Technology

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

>>>Tell me how I sort on stroke count in Unicode without ``locale-specific
>>>algorithms or hard-coded data''?
>
>If it is Han characters that are being sorted, then Unicode already orders
>them according to KangXi radicals (214) and (additional) stroke count.

Different characters are mapped to a single code point in 10646/Unicode.

Different Characters with different stroke counts are mapped to a
single code point in 10646/Unicode.

Thus, if you use 10646/Unicode, stroke count is context dependent. Don't
use it.

						Masataka Ohta
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Fri, 8 Jan 1993 09:41:19 GMT

In article <1993Jan7.065611.15193@fcom.cc.utah.edu>, terry@cs.weber.edu (A Wizard of Earth C) writes:
> 
> Again, sorting can not be safely tied to character set lexical order for
> all languages.  I disagree with Boyd here.  Localization with Unicode is
> a piece of cake.  Unicode allows it to be entirely data driven, with no
> locale-specific algorithms or hard-coded data.
> 

Maybe you should check your attributions, but I have never advocated
that the code values can be used to do lexical sorting in the general
case -- far from it.  Your above paragraph contains a contradiction
as I read it.

Tell me how I sort on stroke count in Unicode without ``locale-specific
algorithms or hard-coded data''?

Re: `san'

    It can be used on either the family name of the first name.
    This assertion is based on current common practice in Japan.

    If you knew Ohta-san reasonably well (ie. friend or colleague)
    and were contemporaries you could use `kun' instead of `san'.


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
From: melby@dove.yk.fujitsu.co.jp (John B. Melby)
Newsgroups: comp.std.internat
Subject: Re: Unicode Han Characters [was Re: Language tagging]
Date: 8 Jan 93 10:20:34 GMT
	<MELBY.93Jan6113951@dove.yk.fujitsu.co.jp>
	<1if6lgINN6ri@life.ai.mit.edu>
Organization: Open Systems Group, Fujitsu Limited, Yokohama
In-reply-to: glenn@wheat-chex.ai.mit.edu's message of 6 Jan 93 17:59:12 GMT

>>Of course, there is one major flaw in the preliminary Unicode version:  the
>>Japanese simplified form of "sakura" (ying1hua1 de ying1) is not included.
>
>I'm not sure which "preliminary" Unicode version you are referring to;
>however, Unicode does have at U+6A31 the character ying1hua1 de ying1.
>Is the simplified Japanese form you refer to contained in JISX0208 or
>JISX0212?  If it is, then it is in Unicode 1.0.

This fallacy seems to have originated in an "official"(?) Unicode survey
posted to JUNET a while ago.  I have been corrected on this point - the
unsimplified character is 6AFB, the Chinese simplified character is 6A31,
and the Japanese simplified character is 685C.

-----
John B. Melby
Fujitsu Limited, Yokohama
melby@yk.fujitsu.co.jp
From: melby@dove.yk.fujitsu.co.jp (John B. Melby)
Newsgroups: comp.std.internat
Subject: Re: Language tagging
Date: 11 Jan 93 13:29:17 GMT
	<TT.93Jan7085019@tarzan.jyu.fi> <1ii6bkINNf6c@rodan.UU.NET>
Organization: Open Systems Group, Fujitsu Limited, Yokohama
In-reply-to: avg@rodan.UU.NET's message of 7 Jan 93 21:12:20 GMT

>>Let's look at it this way:  How would a Finn want to see Chinese
>>names sorted?
>
> If (as is likely) he doesn't know Chinese he either
>>couldn't care less, or would want them transliterated into Latin
>>characters (and then sorted by Finnish rules).
>
>Ever saw Chinese transliterated into Latin? :-) You generally
>can't do it and keep it intelligible because phonetic structures
>of languages are fairly different.

It is feasible to sort Chinese names in the Putonghua-Pinyin order.
(Of course, there may be problems if this is done programmatically,
since many characters have two or more pronunciations.)

This is even more so in the case of Japanese, where a name like Kouichi
Watanabe could just as easily be Hirokazu Watabe, and the characters
for "hinagata" can also be pronounced "suukei."

In Japanese databases, ordering information is stored in a separate
field from the character encoding, making the kanji ordering somewhat
irrelevant for sorting.

If one wants to make sense out of an ordered multilingual list, it might
be a good idea to provide the following information for each item:

(1) Source language of data item.  The sorting algorithm may or may not
    use this information to arrange different languages into separate
    lists.
(2) Ordering information in source language, where necessary.
(3) Official or arbitrary Romanized equivalent, where necessary.
    (Since people romanize their names differently, the use of this field
     may result in conflicting entries for the same name, such as Otsu,
     Ootsu, Ohtsu, Otu, Ootu, and Ohtu.  There is probably no easy
     solution to this problem.)

-----
John B. Melby
Fujitsu Limited, Yokohama
melby%yk.fujitsu.co.jp@fai.com
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.std.internat
Subject: Re: ISO paper sizes
Date: 5 Jan 93 00:10:59 GMT
Organization: CWI, Amsterdam

In article <1993Jan4.170125.3951@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:
 > In article <1i9j4gEINN8nd@uni-erlangen.de> mskuhn@immd4.informatik.uni-erlangen.de writes:
 > >
 > >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?)
 > 
Never knew this, but looked it up (in a British book, no less, from the
early 60s) and indeed, an US inch is ~25.4000509 mm (and not approx.
2.54 mm, Alasdair uses very small inches, or did he intend a deciinch?).
-- 
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: bengtl@maths.lth.se (Bengt Larsson)
Subject: Re: Let's develop ISO sorting rules
Organization: Lund Institute of Technology, Sweden
Date: Thu, 7 Jan 1993 00:42:24 GMT

In article <maf.726345946@dtek.chalmers.se> maf@dtek.chalmers.se (Martin Forssen) writes:
>unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn) 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?
>
> 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.

No IMHO needed. This is definitely not acceptable for swedish. 
"v" and "w" are commonly sorted together, however.

> I think it would be great if one could design a single sorting order based
> on character positions, but IMHO this is impossible. 

Oh yes, clearly.

>There is a too great
> mass of people out there who won't change... I think we will have to define
> some sort of list which defines the local sorting order.

Sorting orders are notoriously complicated anyway, if you want to get
it really "right".

-- 
Bengt Larsson - bengtl@maths.lth.se
From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.std.internat
Subject: Re: Future extension of ISO 10646
Date: 5 Jan 1993 03:16:11 GMT
Organization: MIT Artificial Intelligence Laboratory
NNTP-Posting-Host: wheat-chex.ai.mit.edu

In article <1993Jan4.102448.9710@cs.ruu.nl> jhelling@cs.ruu.nl (Jeroen Hellingman) writes:
>(although to me the SGML
>standard is not fully clear about how to tag the language used)

The Text Incoding Initiative (TEI), which is based on SGML, provides
for a Writing System Description which allows an attribute "lang"
(value is a writing system identifer) to be applied to any element.

Glenn

Newsgroups: comp.std.internat
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 15:03:05 GMT

mskuhn@immd4.informatik.uni-erlangen.de writes:
>THE SOLUTION IS SIMPLE ONCE YOU ACCEPTED THAT INCOMPATIBILITY WITH
>EXISTING HISTORICAL RULES IS NECESSARY!

I don't accept it.  Computers have to change to please users, not the
other way around.

There is no sorting order that will satisfy everybody.  Thus it is not
a good idea to embed one into the character set and make everybody use
it.

I have had no problem sorting strings in character sets where the
order of the letters is not the same as the order in my alphabet.
(I'm not claiming that it is trivial in all languages, though, but as
far as I can see, it is more or less trivial for all languages that I
know.)

My humble, uninformed opinion, of course.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
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: 7 Jan 93 09:22:54 GMT
Organization: Tokyo Institute of Technology

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

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

>	the layer handling character transport need not know.

Then, after the transport, the distinction information is lost.

>one would presume the display layer needs to know. as for seeking,
>we can find word boundaries and all sorts of useful things WITHOUT
>knowing higher-level information such as font changes or size changes.

"all sorts of useful things"? Then, how can display the part of the text
after seek? Isn't displaying characters useful?

>	we've come a long way; from a guess of mine as to how
>NT does internationalisation, you've deduced 10646 is utterly hopeless.

No, no. Regardless of NT, 10646 itself is utterly hopeless. I only made
you realize that.

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

>> >	damned if i know where i said the text was english.

>> How damned Plan9 is. It is much better to be said "Not a tty" than
>> "iwmczal aslkdjf lskjancm aslkio" on inappropriate ioctl.

>	what? you said plan 9 is crap because it uses english. i replied
>that i never said plan 9 had to use english. you reply plan 9 is crap because
>it doesn't use english.

Yes. That the Plan9 with English error status is worse than the current
UNIX with integer error status does not mean you can't make Plan9 even
worse.

>> Internationalization of "errno" interpretation is a simple and
>> already-solved problem.

>	really? i would think so for the cases like posix where there is
>a predefined list of alternatives and implementations such
>as a list of language-dependent strings indexed by error numbers work
>just fine. when the errors are not so constrained, i am unaware
>of any general solution. does anyone know of one? if so, could you
>describe it here or email me please?

Simple.

Let all error classes be known in advance and provide appropriate
messages locally to each class of errors.

						Masataka Ohta
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.std.internat
Subject: List of ISO paper formats (A4, ...)
Date: 6 Jan 1993 17:53:54 +0100
Organization: Regionales Rechenzentrum Erlangen
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de

Everyone uses them each day, but nobody knows the sizes, so here is a
list for the USENET community. Please proof read it, before I'll include
it in the standards FAQ.

Markus

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

International paper formats
---------------------------

The paper end formats defined by ISO in the A, B and C series are used
today in nearly all countries apart from North America.

The formats have been determined according to the following rules:

  - A0 has an area of one square meter.
  - The format of all members of the A, B and C series is 1 : sqrt(2).
  - You get the next higher format by cutting the paper in two
    equal pieces parallel to the shorter side. This results again in
    an 1 : sqrt(2) format (that's the big advantage of this format).
  - The size of a B paper is the geometric mean between the size of
    the corresponding A paper and the next bigger A paper. E.g.
    B1 is between A1 and A0.
  - The size of a C paper is the geometric mean between the size of
    the A and B paper with the same number.

The following table lists the paper sizes rounded to an integral number
of millimeters, which is the official definition:

      4 A0 1682 x 2378
      2 A0 1189 x 1682
        A0  841 x 1189       B0 1000 x 1414       C0  917 x 1297
        A1  594 x 841        B1  707 x 1000       C1  648 x 917
        A2  420 x 594        B2  500 x 707        C2  458 x 648
        A3  297 x 420        B3  353 x 500        C3  324 x 458
        A4  210 x 297        B4  250 x 353        C4  229 x 324
        A5  148 x 210        B5  176 x 250        C5  162 x 229
        A6  105 x 148        B6  125 x 176        C6  114 x 162
        A7   74 x 105        B7   88 x 125        C7   81 x 114
        A8   52 x 74         B8   62 x 88         C8   57 x 81
        A9   37 x 52         B9   44 x 62         C9   40 x 57
        A10  26 x 37         B10  31 x 44         C10  28 x 40

The most popular sizes are perhaps:

        A0        technical drawings
        A4        letters, magazines, documents
        A5        books
        C4,C5,C6  envelopes
        B4,A3     supported by many copy machines, newspapers

There are also stripe formats possible, e.g.

    1/3 A4   99 x 210
    2/3 A4  198 x 210
    1/4 A4   74 x 210
    1/8 A4   37 x 210
    1/4 A3  105 x 297
    1/3 A5   70 x 148
    etc.

(The values have been copied from DIN 476 (Dec 1976) which is the German 
version of the ISO standard).

------------------------------------------------------------------------
        
-- 
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. ---
Newsgroups: comp.std.internat