dave@utcsrgv.UUCP (Dave Sherman) (05/01/84)
It was recently suggested in net.news that VT100 escape sequences
be used to highlight text in news articles. That idea was justifiably
shot down because it would screw up many users' terminals.
The question of storing information in the form of ANSI 3.64 commands
and converting them with termcap is of great interest to me and goes
far beyond the issue of news postings.
I have designed and am maintaining a large CAI system which presently
contains modules which teach income tax law. During our experimental phase,
we have used VT-100 terminals (with the Advanced Video features), and I
found many of the VT-100 capabilities extremely useful in highlighting
and presenting information. Accordingly, I wired in these sequences
throughout the system, assuming I could deal with terminal independence
at a later time if the experimental project was successful.
I am now at the stage of preparing a conversion to a new UNIX system
which will support up to 30 users at a time, at least some of whom will
be using non-VT100 terminals. I have to make a fundamental decision as
to the best way of handling highlighting, cursor control and other visual
attributes. This decision will affect courses to be developed in other
areas of the law as well.
Highlighting (underlining, boldface, flashing, etc.) occurs in my
course in several ways:
- in text files which are copied straight to the screen.
- in lessons which are interpreted by a CAI interpreter
("Calypso") at run-time. Text, questions and answers in
these lessons are copied to the screen and often contain
highlighting.
- in complex quizzes which are written as C programs, e.g.,
printf("This looks \033[4mvery\033m underlined.\n");
I need a convenient standard for storing this information. As well
as highlighting, I occasionally use clear-screen commands and cursor
control in a rather minimal way. I also use double-width characters
in a few headers.
It seems to me that the ANSI 3.64 (as used by the VT100) sequences
provide a simple way to do this. As long as I am working on a VT-100,
text files will appear exactly as their final output will (even when
I'm creating or modifying them with an editor). Some conversion
mechanism is a must to let them run on other terminals; my preference
is to leave this conversion until the final output to screen, and only
do the conversion work if(vt100flag==0), so to speak. This can be
done in putc() in such a way as not to affect the rest of the package.
I asked on the net for programs which convert vt-100 sequences
to something termcap can use, and received useful programs from
four different people. I also received scathing attacks from
two people for planning on embedding VT100 sequences in my code.
=====================================================================
=
= I would like people's comments on this basic question: is it so
= terrible to embed VT100 sequences into my code, and if so, what's
= a better way? (Before you reply, read the below.)
=
=====================================================================
MY REASONS (i.e., why I don't think it's such a bad idea):
1. ANSI 3.64 is an internationally recognized standard which
many terminals follow. As long as I have to encode the information
\somehow/, this seems as good a way as any.
2. One person has suggested nroff-like \fB, \fI and so on. Then
what do I do for clear-screen, move-up-one-line, boldface *and*
underlined at the same time, etc.? There is no standard convention
I know of for these things which contains only ASCII-printable
characters. (Does anyone think using "^[" for ESC would be
a good idea? Then the only translation for vt-100's at run-time
would be to convert the two-char "^[" to 033. Has anyone tried this?)
3. As noted above, I don't have to use any kind of filter to read
the text as I'm writing it in my editor (as long as I have a
vt-100 to work on).
4. No computation/interpretation/translation is needed by the machine
for the student who is on a VT-100 terminal.
5. All translation for students on other terminals is isolated in
my revised "putc". The only change needed to all source which
contains VT-100 sequences is "#undef putc" after the "#include <stdio.h>".
Since putc is a standard stdio macro, this can be guaranteed to work on
any UNIX system (my putc will, once it's finished, do whatever the putc
macro in <stdio.h> would have done in the first place).
6. Once I implement a revision to putc() to handle all sequences properly
and generate calls to termcap routines (or whatever), the next person
to maintain/revise the code needn't worry about what terminal the user
faces, or anything like that. The system *will* be terminal-independent.
OK, netters, what do you think? If the net can agree on a standard
for storing this stuff, I'm willing to follow it. I remain to be
convinced that ANSI 3.64 is not the best way.
Dave Sherman
The Law Society of Upper Canada
Toronto
--
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!davebarmar@mit-eddie.UUCP (Barry Margolin) (05/02/84)
Your idea sounds mostly sound, as long as such files stay on your system, and don't go out to the net. One reason I can think for using ASCII graphic characters rather than escape sequences is that they can have more mnemonic value; ANSI control codes are almost all pretty arbitrary. Remember, everyone who writes your text files is going to have to know these sequences. I also think that this form will be easier to edit, since you will see the characters, not the effects (although you indicated that you like seeing the effect as you edit). I'm not sure I like your implementation scheme, though. Rather than modifying putc you should write a filter, and make all the programs do their output through the filter. Of course, you said you wanted to do this without modifying any of the existing programs, so you are sort of stuck with your idea. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
gwyn@brl-vgr.ARPA (Doug Gwyn ) (05/02/84)
By all means follow a real standard, ANSI 3.64 (NOT the same as VT100 but similar), or BEST OF ALL (since you can imbed graphics etc.) NAPLPS.
lmc@denelcor.UUCP (Lyle McElhaney) (05/03/84)
I have been thinking over the same issue for some time (in relation to displaying help information for interactive programs), and came independently to the same conclusion as Mr. Sherman - the ANSI 3.64 standard, while it may not be the best (or maybe it is - I haven't met the alternatives yet), is a *standard*. As for flames about including the sequences in news because xyz terminals can't handle them, then let's build a filter (like ul) which can into readnews (yes, I know its allready a monster; if its too big, then pipe it, like man does). I can't imagine that the size (or speed) difference would much matter. The vt100, in many respects an admirable terminal (at least to those of us stuck with Televideo 910's and adm5a's) has its faults; but the use of the ANSI standard was not one of them. Don't let the fact that the @#$%@!!!$ vt100 uses the standard put you off this idea. On the other hand, if you have a better idea, lets hear it. I like the ^[ alternative idea, as long as <esc> is also handled. (Could you send me copies of the programs you received, Dave? I appreciate it.) -- Lyle McElhaney (hao,brl-bmd,nbires,csu-cs,scgvaxd)!denelcor!lmc
dave@utcsrgv.UUCP (Dave Sherman) (05/03/84)
~| From: barmar@mit-eddie.UUCP (Barry Margolin)
~| One reason I can think for using
~| ASCII graphic characters rather than escape sequences is that they can
~| have more mnemonic value; ANSI control codes are almost all pretty
~| arbitrary. Remember, everyone who writes your text files is going to
~| have to know these sequences.
Most people will only have to know about 3 things - ESC[4m to underline,
ESC[7m to highlight, ESC[m to turn off both. But it's a valid point.
~| I also think that this form will be
~| easier to edit, since you will see the characters, not the effects
~| (although you indicated that you like seeing the effect as you edit).
It's important to me to see the effect as I edit (to the point where,
if I do go with some other format, I'd likely add an option to my
editor to do the conversion on printing). Layout of text on the line
is crucial, in my view, to the information being presented in a
comfortable format for the student. So I need to know exactly how
long a line will be (relative to others in the paragraph, etc.).
My paragraphs are usually very short (3-4 lines), and I don't use
a formatter for this reason.
~|
~| I'm not sure I like your implementation scheme, though. Rather than
~| modifying putc you should write a filter, and make all the programs do
~| their output through the filter. Of course, you said you wanted to do
~| this without modifying any of the existing programs, so you are sort of
~| stuck with your idea.
Well, I don't mind a global modification to existing programs such as
changing printf() calls to myprintf() calls, but I don't want to have
to do a huge amount of conversion work. If by "filter" you mean a
separate process, I definitely don't want that extra overhead; if
you mean an output conversion routine, that's essentially what I'm
doing.
Dave Sherman
--
dave at Toronto (CSnet)
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!davedave@utcsrgv.UUCP (Dave Sherman) (05/04/84)
~| From: apratt@iuvax.UUCP
~| It makes the code look a little worse, but in a C program, the "accepted"
~| modular-programming method would be:
~|
~| #define ON 1
~| #define OFF 0
~|
~| printf("This is ");
~| highlight(ON);
~| underline(ON);
~| printf("very");
~| highlight(OFF);
~| underline(OFF);
~| printf("important\n");
~|
I know. If I only did the highlighting occasionally, that would be OK.
Problem is, I have some quizzes which can only be done in C (they use
structures and logic which are beyond the scope of any file-driven CAI
language I have access to). And in these quizzes I often use underlining
and the like.
~| That way, the functions could take care of sending the apropriate code.
~| Redefining putc will *not* work if you use printf, unless you redefine printf
~| as well. This is because the library version of printf would not use your
~| new and improved putc as a filter/translator/interpreter.
You're right, of course. I forgot to mention in the original article
that I also recompiled _strout with an #undef putc, so that it would
link in my putc function.
~|
~| In text files, however, the ANSI standard is as good as any, but a little
~| verbose; writing an interpreter for it (to include cursor motion, screen
~| clearing, etc.) is not trivial.
That's why I asked on the net - and received several!
~| Also, you should keep in mind that not a lot
~| of terminals have such features as double height/double width lines.
Lots of terminals can't do highlighting either. That's fine - the
terminal will do what it can.
~| Of course, these files would have to be run through a filter which interprets
~| the embedded ANSI codes and sends the appropriate termcap-supported codes.
~| This all is assuming, of course, that you want portability from UNIX to UNIX
~| as well as terminal to terminal.
That's the whole idea. In my CAI system, text files are copied to the
terminal with while((c=getc(infile)!=EOF)putchar(c);, so the same
redefinition of putc that works for printf works for the text files.
Dave Sherman
--
dave at Toronto (CSnet)
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!davelmc@denelcor.UUCP (Lyle McElhaney) (05/13/84)
Pardon my ignorance, but what is a "NAPLPS" (or whatever)? My being only the left half of a wizard is showing again. References? -- Lyle McElhaney (hao,brl-bmd,nbires,csu-cs,scgvaxd)!denelcor!lmc
gurr@west44.UUCP (05/15/84)
<>
Count this as a big YES vote for NAPLPS. I'm currently involved in a project
on NAPLPS, and I've found that the more you use it, the more you realise that
it is the ONLY way to go !
cbosgd
\
qusavx mcvax
/ \ /
decvax ukc!root44!west44!gurr
/ \
vax135 hou3b
Dave Gurr, Westfield College, Univ. of London, England.
PS - for those who didn't know, NAPLPS behaves by default as standard ASCII
until told to do otherwise, so no flames about incompatability please.gwyn@brl-vgr.ARPA (Doug Gwyn ) (05/15/84)
Noth American Presentation Level Picture Standard is upward-compatible with ASCII and supports nearly unlimited alternate character sets, nice graphics, etc. It was discussed in a couple issues of Byte about a year ago.