See also: The Ultimate Oldschool PC Font Pack from VileR at <https://int10h.org/oldschool-pc-fonts/fontlist/>.
I came across this website when I was looking for IBM PC OEM fonts for a little HTML + Canvas-based invaders-like game I was developing a few years ago. It is impressive how much effort VileR has poured into recovering each OEM font and their countless variants, from a wide range of ROMs. The site not only archives them all with incredible attention to detail, but also offers live previews, aspect ratio correction and other thoughtful features that make exploring it a joy. I've spent numerous hours there comparing different OEM fonts and hunting down the best ones to use in my own work!
https://en.wikipedia.org/wiki/Sixel
we are full circle, 40 year later.
It took several seconds to load for me, so here's the first paragraph. It's a good first paragraph, though!
Each UTF8 character (1 to 3 bytes) corresponds to 1 byte of input data. The average increase in data size is about 70%, but you gain binary independence in any medium that understands utf8 (email, the terminal, unit tests, etc.)
CNXT = Constantine's Nine x Twenty
I ended up writing a rust parser for the .hex file format for use in my kernel[1]. So I can now display the fantasy kernel on bare-metal :)
[1]: https://github.com/LevitatingBusinessMan/runix/blob/limine/s...
I'd like to figure out how that wrong belief could have formed.
When was "years ago"? Unscii 1 is from 2014. That's more than 15 years after the heyday of Mona Font and its predecessors.
I postulate viznut was just not aware of the huge scene due to his parochialism.
A great deficiency of Unifont mentioned several times in the other thread was its lack of combining-character support, and the absence of alternative glyphs for the code points in scripts like Arabic (well, and EngsvanyƔli) whose form is affected by joiner or non-joiner context. Does anyone know if Unscii does better at this?
From opening it in Fontforge, Unscii seems to have pretty broad coverage, including things like Bengali, Ethiopic, and even runic, plus pretty full CJK(V) coverage. It seems to have some of the CSUR https://www.evertype.com/standards/csur/ assignments, such as the Tengwar of Feanor in the range U+E000 to U+E07F, but has conflicting assignments for some other ranges, like the Cirth range U+E080 to U+E0FF (present in Unifont but arguably duplicative with the runic block), which is assigned to Teletext/Videotex block mosaics. I note that my system has different conflicting assignments for this range, with Tux at U+E000 followed by a bunch of dingbats, while the Cirth range is a bunch of math symbols.
Given that astral-plane support is virtually universal in Unicode implementations these days (thanks largely to emoji) it might be better for future such efforts to use SPUA and SPUB to reduce the frequency of such codepoint clashes. SPUA and SPUB are each the size of the entire BMP: https://en.wikipedia.org/wiki/Private_Use_Areas
For day-to-day use of semigraphic characters, I ran into the problem two hours ago in https://news.ycombinator.com/item?id=46277275 that the "BOX DRAWING" vertical lines don't connect, consequently failing to draw proper boxes. I had the same problem in Dercuano, where I fixed it by reducing the line-height for <pre> elements. The reason seems to be that Firefox defaults line-height to "normal", which is apparently equivalent to "1.41em", which doesn't sound very normal to me (isn't an "em" defined as the normal line height?), and, although the line-drawing characters in my font (which seems to be Noto Sans Mono) are taller than 1em, they still don't reliably join up if the line-height is taller than 1.21em.
Chromium does the same thing, except its abnormal definition of "normal" is evidently more like 1.35em.
It's probably too late to make a change to the standard HN stylesheet so major as
pre { line-height: 1.2em }
since it would change the rendering of the previous decades of comments. It would be a significant improvement for things like what I was doing there, and I don't think it would be worse for normal code samples. However, given the lengths to which the HN codebase goes to limit formatting (replacing characters like U+2009 THIN SPACE with regular spaces, stripping out not just emojis but most non-alphanumeric Unicode such as U+263A WHITE SMILING FACE, etc.) maybe discouraging the use of these semigraphics is intentional?If not, though, perhaps the fact that the line-height is already different between Chromium and Firefox represents a certain amount of possible flexibility...
Obviously the line-height would be a much more serious problem for the kinds of diagonal semigraphic characters that viznut is largely focusing on here; those would strictly require a line-height of exactly 1em, which I think would substantially impair the readability of code samples.
I'll definitely give this a try in my Linux TTY. Thanks for sharing!
Today, when we're sending it to terminal emulators running on teraflops supercomputers over gigabit-per-second links, it's only a waste of CPU and software complexity instead of user time and precious bandwidth. But it's still a waste.
Why couldn't we have FTP and Gopher support in web browsers instead?
Out of curiosity I checked with lsof, apparently other fonts are used as fallback:
/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
/usr/share/fonts/truetype/droid/DroidSansFallbackFull.ttf
/usr/local/share/fonts/MS/segmdl2.ttf
/usr/local/share/fonts/MS/seguisym.ttf
/usr/local/share/fonts/nerd/Iosevka/IosevkaNerdFont-Regular.ttf
/usr/local/share/fonts/nerd/JetBrainsMono/JetBrainsMonoNerdFontMono-Regular.ttf
At least the result is perfect!
Do you have a link to the MUD you're working on?
I won't have to wait seconds (!!!) to read it
Then why do I have it now? Time travel?
I'm envious of the level of nerdiness and genius at display, and hope some of it rubbed off on me by watching that demo.
Nice work! But if you want something like this in production, base64 only increases the size by 33%.
I mean not really, they are ancient and horribly insecure protocols without enough users to justify improving them.
I come to the comments to find out what these "clickbait title" articles (meaningless words with no context) really are before clicking.
Secondly, the site appears to be "hug of death"'d at the moment. I presume it was still accessible but struggling when OP posted.
Also, you may not have noticed this, but you're commenting on a thread that's largely about PETSCII and Videotex.
Fortunately, AFAIK, there isn't any significant body of existing Sixel art we need to preserve access to.
Also:
The browser support would have need continous security fixes and rewrites unfortunately, the protocol specs and the code was written in the day and age of a much less adversarial internet. It's much safer to handle those sort of protocols with a HTTPS proxy on the front these days. There's dedicated gopher and ftp clients still out there, IMHO browsers are too big and bloated as they are they need more stuff taken out of them, not more added without taking anything away, particularly stuff thats old and insecure and not used much anymore.
And yes, I'm also here for the retro factor :-) my pet project is Z80/6502 emulation in UnrealEngine with VT100 and VGA support and running BBS's in space. So I'm all over stuff about old ANSI, PETSCII and anything even tangentially 8x8 character set related:
The entire original point of the WWW project was, approximately, providing a better user interface for accessing files on FTP servers. So to me it seems perverse that the current stewards of the Web have broken that.
So is Webdings: https://www.dafontfree.io/webdings-font/
Webdings even got integrated into Unicode 7.0, so all the Noto fonts support it: https://en.wikipedia.org/wiki/Webdings
And recode(1) has full support for ISO-8859-*. As does iconv and the Python3 encodings.codecs module. I'm pretty sure browsers can render pages in them, too. Firefox keeps rendering UTF-8 pages as if they were ISO-8859-1 encoded when I screw up at setting the charset parameter on their content-type.
With Nerdfonts, these will be obsolete in further Unicode releases.
GNU Unifont and the unicode table might be backported to the Amiga. With NerdFonts, you need to do twice the jobs.

