terminal resources

The virtual terminal subsystem requires various resources.

keyboard maps

On systems with /usr/share/vt/keymaps/ (such as FreeBSD), the external formats conversion subsystem takes the old-style SCO/FreeBSD kernel virtual terminal keyboard maps from there and generates a range of keyboard map files suitable for console-fb-realizer by passing them through console-convert-kbdmap. The original maps are converted with some modifications supplied by overlay map files:

soft_backspace.kbd

The DEC VT backspace ⌫ key is actually programmable with the DECBKM control sequence. The FreeBSD keyboard maps hardwire the mapping from the backspace ⌫ keycode to the DEL and BS control characters, and if used as they stand would prevent the key from being soft-switchable. This overlay replaces that with a mapping to the bspace action, letting console-terminal-emulator handle the mapping to control characters in concert with the DECBKM setting.

soft_delete.kbd

The XTerm delete ⌦ key is actually programmable with the DECSM/DECRM 1037 control sequences. The FreeBSD keyboard maps hardwire the mapping from the delete ⌦ keycode to the DEL control character, and if used as they stand would prevent the key from being soft-switchable. This overlay replaces that with a mapping to the delete action, letting console-terminal-emulator handle the mapping to control characters in concert with the DECSM/DECRM 1037 setting.

soft_enter.kbd and soft_return.kbd

Likewise, these replace hardwired FreeBSD mappings, from the return ⮠ and enter keys to the CR and LF control characters, with the return and enter actions. The DEC VT enter key is actually programmable with the DECNKM control sequence. The enter action lets console-terminal-emulator handle the mapping to control characters in concert with the DECNKM setting. The return action ensures that the return key can be distinguished from a CR or LF control character in input messages.

jp_to_jp.104.kbd jp_to_jp.109.kbd

The FreeBSD keyboard maps usually apply to all of the Model M/Windows keyboards invariantly. Overlays such as this are per-country per-keycount fixes for various things.

The FreeBSD jp.kbd keyboard map maps the "Grave" key (engraved with Zenkaku/Henkaku/Kanji on the JIS 109-key keyboard) to the ESC control character.

On systems where there is no /usr/share/vt/keymaps/, the external formats conversion subsystem generates a (narrower) range of keyboard map files by overlaying the default null map, U.S. International, built into console-convert-kbdmap with map files that provide just the differences between U.S. International and other layouts rather than entire maps as come with FreeBSD. For example:

The generated keyboard maps are placed in /etc/system-control/convert/kbdmaps/ and can be linked to the service directories of, or simply used directly by, any keyboard device user-space virtual terminal realizer services. Their names follow a regular pattern comprising the ISO country code, the PC Windows keyboard variant (i.e. 104, 105, 106, 107, or 109), and any options such as .capsctrl for maps generated with the swap_capsctrl.kbd overlay that swaps the capitals lock ⇬ and control ⎈ keys.

fonts

Fonts suitable for console-fb-realizer have to be in the "vt" format of FreeBSD. Unifont-style HEX fonts and BDF fonts can be converted to this format with FreeBSD's vtfontcvt tool.

vtfontcvt caveats

In order to work with FreeBSD's vtfontcvt tool:

One can convert other formats to BDF format first, using tools like Jan Engelhardt's fnt2bdf.

The "vt" font format uses 16-bit integers for some fields, such as the internal glyph index. It cannot cope with fonts that cover more than about half of a Unicode plane. Fortunately, console-fb-realizer allows one to build up full Unicode coverage using multiple font files as a sequence of overlays.

Broad range monospace fonts

These cover large parts or even all of the defined Unicode code pointsm, ranging from a few thousand to over a hundred thousand glyphs.

Limited range monospace fonts

These cover only small parts of Unicode, usually little more than a few hundred glyphs that form a subset defined by an 8-bit character set such as an ISO 8859 one or an IBM/Microsoft code page. Generally these are not useful for the more modern, more free, uses of Unicode in terminals, which will often extend to many things not in the old 8-bit character sets, from non-VGA drawing and box characters through extra punctuation and symbols to MouseText and emoji.

input methods

console-input-method is table-driven. The tables that it uses are the same CIN data files as are used by xcin, gcin (GitHub), jscin (GitHub), hime (GitHub), PIME (GitHub), OpenVanilla (GitHub), Chinese Open Desktop (GitHub), OkidoKey.app (GitHub), and MacOS.

Some operating systems supply snapshots of some of these collections as packages, such as Debian's openvanilla-imgeneric-data-all package for example.

The CIN file collections supplied with each software do not exactly overlap, and some are more up-to-date than others, but taken as a whole they range from Esperanto input helpers through Pinyin and Katakana to Hanja. The nosh toolset does not provide yet another collection to augment the mess. Rather, one should pull the CIN files from these collections. There are three exceptions:

hiragana

This data table provides an input method for Hiragana, encoding everything explicitly in the data table itself, including gemination of consonants for sokuon. It incorporates only Nihon-shiki and Kunrei-shiki, and is case-insensitive.

katakana

This data table provides an input method for Katakana and symbols, encoding everything explicitly in the data table itself, including gemination of consonants for sokuon and gemination of vowels for chōonpu. It is a grab-bag mixture of Nihon-shiki, Kunrei-shiki, Hebon-shiki, Hyoojun-shiki, old ANSI/BS standards, and unofficial but common stuff (such as an "l" prefix for little kana). It also incorporates ASCII spellings for punctuation and symbols, such as "hakko" for various sorts of brackets, and is case-insensitive.

romaji-x11

This data table incorporates a subset of the Xlib compose key sequences, not duplicating Xlib sequences that are available in other ways on user-space virtual terminals. (For examples: Many of the combining diacritics are already a standard part of the keyboard map, in the common secondary group, because of ISO 9995-3. Hangeul and Kana are already directly available via other input methods dedicated to them.) It is suitable for use as a "romaji" input method alongside CJKV input methods.