Dmuse: Color and upper-ASCII codes

The Representation of Color in Dmuse Text Files

Example color codes rendered in Dmuse (.dm, .html).

The design of the Dmuse screen has its origins in the old PC screen. The old PC screen, which was character based, used two bytes to represent each character cell on the screen: one byte for the character, and one for the color attributes. The color attribute byte had two parts: color of the foreground -- the letters, themselves -- and the color of the background -- the field on which the letters appeared. The Dmuse screen also uses this system to represent characters and their color attributes.

The ability to use different color combinations for characters has proven quite useful. The eye is quick to distinguish color, and this makes it easy to flag or highlight certain areas of the screen. But there needs to be a mechanism for coding this information for storage in a file; otherwise, no advantage would be gained in using colors, since this information would simply go away when the window was saved. The most direct way to store window data would be to store each cell: character and attribute. But this has two very large disadvantages. One, it is very wasteful, since most text is written in a "default" combination, e.g., white on black. Second, it makes the file very difficult to read by other programs, since only every other byte contains a valid character. The alternative used by Dmuse is to insert an escape sequence each time the color attribute in a line changes. Since these changes do not happen very often, the extra bytes do not add up to a lot of extra storage. And since the escape sequences come in blocks, they do not interfere with the characters, at least not on a massive scale.

The escape sequences used by Dmuse actually derive from those used by the old (c. 1965) HP 2640 Smart Terminal, on which the first Ibycus systems were based (see the History of Dmuse). Dmuse supports 16 different color combinations, which can be accessed by means of the four function keys, F5, F6, F7, F8, used with the four states: unaltered, Shft, Ctrl, and Ctrl+Shft. By convention, F5 is assigned the default combination, usually white on black. The table on the right shows the 16 escape codes used by Dmuse to flag these combination changes in a file, along with standard color assignments. <esc> here refers to the ASCII byte 27 (hex 0x1b).

In a plain ASCII text editor, a file created by Dmuse might display the following string (using ? to represent the escape byte, 0x1b):

  ?&dAThis combination is black on red.?&d@

which would be displayed in Dmuse as:

   This combination is black on red

with "?&dA" indicating color combination 1 (black letters on a red background), and "?&d@" indicating color combination 0 (return to default colors).

The Use of Non-standard ASCII Codes in Dmuse Files

Byte values range from 0 to 255. For purposes of representing text in Western European alphabets, only a subset of these values is agreed upon by everyone to have a standard meaning. For reasons now lost to most of us, this is called standard ASCII. The subset includes the values 32 to 126, and a few additional values such as 27 (= escape), 13 (= carriage return), 10 (= line-feed), and 9 (= Tab).

When text files are used to represent data that is meant to be read by multiple programs running on a variety of computer platforms, it is absolutely essential that ONLY standard ASCII be used. But it would be a shame to limit screen applications such as Dmuse to the 100 or so standard ASCII characters. Dmuse, for example, can display each of the letters, a,e,i,o,u, A,E,I,O,U, with the acute accent, the grave, the circumflex, and the umlaut or dieresis. Since Dmuse can put only one character in a cell, that's 10 x 4 = 40 additional screen characters. Another example: Dmuse can draw lines and boxes with both single and double lines. Tables and diagrams made with these characters have many useful applications. It takes 40 special characters to do this. So Dmuse does make use of almost all of the 256 byte values, even though only 100 of these values have a standard meaning.

This means that text files generated by Dmuse can have non-standard ASCII bytes in them. These bytes have a clear and sensible meaning to Dmuse, but other programs will interpret them differently with what may look like nonsensible results. There is no problem so long as files generated by Dmuse for general export (MuseData files, for example) contain bytes only from the standard ASCII set. Files intended for use by Dmuse alone are not subject to this limitation. Below is a list of the byte codes used by Dmuse.

Dmuse byte code character mappings

The following screen shot of Dmuse show the contents of this .dm file (HTML conversion) which contains a list of each byte code as it is displayed in Dmuse (when the Dmuse fonts have been installed correctly for X11).

Conversion from Dmuse text files to HTML files

This PERL program can be used to convert files using Dmuse byte code representation and color escape codes into a visually similar HTML file. Not all of the Unicode characters which map into Dmuse characters have fixed-width forms, so there may be slight mis-alignment between characters in the same column. Here are example files and screenshots of the Dmuse and HTML files:

boxtest.dm as displayed in Dmuse.

boxtest.html as displayed in Firefox.

The program can be run from the command-line in a unix-style computer terminal like this:

    ./dmuse2html file.dm > file.html

Dmuse ASCII Artwork

happyboy.dm, happyboy.html	monsterboy.dm, monsterboy.html
monstergirl.dm, monstergirl.html