dave@utcsrgv.UUCP (Dave Sherman) (05/02/84)
Another reply to mail I've received:
~| From sask!derek Wed May 2 06:32:13 1984
~|
~| I would tend to the idea of nroff type descriptions in the text
~| file rather than vt100 type escapes. This has been used successfully
~| by the man command on our 4.1 Unix. As far as clearing the screen
~| goes, a control L should suffice to indicate that.
Ah, a standard. Good point - man already does it. But I believe man
only has underlining, and it's stored in the file as _ \b char, and
is converted by ul(1). A start, but not general enough for me.
~| My reasoning is simple. If you try to tie your text file to a vt100,
~| instantly you have a hardware dependence. Case in point, the double
~| height characters are not available on non-vt100's (in general).
Fine, I know that. So if the user's terminal doesn't support it,
he won't see the chars in double height. That goes for anything you
do with termcap.
~| I think that using nroff type commands to indicate the portions of
~| text to highlight, blink, bold, italicize removes any dependence on
~| a specific type of terminal. Notice that you do not have italicizing
~| on a vt100, yet you could indicate it in case the terminal could
~| display it.
True. But I've got to design the courseware with some particular set of
attributes in mind.
~| You would describe an object as, say, highlight. This would come
~| out in bold on one type of terminal, inverse video on another, and
~| underlined on a third, depending on what the terminal is capable of.
OK, I can do that anyway. In fact, that already happens with VT100's that
don't have the advanced video option - underlining and highlighting both
come out as highlighting.
~| I bet that you can come close to defining only three types of highlighting,
~| or a combination thereof, which could be handled in a terminal dependent
~| way.
That's probably true. So what?
~| I recall a quote from some speaker at a Unix conference...roughly...
~|
~| When I talk to others who have written terminal handling
~| packages, I ask them how many terminals they support. I
~| receive replies in the order of 7 or 10. We handle over
~| 500.
Absolutely. And since my package will use termcap, it will support
500 terminals. If the terminal (e.g., IBM 3101 in char mode, which
some of our users will have) doesn't support ANY highlighting, then
they'll get no highlighting. That's how it goes, and whether I store
the data in VT100 format or not won't change it.
~| I like this termcap approach. Of course, if you throw back to me
~| that there is too much computation required for such a package, I
~| have no answer.
My approach still uses termcap. My problem isn't so much one of computation
(although that's relevant) as one of not having a standard to follow, other
than ANSI 3.64, which will do everything I want.
The only point I have to concede in all of the above is that I'll have no
way of indicating something the VT-100 cannot do. But since I'm happy enough
to have the bulk of our students on VT-100 compatible terminals, I don't
see that I'd want to do that anyway. (If the VT-100 can't display it, how
many terminals will be able to?)
Dave Sherman
--
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!davebarmar@mit-eddie.UUCP (Barry Margolin) (05/05/84)
-------------------- The only point I have to concede in all of the above is that I'll have no way of indicating something the VT-100 cannot do. -------------------- Sure, just pull out ANSI X3.64 and use the standard sequence. Hopefully the VT100's will ignore it. Either that, or you could punt special-casing the VT100's, and go through termcap for them, too. This answers someone else's question about how to represent things like italics, since the ANSI standard does define them. But, since you are mostly interested in VT100's, you probably won't bother with this. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar