Date: Fri, 18 Oct 2002 13:09:47 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: ru@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <3DB06A8B.E40B3004@mindspring.com> References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"M. Warner Losh" wrote:
> In message: <20021018095026.GA3386@sunbay.com>
> Ruslan Ermilov <ru@FreeBSD.ORG> writes:
> I know that there sre terminals for which the SGR sequences screw
> things up. I had to deal with a raft of Televideo terminals back in
> the day that we were constantly finding stupid programmers who hard
> coded things to vt100 and we had to keep fixing the stupid programs
> because those programmers couldn't be bothered to use curses. I find
> this to be an analogous case.
Select Graphic Rendition can in fact lock the keyboard of Televideo
terminals; also Wyse, ADM-31, Lear-Siegler, Hazeltine, etc..
> Back in the day, one could have argued that since all terminals
> understood vt100 sequences, we should have stored our man pages in
> vt100 escape sequences? Well, vt100s are almost impossible to find
> and live on only as emulation and most terminals no longer are only
> vt100, but some are close (cons25, for example, dies on some vt100
> sequences). Back in the day, vt100's were claimed to be ANSI
> compliant terminals, which is also a standard. Yet, we didn't
> standardize on them because the nice thing about standards is that
> there are so many to choose from.
ANSI 3.64 is a standard which defines which escape sequences are
permissable, and what form they will take. It does not guarantee
implementation. It's possible to be an ANSI 3.64 compliant terminal,
and not implement many of the sequences. The ISO color escape
sequences, and many of the ANSI 3.64 sequences were in fact first
implemented on the Commodore Amiga console. The SCO added extra
escape sequences for color, on top of the ISO, which were technically
in violation of ANSI 3.64, because they permitted access to the 16
colors of the IBM CGA cards, instead of limiting them to 8, which was
the limit of the ISO standard.
> So this whole argument that it is standard is a little bogus.
We can all agree with this: not all terminals are ANSI 3.64 compliant;
nor should they be.
> : We have also learned one pitfall with this new approach. Our default
> : terminal driver, syscons(4), renders the "underscore" attribute, SGR
> : E[4m (see screen(4)), the same as bold, which is the (code documented)
> : bug, so using this new SGR scheme directly as it comes with new Groff
> : worsens the output on cons25* type terminals. On the other hand,
> : classical nroff(1) filters like ul(1) (and not by accident less(1))
> : render underlining with the "reverse" attribute on terminals that do
> : not support underlining, like cons25.
The controller hardware here is emulating an IBM CGA adapter. The
correct approach is to set the bit that converts the high bit of the
4 background color bits, such that you are left with 8 background
color bits, and another attribute bit. Real VT100's, without AVO
(Advanced Video Option) also do not support multiple attributes
simultaneously, and only support 12 screen lines at 132 columns.
On a side note, the console is 25 lines -- and almost all ANSI 3.64
glass tty's -- terminals -- were only 24 lines.
Assumptions are bad.
> : So we must either fix syscons(4) or to somehow tell grotty(1) to
> : emit old sequences to print bold and italic characters.
Fixing Grotty to use the termcap ("TermCap" -- Terminal Capabilities)
database is the correct approach, in almost all cases.
> That proves my point more. Just because these escape sequences are a
> standard, they are not the only way to go. 'Fixing' syscons will
> actually break legacy programs, which is bad and not really an
> option. Especially because it is to be compatible with a dubious
> standard from the Linux world. Bah humbug. If you want a linux
> comaptible console, write one, don't coopt FreeBSD.
The SCO console is actually one of the best consoles. The only
deficiency that I've seem is in it's treatment of the "AM"
(automargin) attribute, where it wraps a line after character 80,
rather than before what would be character 81. That basically means
that in order to draw in the lower-right-hand corner of the screen,
you have to write the character to 25,79, and insert the character
that *was* at 25,79 at 25,79. This moves the written character
right, and lets you draw the corner without wrapping the screen.
Most curses packages get this wrong. 8-).
> : There are three ways we can go here:
> :
> : 1. Disable SGR support for grotty(1).
> :
> : It can be soft-disabled by setting GROFF_NO_SGR in environment,
> : or hard-disabled system-wide (like it is now in -CURRENT as of
> : this writing) in /usr/share/tmac/troffrc.
>
> I like this option. SGR belongs not in groff, but in ul, et al.
I agree. This is the best option.
> : 2. Stay compatible with the new standard (11 years old ANSI std).
> : This means we fix syscons(4) so that it renders "underscore"
> : distinguishable from "bold", and change the default pager to
> : "more -R". There will still be an option of soft-disabling
> : it for those who want it disabled.
>
> I don't like this option. Fixing syscons is silly and will break
> compatibility with the past. The standard is just 'a' standard, not
> THE standard like you get with posix or ansi-c. There are many other
> legitimate ways of doing things and moving to device dependence
> because someone takes a shining to a standard is not a wise move.
And to do this, you will lose access to 8 of your background colors.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB06A8B.E40B3004>