🚀 go-pugleaf

ISO 6937 was originally in the first draft MOTIS document.  CEN/CENELEC
and NIST chose to include this character set together with a "default
rendition method".  The latter maps non-ASCII characters to ASCII codes
so they can be displayed on an ASCII terminal, arbeit with loss of
information.

ISO 6937 has several options, but basically extends the IA5 by prefixing
some characters with an escape code.  ISO 8859 extends IA5 by using the
eighth bit and thus, less characters are possible than ISO 6937.

In fact, we had a lot of arguments in NIST over which codes we should
include as body parts.  One of the arguments used was that FTAM
supports ISO 8859, but as I recall, we settled on ISO 6937 since this
was decided by CEN/CENELEC in their X.400 profile.

                                            ....Erik.

ISO 6937 and ISO 8859 are both extensions of ASCII (or ISO 646) to 8 bits.
Both of them avoid not only the 32 control characters of ISO 646 (columns
0 and 1) but also their 8-bit equivalents (columns 8 and 9), so as to avoid
possible transmission or other difficulties.

The most important difference is that ISO 6937 has "floating diacritics"
- characters of "zero width" representing accents, so that accented characters
are represented by two bytes, one for the unaccented character and one for
the accent.  This means that it can accommodate many more accented characters
within 8 bits than can ISO 8859.  In fact it copes with almost all languages
using a Latin based alphabet.  

However, it also means that most existing software, such as text editors,
will not cope with ISO 6937, whereas most software needs little or no
modification to work with ISO 8859.  Probably this is why ISO 6937,
although it came earlier than ISO 8859, has never really been adopted,
whereas ISO 8859 is becoming very widely used.

ISO 8859, because of the limited number of characters which it gets into
8 bits, has to be split into several parts.  ISO 8859-1 covers nearly all
Western European languages, which includes a lot of languages with economic
clout.  ISO 8859-2 covers Eastern European languages with a Latin based
alphabet such as Czech and Polish.  ISO 8859-2 and 8859-3 mop up some of
the gaps.  ISO 8859-5 is for languages like Russian with a Cyrillic alphabet,
8859-6 is for Arabic, 8859-7 is for Greek and 8859-8 is for Hebrew.
ISO 8859-9 is a late addition; it adds to ISO 8859-1 the characters needed for
Turkish, at the expense of Icelandic, which has far fewer speakers than Turkish
but which got included ISO 8859-1 because the Icelanders got into 8-bit
computing at an early stage and also because some of the characters are used
in Old English.  I don't know whether ISO 6937 has any additional parts for
languages such as Russian or Arabic with a non Latin alphabet.

ISO 6937 is a development from Teletex.  ISO 8859-1 is a development of the
DEC multinational character set.  Various manufacturors extended ASCII to
8 bits in various ways (e.g. IBM-PC character set; HP Roman 8 character set
used on Laserjet II laser printers), but the DEC multinational character set
has a far more logical layout of characters than the others.  ISO 8859-1 is
used on DEC VT320 terminals, and terminal emulations such as MS-Kermit 3.0.
The reason that X.400(1988) refers to ISO 6937 whereas X-Windows makes use of
ISO 8859 may be the association between CCITT and Teletex and the association
between DEC and the development of X-Windows, or it may just be that 
X.400(1988) was developed earlier on.

It is now regarded as wasteful having anything like as many as 64 character
positions reserved for control characters, and proposals have been made to 
extend ISO 8859-1 to cover more languages.  Alternatively, it is possible
that ISO 6937 might make something of a comeback within the context of
structured documents.  Or both ideas might be leapfrogged by two-byte or
multi-byte character sets, with file compression for storage.

I am no expert and some of the above information may be wrong.  If so, I would
be glad of corrections.

   Kevin Donnelly

Standard character sets are a true minefield. The scoop is (I think as
follows):

8859.1  8-bit   X-Windows character set
8859.n  8-bit   A family of character sets, including greek, cyrillic
                etc.
