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!
I've been using the Px437 Verite 9x6 font from this pack as my main terminal font for years now, and couldn't be happier with it. VileR's font pack is great for both retro use cases, like displaying ANSI art, and for modern ones.
Hopefully the people after us will spend some time enjoying the things we have left to them; if they dedicate all their time to creating things that will outlast them, all our efforts will have been wasted.
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.
It seems incompatible with the idea that it's "Gone. Forever." Thinking again doesn't change that for me. The only thing that's gone is the exclusivity to a single proprietary-software vendor.
A simple case. Amigans can still use thanks to standards, Usenet and IRC, they can connect to Bitlbee.org to several choices. With Discord and such it's more difficult, but for Jabber there's no isue at all. Ditto with AmiSSL and Jabber, Gemini clients. They can reuse Amiga 4000 machines (or FPGA based ones) and browse small sites, Gopher, connect to Biltbee and make tons of services usable again.
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.
I was personally looking for a bitmap font that resembled old fantasy games for use in a kernel. I was able to write a compile time constant parser for the .hex file format used here.
Sixel support unfortunately came to terminals in 01988, as that page explains. I saw it myself in 01992. Sending uncompressed color raster data over a 9600-baud serial link again every time you wanted to look at it was a terrible idea, made worse by the stupid Sixel encoding inflating it by an additional 33%.
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?
> I don't think they needed improving in order to continue accessing the existing sites that still used them
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:
I think it had been many years since the FTP code had needed a security fix, and at least a year or two for the Gopher code.
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.
Site isn't loading but I have a neat side project that works with any monospace font that includes Unicode glyphs which converts raw binary to unicode and back while passing through 7-bit ASCII characters, replacing control characters with related symbol representations, and sticking with actually-monospace glyphs (a surprising number of glyphs break the width rule across various "monospace" fonts), while ALSO being denser and more directly legible than hex encoding: https://github.com/pmarreck/printable-binary
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.)
The favicon is either exactly or a really close copy of The Grate Book of Moo's logo. Hopefully that's not too obscure for Hacker News, but you never know.
> 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.
It took several seconds to load for me, so here's the first paragraph. It's a good first paragraph, though!
I like the look of this a lot! Especially how condensed it is, similar to my favorite monospace TrueType font Iosevka Term. The ANSI color rendering looks phenomenal.
I'll definitely give this a try in my Linux TTY. Thanks for sharing!
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.
Slightly off-topic but related.
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!
I've been using the Px437 Verite 9x6 font from this pack as my main terminal font for years now, and couldn't be happier with it. VileR's font pack is great for both retro use cases, like displaying ANSI art, and for modern ones.
I just tested and my local nerdfont[1] does not support a bunch of those graphical glyphs, perhaps that is something that could be added.
[1] https://www.nerdfonts.com
I got incredibly accurate output on my terminal emulator using a nerd font (st with Iosevka Nerd Font, tmux, links2 browser).
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!
https://github.com/ryanoasis/nerd-fonts/issues/1959
Thanks for filing that. I was slightly confused by the appearance of the red race car.
Nerdfont sucks as it's non-standard.
Why is that important?
It deviates from the Unicode standard. It's doomed to fail.
Everything in life is temporary. If it lasts while I use it, it's as good to me as if it lasts forever.
ASCII and Unicode will outlast us. Not the case with Nerd fonts.
Hopefully the people after us will spend some time enjoying the things we have left to them; if they dedicate all their time to creating things that will outlast them, all our efforts will have been wasted.
If it lasts 10 years, it's good enough for me.
there's enough support for it across various things that it's not going anywhere
They said the same about ISO-8859-* encodings, Webdings/Windings fonts under Windows. Gone. Forever.
Wingdings is available in OTF format to put on your web site as a webfont: https://www.onlinewebfonts.com/fonts/wingdings_OTF
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.
>Webdings even got integrated into Unicode 7.0,
That's the point. Think again.
It seems incompatible with the idea that it's "Gone. Forever." Thinking again doesn't change that for me. The only thing that's gone is the exclusivity to a single proprietary-software vendor.
A simple case. Amigans can still use thanks to standards, Usenet and IRC, they can connect to Bitlbee.org to several choices. With Discord and such it's more difficult, but for Jabber there's no isue at all. Ditto with AmiSSL and Jabber, Gemini clients. They can reuse Amiga 4000 machines (or FPGA based ones) and browse small sites, Gopher, connect to Biltbee and make tons of services usable again.
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.
Viznut also made a audio / visual live coding tool IBNIZ, used it for a performance once it's fire
http://viznut.fi/ibniz/
Viznut has made a shitload of amazing things: https://www.pouet.net/user.php?who=2547
I love this so much.
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.
Download the program and play with it for a while. You can prepare to learn by watching, but you will only really learn by doing and teaching.
This is perfect. I'm currently creating a MUD and these are exactly the kind of fonts I want. Thanks for sharing!
I was personally looking for a bitmap font that resembled old fantasy games for use in a kernel. I was able to write a compile time constant parser for the .hex file format used here.
Do you have a link to the MUD you're working on?
With sixel support finally comming to terminals
https://en.wikipedia.org/wiki/Sixel
we are full circle, 40 year later.
Sixel support unfortunately came to terminals in 01988, as that page explains. I saw it myself in 01992. Sending uncompressed color raster data over a 9600-baud serial link again every time you wanted to look at it was a terrible idea, made worse by the stupid Sixel encoding inflating it by an additional 33%.
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?
> Sixel support unfortunately came to terminals in 01988
Then why do I have it now? Time travel?
> Why couldn't we have FTP and Gopher support in web browsers instead?
I mean not really, they are ancient and horribly insecure protocols without enough users to justify improving them.
I don't think they needed improving in order to continue accessing the existing sites that still used them.
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.
> I don't think they needed improving in order to continue accessing the existing sites that still used them
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:
https://i.imgur.com/rIY1he8.png
https://i.imgur.com/DlftREp.png
I think it had been many years since the FTP code had needed a security fix, and at least a year or two for the Gopher code.
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.
Site isn't loading but I have a neat side project that works with any monospace font that includes Unicode glyphs which converts raw binary to unicode and back while passing through 7-bit ASCII characters, replacing control characters with related symbol representations, and sticking with actually-monospace glyphs (a surprising number of glyphs break the width rule across various "monospace" fonts), while ALSO being denser and more directly legible than hex encoding: https://github.com/pmarreck/printable-binary
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.)
> ... you gain binary independence in any medium that understands utf8
Nice work! But if you want something like this in production, base64 only increases the size by 33%.
I found this when searching for a bitmap font.
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...
The favicon is either exactly or a really close copy of The Grate Book of Moo's logo. Hopefully that's not too obscure for Hacker News, but you never know.
Constantine Bytensky's "cnxt" font is sort of in this vein also. If you're interested in unscii, you might also like cnxt.
CNXT = Constantine's Nine x Twenty
https://github.com/cbytensky/cnxt
This is conveniently timed, I was planning on doing a cool retro-y WindowMaker rice over christmas break. Better than Liberation Sans
> 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.
It took several seconds to load for me, so here's the first paragraph. It's a good first paragraph, though!
Are you on dialup? :D
The 'net on dialup (good dialup at least) isn't that bad with JavaScript and images disabled. Better yet on a text based browser like Lynx or Offpunk
Or with gopher with gopher://magical.fish and gopher://hngopher.com
Also:
https://farside.link
https://lite.cnn.com
https://text.npr.org
Thank God! You saved me.
I won't have to wait seconds (!!!) to read it
I'm thankful that GP spoke up.
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.
Unscii is great! A few years ago I made a simple mobile-friendly Unscii art editor: http://unicode-drawing-club.netlify.app/
These are lovely. I miss some of that ASCII art quirkiness, so I added it to my blogging platform (as ASCII art banners) https://lmno.lol
Reminds me of UDG graphics on the sinclair spectrum. I like the example of the image in the article very cool art.
I like the look of this a lot! Especially how condensed it is, similar to my favorite monospace TrueType font Iosevka Term. The ANSI color rendering looks phenomenal.
I'll definitely give this a try in my Linux TTY. Thanks for sharing!
could also suit Termux (Android linux terminal) well. Will try it asap
How to install it?
looks very useful. And skillful! Very careful typographic reasoning when creating the glyphs from the classic originals.
> Years ago […] No commonly accepted Unicode graphics font, no Unicode art scene
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.
Seems related to the discussion the other day of Unifont, which is an 8×16/16×16 Unicode bitmap font: https://news.ycombinator.com/item?id=46248859
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
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.
This would probably work great with the monospace web framework.
https://news.ycombinator.com/item?id=41370020
Can't wait until somebody makes a game hit in Steam using unscii as every UI in the game.
That ' is tilted kinda ruins it for me as a programming font, but otherwise looks really nice.
Oh hey, this is the font used by the Minecraft mod OpenComputers.