Unscii is a set of bitmapped Unicode fonts based on classic system fonts. Unscii attempts to support character cell art well while also being suitable for terminal and programming use.
The two main variants are unscii-8 (8Ć8 pixels per glyph) and unscii-16 (8Ć16). There are also several alternative styles for unscii-8, as well as an 8x16 "full" variant that incorporates missing Unicode glyphs from Fixedsys Excelsior and GNU Unifont. "unscii-16-full" falls under GPL because of how Unifont is licensed; the other variants are in the Public Domain.
Unscii was created by Viznut.
In 2020-03-10, the new Unicode version 13.0 added 214 graphics characters for "legacy computing" (including, among all, the missing PETSCII characters, and a majority of missing Teletext/Videotex characters). Most of these were already included in Unscii 1.x, but now I have been able to give them proper Unicode mappings as well. This is the main reason for the Unscii 2.0 release.
Additionally, Unscii 2.0 fixes errors in some characters, legibility in some others and adds a bunch of new ones.
A test picture representing what is currently available in Unicode (feel free to copy-paste it to your editor to see what it looks like in other fonts):
āāā ā±š½āš¾ā² š®²š®³ š®øš®š®µš®¶š®š®š®š®š®¼šÆšÆšÆ āµ ā ā¬
ā¶āā“āŗāāø ā āāā ā¹ āøā£ā¹ āø āāāāā šÆ²šÆ·šÆ¶ ā³ ā“ ā½ āā¬ā®
ā·āā¬āāāÆāāā¤āāāā š®· š¼āšæ āø āāāāā šÆ¹šÆµšÆ± 𯰠āāāāā
āāā āā
āā³ā·ā»ā¹ ā² āā¼āā¾ā ā©ā¬ā¬
āāā¼ā¤āāæā„āāŖā”āāā ā¹ā± ā³ ā²āø āāāāā šÆ“šÆ³šÆø āš®š®
š®āš®š®āā¹ ā½ āāāš®½ā¶āŗāøāæ ā® ā¬ā§ā«āØā¬
āµāā“āāā·āāā§āāā⦠āāāāā š¬š¬š¬°š¬Ŗš¬ š®š® āā āā”āÆā” āšµ āæ ā¼ ā ā®āā® ā¬ā¬āŖ
ā»āā°āāā³ā āāāā
ā®āāāā š¬„š¬¦š¬š¬²š¬µš¬¹š¬±š¬·š¬š¬š¬ š®š® š®āāā āÆāāÆā”āš“ ā¾ ā® ā ⬠ā
āā āāØā£āā« āŗā½āāāā¾ā
ā
āā š¬š¬”š¬š¬»š¬š¬š¬š¬ŗš¬¢š¬š¬§ š®āā ā āÆā ā š³ āæāŗ
ā¹āāøāāā»ā āāµāāāā¶āāāā š¬š¬¤š¬«š¬“š¬ š¬š¬š¬øš¬š¬š¬ šš¬¼ āā āš®£š®¢ 𮦠š² ā¹āø šÆ š®āāš® šÆ āāā¶āāµ
āā„ā āā¦āā¢āāŖ āā±ā²ā§ š¬£š¬Æš¬š¬¬š¬š¬š¬š¬š¬
š¬®š¬ š¢š š®ā š®¤š®Ŗš®«š®„š®§ š± šÆ š®āš¬āāī”±āā®ā«š®»ā§ āāāā²ā¼ā±āāā®
āāā«ā¢š®š®š®ā ā¬ā£ ā¹ā ā”ā¹āŗā© š¬³š¬š¬©š¬š¬š¬š¬š¬Øš¬š¬š¬¶ šš¬æ š®ā š®©š®¬š®š®Ø š° ā¢š«ā£ š® ā ā¢ ī”°ā®šāŖ āāā·ā¼ā“āāāā
āāØāš® š®āā©ā šÆ šÆ
šÆ š®£š®¢ šÆ šÆ š„š š®āš®® š®”š® āøš®šŖāšØš®š®æš¬ā°āš®ÆāāÆā¬āÆāØ ā³āā°ā°āāÆ
āāš®š®š®āāāāš®š®ā¤ā¤ā„ā„ā¦ā¦ā©ā©ā§ā§š®š®š®š®āØāØš®š®š®š® šš āāš»šŗš¹šøš·š¶ā ā„š©ā¤ š ā®āÆāŖ ā±ā° āā¬
āāāš®āāāāāš®š®ā¤ā¤ā„ā„ā¦ā¦ā©ā©ā§ā§š®š®š®š®āØāØš®š®š®š® š¦š š®° šš¬¼š šš¬æ šš āāÆā© āÆā® ā«ā»ā”ā ā¼āŖā¬Ā·
š®āš® ā²ā± šš¬¼šš¬½šš¬¾ā¢ā£šššš¬¼šššššš¬½šššš¬¾šššš¬½š
š ā¦āāÆā¬¤āā ⬫⬦⬨ā¢āāāā¦ā¬§ā¬„⬩⬪
āš®ā š¢šš£šš¤šā„ā¤š¢šššš£š§ššššš¤šššš£šš ššš” āāā
š¢š š„š š¦š ā¢
Here are some conversions of legacy character set art into Unscii.
Amiga ansi: Divine Stylers by Hellbeard, as rendered with unscii-16. Source

