SCO and the attribute byte

[Ross Oliver]

In article <38 at wzlr.UUCP> jms at 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