6937.n  8-bit (with *some* two byte characters)
                Overall includes the same set of characters as the
                entire 8859.n family. 6937.1 & 6937.2 are (roughly)
                equivalent to T.61 (1984) excluding Kanji.
T.61 (84) 8-bit (some two byte character), 16-bit Kanji.
                This contains all western european characters and the
                Japanese Kanji set. Note that the Kanji set contains
                Cyrillic and *some* greek characters (but no terminal
                sigma for instance).
T.61 (88) 8-bit (some two byte characters), 16-bit Kanji, 8-bit Greek
                This is an enhancement to the 84 version by the
                addition of an 8-bit greek set. I think that Chinese 
                also got added.
JIS C 6226  16-bit
                This is known as Kanji.
JIS X 0208      This is the current name for JIS C 6226.

T61String (TeletexString) is subtly incompatible between 1984 and 1988
X.400 (but I have a defect report in about that). Note that in any
event, T61String (88) is a SUPERSET of 84 in that greek characters are
allowed. 

Also please note that the curly bracket characters {} *are* in
T61String, its is just that they are rather difficult to find being
located in the kanji portion. 

In answer to your question 'What are the respective merits?':

    As far as I am concerned, each character set for conveying data is
    sufficiently different, with different escape sequences etc, that
    you need to have a comprehensive solution to the character set 
    problem. Once you have this, it doesn't matter much which set you
    use provided you don't start losing characters.


     
--
Philip Gladstone      
Development Lab Europe 
Data General, Cambridge
England.  +44 223-67600

In article <PHILIP.90Nov6103250@beeblebrox.dle.dg.com> philip@beeblebrox.dle.dg.com (Philip Gladstone) writes:
>   JIS C 6226  16-bit
>		   This is known as Kanji.
>   JIS X 0208      This is the current name for JIS C 6226.

JIS X0201-1976	Code for Information Interchange.
JIS X0208-1990  Code of the Japanese Graphic Character Set 
						for Information Interchange.
JIS X0212-1990  Code of the Supplementary Japanese Graphic Character Set
						for Information Interchange.

 "JIS X0201" is 7bit or 8bit encoding roman and "Kana" characters.
 "JIS X0208" and "JIS X0212" is 16bit encoding "Kanji" characters.

------
Hitoaki Sakamoto ( hitoaki@nttlab.ntt.jp )
Nippon Telephone and Telegraph corporation. 
Tokyo Technical and Development Center.

[ n.b. followups redirected for this question ]
philip@beeblebrox.dle.dg.com (Philip Gladstone) writes:

> Standard character sets are a true minefield. The scoop is (I think as
> follows):

[ useful informative table deleted ]

Can anyone tell me if the line drawing characters are standardised in any
ISO standard?  I mean the kinds of characters you use for drawing boxes on
terminals, e.g. like the ones that really annoy you when your VT100 has
received some line noise :-)

Email would be appreciated.  If the info is forthcoming, I will summarise
(to std.internat).

Thank you.
-- 
ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)

In a recent article K.P.Donnelly@edinburgh.ac.uk writes:

>ISO 8859-1 is a development of the DEC multinational character set.

Actually, the way I got this explained for me was that when DEC needed
an 8 bit character set, they took an early draft of ISO 8859/1. Later
drafts of ISO 8859/1 changed, and thus there are now about 10 characters
in the right half that's different between DEC Multinational and ISO
8859/1.

The DEC VT200 series has DEC Multinational as the only 8 bit character
set. The VT300 and VT400 series adds the true ISO 8859/1 character
set.

Anyone who knows the *true* story behind this?

-- 
Robert Claeson                  |Reasonable mailers: rclaeson@erbe.se
ERBE DATA AB                    |      Dumb mailers: rclaeson%erbe.se@sunet.se
                                |  Perverse mailers: rclaeson%erbe.se@encore.com
These opinions reflect my personal views and not those of my employer.