On 16/10/2026 16:04, Crystal Kolipe wrote:
On Fri, Oct 16, 2026 at 08:28:17AM -0000, Crystal Kolipe wrote:
Historically, the line drawing characters along with various accented
characters were implemented as alternative character sets and switched in and
out of the 128 - 255 range above the standard ASCII characters.
Just to clarify, this was referring to how those characters are represented in
VGA hardware text modes.

 From a software point of view, if you're driving a VT-220 terminal or similar,
(in very simple terms, using any relatively modern and common terminal
emulation that is not UTF-8), then you set the terminal to an alternative
character set and those characters replace regular ASCII characters in the
7-bit printable range 32 - 127.

For example, consider the line drawing character that resembles an inverted T.

On VGA hardware in text mode, this character is typically going to be
available as codepoint 0xC1.  Looking in the _alternative_ spleen font that I
mentioned before, it is indeed at this position.  In the regular spleen font,
which follows ISO-8859-1, this position is a capital A with an acute accent.

On the OpenBSD framebuffer console using the default font, if you print 0xC1
from the shell you should get the accented A:

$ echo '\0301' # Prints an accented A.

Using the alternative spleen font you'd get '?' as a replacement character,
because the system knows that the font is not ISO-8859-1.

Likewise, the codepoint 0x76 is usually an ASCII lower-case 'v'.

$ echo '\0166' # Prints a lower case v.

On the other hand, in DEC special graphics mode the same code is now our box
drawing character that looks like an inverted T.

$ echo '\033(0v' # Should change modes and print the line drawing character.

On an OpenBSD system with the appropriate console font variant loaded, it
does.

Otherwise you get '?', unless you create, load, and enable a special font with
a glyph at codepoint 0x2534, (which is the UCS codepoint that the OpenBSD
console maps for this character), way above the normal 0 - 255 range.

The point here is that the code and logic to use those high codepoints on the
console exists, but it has known bugs and there is no font supplied that
includes those glyphs anyway.

Many thanks for you comprehensive explanation - it is very much appreciated! I remember playing games with fonts and codesets decades ago with Windows. I will focus on getting my xenodm environment up and running - I think that will be the straight forward way to UTF-8 fonts.

Reply via email to