PC ansi: Ansi Love by Rad Man, as rendered with unscii-16. Source

Commodore 64 petscii pictures as rendered with unscii-8, using the 256-color xterm palette: I Has Floppy by Redcrab; The First Ball by Dr.TerrorZ; Gary by Mermaid.

The source code package includes a generic bitmap-to-unscii converter. Here's an example of a conversion to unscii-8 using the 256-color xterm palette, without dithering:

HEX and PCF are the only actual bitmapped formats here. HEX is the same simple hexdump format as used by the Unifont project. TTF, OTF and WOFF are vectorized.
NOTE: Due to format limitations, the PCF versions lack all the characters above U+FFFF! However, all the new graphics characters are provided in the good old PUA range as well. A mapping is in the file uns2uni.tr.
![]() | unscii-16: hex pcf ttf otf woff |
![]() | |
![]() | unscii-8-tall: hex pcf ttf otf woff |
![]() | unscii-8-thin: hex pcf ttf otf woff |
![]() | unscii-8-alt: hex pcf ttf otf woff |
![]() | unscii-8-mcr: hex pcf ttf otf woff |
![]() | unscii-8-fantasy: hex pcf ttf otf woff |
Years ago, I noticed that Unicode had a bunch of pseudographic characters that could be used to enrichen Ansi art. However, no one seemed to use them. Even MUDs that used the 256-color Xterm palette and had no issues with Unicode still preferred to stick to the blocks available in the MS-DOS codepage 437.
After looking into existing Unicode fonts, the reason became obvious: the implementation of non-CP437 graphics characters was shaky at best. Unicode Consortium doesn't even care how pseudographics are implemented. It was a kind of chicken-and-egg problem: No commonly accepted Unicode graphics font, no Unicode art scene; no art scene, no font support. The idea of an art-compatible Unicode font was born.
For Unscii, I studied a bunch of classic system fonts and how their characters had been used in Ascii and "extended-Ascii" art.
8Ć8 system fonts can be divided in two major categories according to their line thickness: 1-pixel and 2-pixel. 2-pixel-wide lines are used in more prominent classic systems, so I chose it. Also, 2-pixel 8Ć8 system fonts are surprisingly similar to one another which made it easier to choose neutral shapes.
The basic look of the 8Ć8 variant of Unscii is based on the following systems:
The 8Ć16 variant of Unscii has been mostly derived from the 8Ć8 variant by using a set of transformation principles. When in doubt, the following fonts have been looked at for additional reference:
In general, neutral shapes are preferred, unless art, legibility or readability require otherwise: The characters /\XY are connective because of their connetive use in ascii art, and the serifs in iIl are longer than in most classic systems.
Whenever a 8Ć16 shape has not been defined, Unscii falls back to height-doubled 8Ć8.
I also studied game fonts and thin-line system fonts. This resulted in the variants unscii-8-thin, unscii-8-mcr and unscii-8-fantasy.
When studying legacy character sets, I found literally hundreds of characters without proper Unicode codepoints. These are mapped in the PUA range as follows:
Since Unicode 13.0, many of these are also available in Unicode, but the PUA mappings are retained for compatibility.