> 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!
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.
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!
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.
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.
23 comments
[ 3.8 ms ] story [ 254 ms ] threadIt took several seconds to load for me, so here's the first paragraph. It's a good first paragraph, though!
I'll definitely give this a try in my Linux TTY. Thanks for sharing!
[1] https://www.nerdfonts.com
https://news.ycombinator.com/item?id=41370020
Do you have a link to the MUD you're working on?
https://en.wikipedia.org/wiki/Sixel
we are full circle, 40 year later.
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!
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.)
http://viznut.fi/ibniz/
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.
CNXT = Constantine's Nine x Twenty
https://github.com/cbytensky/cnxt
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.