Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!genrad!panda!talcott!harvard!seismo!mcvax!ukc!stc!inset!mikeb
From: mikeb@inset.UUCP (Mike Banahan)
Newsgroups: net.internat
Subject: Re: fonts, colours, greping, context sensitivity and the future
Message-ID: <834@inset.UUCP>
Date: Wed, 5-Feb-86 05:22:33 EST
Article-I.D.: inset.834
Posted: Wed Feb  5 05:22:33 1986
Date-Received: Fri, 7-Feb-86 22:03:44 EST
References: <343@ur-tut.UUCP> <832@inset.UUCP> <970@dcl-cs.UUCP>
Reply-To: mikeb@inset.UUCP (Mike Banahan)
Distribution: net
Organization: The Instruction Set Ltd., London, UK.
Lines: 65

In article <970@dcl-cs.UUCP> craig@comp.lancs.ac.uk (Craig Wylie) writes:
>... is not going to make greping for such characters particularly
>easy. I still feel that the problem must be with the Terminals and
>editors that we are using. If we can generate any particular combination
>of colour and font while we are typing (and change in the middle of
>a sentence) then pattern matching will be that much easier, but very few
>of us can. We don't all have full colour graphics workstations available to
>us all the time. 
>
>If we want to be able to say :-
>
>	grep -font=ROMAN -pica=12 -colour=RED "Syntax error on line....
>
>then grep and programs like it are going to have to be given the ability to
>know the context of all the text they are examining. This in turn means some
>sort of standard, not just for programs but for Word and Text procressors,
>editors, printers, linkers, compilers, pretty printers .....
>hoo boy (to coin a phrase). Perhaps this really is a sign 
>that our current operating systems are on the way out, we need
>something better.

Got it in one! Exactly. It is going to be necessary to support a variety
of attributed characters for different purposes, and to have translators
which can convert from one codeset into another, perhaps stripping out
information.

For example, if the middle-level description of one of these super-chars
(which I chose to call a `codon' in my paper on this idea) is like this

struct codon{
	unsigned font: 4;
	unsigned point: 6;
	char encoding;
};

Then it can be `transformed' in a number of ways. A simple one would be for
the transforming program to throw away the font and point stuff altogether
and just spit out 8 bit chars.
Then grep would work just fine. Another approach would be to convert it into
troff-like input, so that given the above form of a Roman 12pt letter A,
the transformer would read it and output something like

	\f(RO\s12A
which even the current grep could be told to look for. Of course, if a new
grep were written which understood those codons directly, then the transformer
would be unnecessary.

>
>Even then different operating systems will have different 'standards' that
>will have to be translated (if possible  --  pass the straight jacket please)
>when documents are passed. I think I'm going to take up water colours.
>
>

It will be a fact of life that we have to be prepared to transform data
streams on input to and output from our systems. Anyone unlucky enough
to work  in a mixed UNIX and EBCDIC environment knows that already; we
have this problem all the time because our telex machine is hooked up to
UNIX. Surprise surprise, the telex character set and ASCII don't match.

The truth may be painful folks, but ingoring it has never made it go away
yet!
-- 
Mike Banahan, Technical Director, The Instruction Set Ltd.
mcvax!ukc!inset!mikeb