You can see unifont in the experimental web version here: https://cad.apps.dgramop.xyz/
But I love the idea that even if your bronze age CAD guy wrote all the solid names in Linear A, no problem!
One of these days I need to dive into the code and figure out a replacement for the modal "can not create constraint" dialogs as those are the worst part of the whole experience.
(Just so you know, RTL doesn't work. حبيبي comes out as ي ب ي ب ح. See https://imgur.com/a/HiXxqZ2 )
GNU Unifont is a bitmap font. It provides a fixed glyph for every code point in the BMP. It also covers additional code points in other planes.
I am guessing this is useful for writing editors that can edit Unicode text without knowing anything about various languages and their conventions. Authors who try to use this font to compose documents in (say) devanagari will have to learn the Unicode characters "in the raw", because I don't see a shaper for devanagari, so they won't get feedback that looks like real text.
If anyone can explain this better, please do!
Edit: looks like it's because BMP supports 1-bit packed pixels and ~~PNG doesn't~~ (Edit to edit: this is wrong). The file sizes are almost identical; the 8x difference in the number of bits is exactly balanced by PNG compression! On the other hand, PBM [2] would've been a properly Unixy format, and trivial to decode, but I guess "the browser knows how to render it" is a pretty good argument for BMP. macOS Preview, BTW, supports all the NetPBM formats, which I did not expect.
[1] eg. https://unifoundry.com/pub/unifont/unifont-17.0.03/unifont-1...
That's nonsense, PNG supports 1-bit pixels just fine, and the resulting file is a lot smaller (when using ImageMagick):
$ file unifont-17.0.03.bmp
unifont-17.0.03.bmp: PC bitmap, Windows 3.x format, 4128 x 4160 x 1, image size 2146560, resolution 4724 x 4724 px/m, 2 important colors, cbSize 2146622, bits offset 62
$ magick unifont-17.0.03.bmp unifont-17.0.03.png
$ file unifont-17.0.03.png
unifont-17.0.03.png: PNG image data, 4128 x 4160, 1-bit grayscale, non-interlaced
$ wc -c unifont-17.0.03.*
2146622 unifont-17.0.03.bmp
878350 unifont-17.0.03.png
3024972 totalI'm realising I know very little about fonts.
"This page contains the latest release of GNU Unifont, with glyphs for every printable code point in the Unicode Basic Multilingual Plane (BMP). The BMP occupies the first 65,536 code points of the Unicode space, denoted as U+0000..U+FFFF."
This is suitable as a last resort font, which should display any character for which no match was found in the other available fonts.
This is normally preferable to a last resort font that just displays the number of a character not available in your preferred fonts.
Just showing a single screenshot of it in its intended use would go a long way.
I clicked on one of the charts and had no idea if the font itself was bitmap, or if it had just been rendered at a tiny size without antialiasing.
Given it’s a last resort font, I think it doesn’t make too much sense for print (unless you’re printing something that could be in any possible language).
It just indicates that the x-height isn't increased the way it often is for a font designed specifically for screens, and that you can have finer details like serifs and thinner strokes. It just means it's intended for high-resolution viewing.
A GitHub readme for some software that sells a subscription (or is meant for “average” users) will have way more explanations and screenshots than something that’s more technical. HN has a “leaner” (worse for mobile) interface than old reddit, while both are way better than new reddit.
And god help you if you want to understand the chain of context on a Linux mailing list (email?) thread. “What, you’re not savvy enough to know the arcane and totally unintuitive stuff we use to format and can’t make sense of it? Too bad, sounds like user error.”
Yeah this turned into a rant, but seriously, little polish goes a long way in usability.
Unifont seems to have about the same glyph coverage as my system default CJK font (unfortunately I don't know what it is).
Another example would be emoji, which would probably now be considered "basic" by most people but have always been in a supplemental plane.
https://github.com/runarberg/shodoku/issues/1
A classic utf-16 bug, where I failed to grab the two remaining bytes of these ideographs.
Tons of these open source projects have the same issue.
I mean that's pretty close no?
- what's the 2 meaning in BMP
- it's designed as a monospaced (or proportional?) bitmap font
- designed in a single 16x16 size only (or also 8x16? it's a bit unclear)
- provided as an OTF/TTF font format, which can be scaled by most font rendering engines to other sizes, but u need antialiasing to make it look smooth (this is mentioned, but under the download section only)
- use as a "last resort" default font, according to wikipedia at least
https://shkspr.mobi/blog/2022/07/the-mostly-complete-unicode...
Are the random sparse Chinese characters floating around the main spiral a natural part of Unicode, or did you put them there for effect? I like how the whole thing looks like a galaxy and those characters like background space debris.
I also like how emoji fall neatly around the outer rim. I had fun finding the Earth emoji.
Unifont is also dual-licensed under GPLv2/SIL OFL.
An important caveat, that while this is potentially a useful fallback font to at least something for unknown glyphs, without any sort of combining/shaping, it's not going to usefully render a whole bunch of languages (i.e. languages like Arabic will be a disaster)
There you can set what fonts should be used by Firefox to display each script/language, including Chinese, Japanese and other CJK variants.
If you do not configure this, then it is indeed unpredictable which fonts will be used by Firefox to render the Web pages, unless it can match exactly a font requested by the page.
I love fonts...