Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!rutgers!sun-barr!ccut!wnoc-tyo-news!ricohgwy!patty!snoopy!inaba
From: inaba@snoopy.src.ricoh.co.jp (Kiyo Inaba)
Newsgroups: comp.protocols.iso
Subject: Re: CCITT T.51 (ISO2022?) and multiple-byte codes designated to GR/GL?
Message-ID: <3693@snoopy.src.ricoh.co.jp>
Date: 29 Jan 91 15:54:43 GMT
References: <5356@hemuli.tik.vtt.fi>
Reply-To: inaba@snoopy.src.ricoh.co.jp (Kiyo Inaba)
Distribution: comp
Organization: Ricoh Software Reaearch Center, Tokyo
Lines: 31

In article <5356@hemuli.tik.vtt.fi> savela@tel.vtt.fi (Markku Savela) writes:
#
#  Have I understood the standard right? Assuming the following in
#8-bit environment:
#
#   1) I have designated single byte code set (like normal "ASCII")
#      into G0 and invoked it into GL with LS0.
#   2) I have designated multi-byte code set (like JISC 6226 (kanji))
#      into G1 and invoked it into GR with LS1R. 
#
#  With this setup ASCII and Kanji can be mixed without any additional
#escape sequences? Every single code that does not have the 8th bit
#set will be normal ascii, and each consecutive pair of bytes that
#have 8th bit set will be single kanji character.

Unfortunately, I don't have 2022 in hand, refering JIS X0202 (which
is Japanese translation of 2022), this interpretation is correct.

#  What is the correct procedure to handle error cases, like when
#there is only one byte with 8th bit set? Do I blindly take the
#next byte regardless of the 8th bit setting or ignore this single
#byte?

According to the JIS X0202, 'Error recovery for transmitting incorrect
multi byte character set is not defined in this standard'.
But I usually, just get two byte even if the next byte's MSB is set to
0. 

BTW, JISC 6226 became JIS X0208 several years ago.

Kiyo Inaba