craig@dcl-cs.UUCP (Craig Wylie) (02/04/86)
>Is ``italicness' an attribute or a separate font? > >What if I have a private set of attributes that I want characters to have >that don't fit into the codeset currently in use? What is happening about >a design of a regular way of redefining a ``character'' that allows >me simply to change the definition of what a character is, at the head >of my program, that will still allow all the other stuff (ctype, strcmp) >etc. to work, yet allow me to diddle with attributes as I see fit? Get >your thinking caps on, Netland, and see if you can come up with something. >If you don't think that this is important, go read net.dead-sea-scrolls >or something. Big problems though -- grep will have to be able to read and interpret these redefinitions so that it knows what is what inside the program. At one point I was thinking of suggesting that the database of printer characteristics should include how to generate bit images if required. The program could then have a preprocessor command (#CHAR_DEF ?) which gave the information required for the pattern to be used (ie you could specify the bit pattern of a certain character, such as the Swedish symbol of the sun and say :- #CHAR_DEF $ '100010101 .... .... ' etc.) This however 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. 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. Back in the realms of the living dead (have you ever met Stephen Muir from Lancaster ?) it should be possible to define extensions to the preprocessor to allow character definitions at the head of programs and to give programs such as grep some form of context sensitivity. Craig ( I think). -- UUCP: ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster, DARPA: craig%lancs.comp@ucl-cs | Department of Computing, JANET: craig@uk.ac.lancs.comp | Bailrigg, Lancaster, UK. Phone: +44 524 65201 Ext. 4146 | LA1 4YR Project: Cosmos Distributed Operating Systems Research
mikeb@inset.UUCP (Mike Banahan) (02/05/86)
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