!GopherColour2 Last update: 2020/05/29 ==========$$$$$$$$$$==========$$$$$$$$$$==========$$$$$$$$$$==========$$$$$$$$$$ ~GopherColour2 - A Naïvely Immodest Proposal~ At present terminal colours can be enabled by use of the \e colour escape. This escape character must be passed to the supporting client by either verbatim characters on gophermap or by script passed to client side terminal by the gopher menu. The escape characters are then rendered invisible on clients which render terminal colours. I believe this is how it works! However linespace is limited. A gopher map which includes colour escape codes will carry less content information the more colours are formatted per line. The following is a proposition for GopherColour2, a client interpreted content mode specification (not a “gopher extension”) which would allow gophermaps to pass more colours per line of content. The technical detail of this sketch will be limited by the wholeheartedly admitted naïveté of the author in understanding of code. This page will be expanded as and if it approaches practical implementations. ~Colour Escapes~ The ANSI escape and colour combination in shell will enable text to be clothed by pretty colours if variegated hue as well as attributes like bold and reverse: ``` \e[foo;bar;bazm ``` For reasons beyond my ken, the sequence \e is not passed for interpretation as an escape to terminal. Rather, it is ignored. The verbatim ESC code represented by \e in shell can be copypasted from and to local files for the painter to use. But it is either misrendered as a gibberish ligature or it is invisible to the editor. Betwixt \e and m, the formatting code integers change the following text. These changes are inheritable by following lines. This can increase economy. E.g.: ``` \e[41;96m This is light blue text on dark red background. More. More... \e[0m This is unformatted text. ``` ~Interlacing~ How if we leveraged lines by alternating them? Much like an analogue TV set will interlace lines to increase the patterns of movement, we might alternate lines as a client or script formatting interpretation. When so marked as !GopherColour2 or some such, let odd lines be text content and even lines be reserved for formatting the preceding line. The even lines would be hidden from rendering in the client. Spaces could articulate code breaks. One case of Latin could stand for text colouration, with the other background. Each character would denote the corresponding colour in the same or following columns. This would greatly increase fine granularity of coloured art. To wit: ``` This is light blue text, and red text. b r This is light blue text on red background. bR ``` The Latin alphabet might suffice for the basic 16 colours. Numbers or other easily keyboard accessible characters could be used to augment these colours, perhaps by scripted palettes. But specific colours could risk using a tad more linespace by indicating xterm-256colours directly. ``` This is mint green text on strawberry background, oh my goodness so yummy. c47;198 ``` What if you wanted to pack in even more colour? Each character as a differently coloured pixel? With spaces as interrupting codes this would be a problem unless the client is smart enough to note that single character codes cannot colour the same text, but must imply an interrupt. ``` Green pink yellow blue mosh pit. gpybgpybgpybgpybgpybgpybgpybgpyb ``` ~Item Types~ Item types can be leveraged by providing novel substitutions for the standard and customary gopher types. These could be excepted from server gopher menu conversion by script. These item types could indicate background colours or palletes to remap Latin keys. ``` i This is purple text by painter selected palette. C b ``` ~Summary~ The appeal of a system this type across Gopherspace is unknown. I reckon it to be small. But perhaps a community of colouring and text drawing enthusiasts might find it a worthy tool for decorating our gopherholes. By increasing the available colour fine grain, interested gopherites can be enabled to easily and quickly draw much more lively gophermap art. Once I have some deeper feel for using terminal colours by map and script, and the limitations are already rather severe, I shall pursue a practical prototype implementation of this. If you’ve any interest in GopherColour2, or advice for improvement of a specification, please do contact me. Shufei@riseup.net -EOF- .