[DGD]Switch colors On and Off
Gregory D Lewis
glewis at maths.adelaide.edu.au
Fri Nov 24 23:19:26 CET 2000
Posted in the hope it might be useful to someone :).
LPColor 1.0r1
Fantome @ IdeaExchange, TMI-2
1 December 1994
0.0 Introduction
----------------
This is a proposed new standard for the handling of colors in general
throughout LPmuds. The suggestion for color-codes comes directly from
Northern Lights AberMUD/Dirt 3 (aber.ludd.luth.se 6715). Much of this
information is directly available as "help colorcodes" there.
This standard is intended to replace Pinkfish's long color names,
although it can be used in conjunction with Pinkfish's color names at a
performance cost.
1.0 Color Code Conversion
-------------------------
1.1 Color codes should be processed into terminal-appropriate
signals immediately prior to display to the player. For all
other purposes, the mud-internal color-codes should be used. To
minimize processing time, color code should support both the
mud-internal and the player escape sequences. Limiting color
processing to display-time will accomplish several things.
1.1.1 Direct ANSI or other terminal-specific ("unknown")
characters can safely be stripped from all communications
channels ("say", "shout", and actual channels including
"Intermud") without affecting intended colors.
1.1.2 Terminal independence is gained. This way, when a new
terminal type becomes commonplace, processing can be
added that supports the terminal, at the option of the
mudlib maintainers.
1.1.3 Color processing should be faster because it is only
processed when necessary.
1.2 All terminal-specific or client-specific color codes should be
stripped from communications channels. No mudlib should reverse
the process of this standard.
2.0 Compliance
--------------
2.1 Minimum compliance with this standard is support for 'unknown'
terminal types.
2.1.1 'unknown' terminals should strip the color codes specified
in this standard without any further processing.
2.2 Recommended compliance is VT100, ANSI, and 'unknown' terminal
types.
2.2.1 'VT100' and 'ANSI' terminal types should be handled by
converting the color codes into the appropriate
ESC[(n;..)m codes as specified by VT100 and ANSI accepted
standards. This information is reproduced as appendix A.
2.3 Recommended addition of 'client' terminal type for AMCP
compliant servers to be set automatically on a proper login
sequence from an AMCP compliant client.
2.3.1 Recommended extension of AMCP 2.1 to support LPColor
extensions as well as older AMCP color codes based on
Pinkfish's standard.
2.3.2 'client' terminal type should not interpret the color
codes in any manner. 'client' terminals receive the
raw color codes.
2.3.3 AMCP clients are required to convert the LPColor codes
appropriately.
2.4 Recommended extension of AMCP 2.1 to support terminal inquiries
(on ANSI and compatible it is usually similar to ESC[?) for
automatic terminal detection at initialization screen to be
overridden by player-set variables.
3.0 Color Encoding
------------------
% Activity in world spock
% Activity in world mist
3.1 Color codes be mnemonic in nature and as short as meaningfully
possible. Color codes should be easily inserted into any
description block and have guaranteed processing.
3.1.1 If a color code were encountered in this file, the
remainder of the text should be in a different color
until the end of the document or a new color code or a
color reset code is encountered.
3.1.2 Color codes should not require #defines or special
functions for insertion into any code. It is recommended
that #defines be made to support the mud-internal format.
3.2 Color codes will be a maximum of five bytes in length. The
bytes will be (signal code)(scope ID)[(color ID)(color ID)].
3.2.1 Signal codes are 0x40 (@) or 0xFF. 0xFF will be used for
mud-internal communications as it is a non-typable, non-
printable character.
3.2.2 Scope identifiers will be from the set of printable
symbols (non-alphanumeric), limited at this time to the
set consisting of [-+=*#!@]. Other symbols are reserved
for future definition. Symbols may not be overloaded.
3.2.2.1 '-' sets the background color (1 argument).
3.2.2.2 '+' sets the foreground color (1 argument).
3.2.2.3 '=' sets both foreground and background colors
(2 arguments)
3.2.2.4 '*' resets colors to standard (0 arguments).
3.2.2.5 '#' sets both foreground and background colors to
one of ten mud-based configurations (1 argument).
3.2.2.6 '!' indicates a non-standard extension (3
arguments).
3.2.2.7 '@' produces 0x40 (@).
3.2.3 Optional color identifiers will be one byte in length and
consist of alphanumeric [a-zA-z0-9] characters. Not all
scope identifiers will support the full set of color
identifiers.
4.0 Scope Implementation
-------------------------
4.1 Scopes '-', '+', and '=' use the set [a-zA-Z] to identify up to
52 different colors. Except as noted below, lower-case letters
are used to identify "dark" colors and upper-case letters are
used to identify "bright" or "bold" colors. Section 5.0 defines
the specific color implementations.
4.1.1 Scope '-' takes exactly one (1) color identifier. For
ANSI implementations, "bright" colors are to be
interpreted as "dark" colors.
4.1.2 Scope '+' takes exactly one (1) color identifier. For
ANSI implementations, "bright" colors are to be
interpreted as "bold" plus the "dark" color.
4.1.3 Scope '=' takes exactly two (2) color identifiers in the
order (foreground)(background). For ANSI implementations,
refer to 4.1.1 and 4.1.2 for limitations.
4.2 Scope '*' takes exactly zero arguments.
4.2.1 Minimum implementation to support colors is restoring
colors to system- normal. For ANSI implementations, this
is ESC[0m (as detailed in appendix A).
4.2.2 Recommended implementation is to query a player
environment variable 'BASECOLOR' and restore the colors
to the colors indicated in that variable, or issue a
color reset if that variable is not found.
4.3 Scope '#' takes exactly one argument from the set [0-9]. The
number indicates a player-specific or mud-specific standard
color.
4.3.1 Minimum implementation is ignoring scope '#'.
implementation is to query player environment
variables 'COLOR[0-9]' (or other, named variables, such
as 'SHOUT_COLOR', etc.) for the player's preference in
viewing that class of output. If variables are not
present within the player, revert to 'GLOBAL_COLOR[0-9]'
or named variable.
4.3.2.1 Recommended scope '#' to Message Class setup:
'#' Message Class
--- -------------
0 Say
1 Tell
2 Shout
...
7 More
8 Error Message
9 Global Message
4.3.2.2 Identifiers 3-6 are left undefined for
MUD-specific implementation. Identifiers 8-9
are recommended to be restrict from common
use in channels.
4.4 Scope '!' signals a non-standard extension. All extensions must
have exactly three bytes from the printable, non-white space set
of characters following the '!' scope.
4.4.1 It is recommended, but not required that the first
character in the extension be a scope identifier similar
to the scope characters defined here.
4.4.2 Extensions are strongly discouraged. This standard can
be amended without difficulty.
4.4.3 Standard compliance with scope '!' is to ignore the three
bytes following.
4.5 Scope '@' produces the escape character in a printable
fashion.
4.6 Unknown scope is when a scope identifier is encountered that is
not defined in this standard. When unknown scope is encountered,
if the escape character is 0x40 (@), both it and the scope character
will be displayed. If the escape character is 0xFF, only the scope
character will be displayed.
4.6.1 For example, '@*' resets the colors. '@1', however,
prints '@1'.
5.0 Predefined Colors
----------------------
5.1 There are eight predefined colors in ANSI/VT100, plus 'bold',
'underline', 'blink', and 'reverse'. (There is also a blank
defined in VT100 that is not supported in ANSI.) These twenty
predefined combinations provide the initially defined colors
5.1.1 Colors are initially represented with the following
codes. The 'bright' or 'bold' forms of the colors are
capitalized forms of the darker color. Darker colors may
be applied to both background and foreground.
Code Represents Bright
Aurora at Astaria gwizzes: No but give me 5 minute and I can ;)
---- ---------- ------
k blacK K
b Blue B
c Cyan C
g Green G
m Magenta M
r Red R
y Yellow Y
w White W
Bright black is dark grey. Dull white is light grey.
5.1.2 Bold is represented by 'D' (bolD) and may be used only
in the foreground.
5.1.3 Underline is represented by 'U' (Underline) and may be
used only in the foreground.
5.1.4 Blink is represented by 'N' (bliNk) and may be used only
in the foreground.
5.1.5 Reverse is represented by 'V' (reVerse) and may be used
either in foreground or background, but not scope '='.
The equivalent in scope '=' is usually kw (black on
white).
6.0 Suggested Implementation
-----------------------------
6.1 Continuous text and non-continuous text should be handled
differently.
6.1.1 Short message classes (say, shout, wiz/cre, etc.) should
be considered non-continuous text. Generally line- or
sentence-based.
6.1.1.1 Each line of non-continuous text should start
and terminate with a color reset (LPESC*) at the
end of each line (\n).
6.1.2 Room descriptions, files viewed through 'more', etc.,
should be considered continuous text. Generally
sentence-, paragraph-, or file-based.
6.1.2.1 All continuous text should start and terminate
with a color reset (LPESC*).
6.1.3 All message classes may be treated as short message
classes at the option of the mudlib designers.
6.2 Prompts (including input_to and ed) should begin and end with
LPESC* to ensure no maleffect on player entry from stray color
codes.
Appendix A: ANSI/VT Escape Sequences
------------------------------------
A.1 ANSI escape sequences are a subset of DEC VT100 escape
sequences. The following escape sequences should be
considered valid on all ANSI and VT-series compatible
terminals.
A.1.1 In the following list, the abbreviation AESC represents
ASCII escape character ESC, 0x1B (decimal 27) followed by
the ASCII printable character 0x5B (decimal 91, '[').
LPESC, when used, is ASCII nonprintable 0xFF or ASCII
printable 0x40 (@). In BNF, this is:
ESC ::= <0x1B>
AESC ::= ESC[
LPESC ::= <0xFF>
A.1.2 In all cases, the presence of braces ('{' and '}')
indicates that it is a variable to the ANSI escape
sequence. Case is significant in specifying a terminator
(such as 'm' or 'H').
A.2 Cursor Motion Commands
A.2.1 AESC{r};{c}H
AESC{r};{c}f
A.2.1.1 Move the cursor to the specified position
({r},{c}) in row major order. The cursor
position is optional and assumed to be (0,0), or
the upper left corner of the screen. Both of
these ANSI commands works the same way. This
command is unsupported by the LPColor standard
definition. Recommended implementation is none.
Possible implementation is:
'LPESC!x{xa}{xb}LPESC!y{ya}{yb}'
where if LPESC!x is found, LPESC!y must follow
and values xa, xb, ya, yb are decimal.
A.2.2 AESC{n}A
AESC{n}B
AESC{n}C
AESC{n}D
A.2.2.1 These ANSI commands move the cursor up (A), down
(B), forward (C), or backward (D). If the
cursor is already at the top (A), bottom (B),
end- of-line (C) or top-of-line (D), the command
will be ignored. If a number is not provided,
the value defaults to one (1). These commands
are unsupported by the LPColor standard
definition. Recommended implementation is
'LPESC!{n}{d}' where {n} converts directly to
{n} in these commands and {d} is in the set of
[UDLR] corresponding to the set [ABDC].
A.2.3 AESCs
AESCu
A.2.3.1 These ANSI commands save and restore the current
cursor position. AESCs saves the position,
while AESCu restores the position. AESCs
overwrite each other and are not nested. These
commands are unsupported by the LPColor standard
definition. Recommended implementations are
'LPESC!SAV' and 'LPESC!RES'.
A.2.4 AESC2J
A.2.4.1 This ANSI command clears the screen and moves
the cursor to the home position (0,0). This
command is unsupported by the LPColor standard
definition. Recommended implementation is
'LPESC!CLS'.
A.2.5 AESCK
A.2.5.1 This ANSI command clears all characters from the
cursor position to the end of the line,
including the character under the cursor
position. This command is unsupported by the
LPColor standard definition. Recommended
implementation is 'LPESC!DEL'.
A.3 Character Color and Appearance Command
AESC{s;...}
A.3.1 This command will change the colors and attributes of
text displayed on the screen. There are two groups of
values: Text Attributes and Colors.
A.3.2 Text Attributes
{s} Meaning
--- -------
A.3.2.1 0 All Attributes Off
A.3.2.2 1 Bold (Bright) On
A.3.2.3 4 Underscore on (monochrome only, appears
as dark blue on color monitors).
A.3.2.4 5 Blink On
A.3.2.5 7 Reverse Video On
A.3.2.6 8 Concealed On
A.3.3 Colors
Color FG BG
----- -- --
A.3.3.1 Black 30 40
A.3.3.2 Red 31 41
A.3.3.3 Green 32 42
A.3.3.4 Yellow 33 43
A.3.3.5 Blue 34 44
A.3.3.6 Magenta 35 45
A.3.3.7 Cyan 36 46
A.3.3.8 White 37 47
A.3.3.9 Colors 30-37 and 40-47 meet the ISO 6249
standard.
A.3.4 No additional implementation is needed to support
Colors or Text Attributes.
A.4 Conversion Specifications for LPColor to ANSI/VT Escape
Sequences
A.4.1 Conversion should be as efficient as possible.
Terminals have to do less work to change the color with
one long ANSI color string, but the server has to do
more work to convert several LPColor sequences into one
ANSI string. Clients should convert several LPColor
sequences into one ANSI string. Servers should convert
on a one-to-one basis.
A.4.2 Bright colors (capitalized color codes) should be
processed as 'AESC1;{fg}m'.
A.4.3 Scope '=' should be processed as 'AESC{fg};{bg}m'. If
{fg} is Bright, scope '=' should be processed as
'AESC1;{fg};{bg}m'.
A.4.4 Scope '*' (color reset, LPESC*) should begin with
AESC0m to turn off all undesired attributes before
setting new attributes.
A.4.5 Attribute 'Concealed' should be avoided.
A.4.6 Standard channel colors (LPESC#{n}) should begin with
AESC0m to avoid bad color and attribute mixes.
--
Greg Lewis Applied Maths Department
Email : glewis at maths.adelaide.edu.au University of Adelaide
--
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list