jms@wzlr.UUCP (Jack Stephens) (06/07/88)
I recently purchased some SCO software and rediscovered a problem that I
had hoped had been solved by now: SCO's distaste for attribute bytes.
I am running SCO professional and (soon) SCO Lyrix on some televideo
terminals and have had to hack together a termcap entry that gets around
the attribute byte problem (sg#1) using low intensity. A less than
satisfactory solution, particularly in the spreadsheet.
Does anyone know the reason for this quirk in SCO software ?
Anyone have a fix? Is there any hope that this might be addressed in
some future release of the products ?
jms
________________________________________________________________________________
Jack Stephens
Digital Technology Resources @@@@___@@@@@@@____@@@@@@@@@__@@@@@@@___
Costa Mesa, California @@@@@___@______@_______@______@______@__
"Where'd the bread go ?" @@@@@@@___@_______@______@______@_______@_
"Beats me. Isn't that neat ?" @@@@@@@___@_______@______@______@_____@___
UUCP: @@@@@___@______@_______@______@______@__
{arnold,berick,bert,hodge,jack}!wzlr!jms @@@@___@@@@@@@________@______@_______@_rosso@sco.COM (Ross Oliver) (06/16/88)
In article <38@wzlr.UUCP> jms@wzlr.UUCP (Jack Stephens) writes: >I recently purchased some SCO software and rediscovered a problem that I >had hoped had been solved by now: SCO's distaste for attribute bytes. > >I am running SCO professional and (soon) SCO Lyrix on some televideo >terminals and have had to hack together a termcap entry that gets around >the attribute byte problem (sg#1) using low intensity. A less than >satisfactory solution, particularly in the spreadsheet. > >Does anyone know the reason for this quirk in SCO software ? >Anyone have a fix? Is there any hope that this might be addressed in >some future release of the products ? This is NOT a software problem, it is an artifact of some terminals. In order to display reverse video, some terminals (Televideo's, most notably) will put an "attribute character" on the screen to mark the start and end of the reverse video. For instance, if you attempt to display the words "SCO Professional" with the characters "Pro" in reverse video, the terminal would display "SCO *Pro*fessional", where the "*" characters represent the attribute characters (usually appearing as a reverse video blank). This prevents reverse and normal characters from being displayed next to each other, and makes cursor addressing much more complex (by adding extra characters on the screen). While the latter can be dealt with, the former is much more difficult, especially in SCO Professional, where a "transparent" reverse video cursor is required. As for addressing the problem in a future release, we have pondered the problem for a long time. The only solutions are compromises. Is it acceptable for you users out there to put up with stray characters in return for being able to use these kinds of terminals? Do any developers in Netland have any clever ways of handling this problem? How widespread are terminals of this type? Ross Oliver SCO Technical Support uunet!sco!rosso
tanner@ki4pv.uucp (Dr. T. Andrews) (06/18/88)
In article <691@nod2sco>, rosso@sco.COM (Ross Oliver) writes:
) [ notes SCO's reluctance to deal with "magic cookie" terminals ]
) This is NOT a software problem, it is an artifact of some terminals.
) ... For instance, if you attempt
) to display the words "SCO Professional" with the characters "Pro"
) in reverse video, the terminal would display "SCO *Pro*fessional",
As one who has written rather a lot in support of terminals plagued
by the magic cookie glitch (sg#1, ug#1), allow me to offer a little
easily forgotten advice.
First of all, choose what you reverse-videate (highlight) carefully.
If you can arrange that it is surrounded by spaces, you win. That's
where you put the "magic cookie". (Yes, I've written lots and lots
of stuff which uses reverse video and the occasional underline. You
forgot ug#1, didn't you? This approach is viable)
There is the occasional case where you will have to tolerate a spare
space where a magic cookie lives. An editor which highlights a block
of text will almost assuredly suffer here. It won't be painful if
the program is aware of the spaces eaten by the terminal, but if the
program doesn't notice that sg#1 is set in the termcap file then
there will be a real problem.
One example of a program which is not very clever in this regard is
"more", which takes sequences of "x\b_" to generate an underlined "x"
using "us" and "ue" strings. It doesn't look at "ug#1", and so
"nroff" output piped through it looks bad on such lines. Try it to
see where the pitfalls of the "magic cookie" lie.
) This prevents reverse and normal characters from being displayed next
) to each other,
Unless the normal character (the blank on a tvi doesn't appear in RV)
happens to be a blank. In many applications (eg: a database package
showing columns of crud, with an entry highlighted) there will be
room for a magic cookie instead of a regular space.
There is of course another problem, widely ignored, which I choose to
call "flash". Take a screen without any magic cookies. Put a reverse
video "magic cookie" up there, in preparation for display of some RV
text. Notice that the screen flashes. Ugly, isn't it? The "good"
thing to do is to first stick the "se" magic cookie where you expect
the end of the string to be. Position the cursor to drop in the "so"
magic cookie (if you have room for it, position one char BEFORE the
text is to be displayed, to allow room for that magic cookie). This
way, the display works nicely.
Seeing that I've been addressing this problem with nice displays from
back in our CP/M days, I have little sympathy for folks who don't make
at least a good effort. Saying "sorry, but you really should have
bought a different terminal" doesn't wash. (That tvi950 I use is a
survivor from our CP/M days. Still works.)
--
rutgers!bpa!cdin-1!cdis-1!ki4pv!tanner (better than it looks!)
or... {allegra codas killer decvax!ucf-cs}!ki4pv!tanner