Relay-Version: version B 2.10.2 9/5/84; site titcca.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site takuya.uucp
Path: titcca!kddlab!takuya!kato
From: kato@takuya.uucp (Akira Kato)
Newsgroups: fj.sources,fj.kanji
Subject: Re: why can't we read kanji in " less"  ?
Message-ID: < 874@takuya.uucp> 
Date: 12 Apr 86 13:01:58 GMT
Date-Received: 14 Apr 86 01:40:20 GMT
References: 
Reply-To: kato@cs.titech.junet (Akira Kato)
Distribution: fj
Organization: Tokyo Institute of Tech., Dept. of Computer Science, Japan
Lines: 41
Xref: takuya fj.sources:24 fj.kanji:30

In article  nojima@nttlab.ntt.junet writes:

>   I installed and it works fine at our site.  However, "less" won't
> accept Kanji.  Has anybody tried it ?  I think very simple hacking
> will improve the situation, but I knew almost nothing about C.

    Here is a little hack result to less program. We can read KANJI
by the change, however, it is NOT complete. The screen may be con-
terminate (please redraw the screen).


	public int
control_char(c)
	int c;
{
/*	original one
	return (c <  ' ' || c == '\177');
*/
	/* modified by kato@cs.titech.junet */
	return (c != '\033' & &  c != '\016' & &  c != '\017'
		& &  (c < ' ' || c == '\177'));
}

    Complete version should :
	o Recognize which two neighbor bytes is KANJI.
	o Treat the terminal capability of KANJI-on/ASCII-on. 
(none of koudai users hack it to be complete)

    In order to make the software which can handle KANJI, it
is necessary to issue the escape sequences for each terminal.
Some special termcap entry for KANJI capabilities would be one
of the solution. I remember that there was a news article of
proposal for KANJI termcap entry standarization in last summer.
I am sorry that I don't know who posted the article and the 
result of it. Does anyone know the result? 

					Akira Kato
				Tokyo Institute of Technology
				JUNET: kato@cs.titech.junet