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.
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.
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?
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.
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...
For that particular use case (tbh mostly aesthetics than glyph support), I also found the TTF version of Terminus to be pleasant: https://files.ax86.net/terminus-ttf/ though JetBrains Mono is good enough for me to not venture far away from defaults, albeit maybe Liberation Mono / Cousine was the peak of readability at somewhat small sizes out of any font out there for me.
Wonder if the Potrace approach of Terminus TTF version would work for Unifont. I imagine that Unifont is a pretty good default when doing shipping labels and for such utilitarian use cases.
There are better fonts for this too e.g. Fusion Pixel Font for CJK: https://github.com/TakWolf/fusion-pixel-font
(yes the readme is in chinese, use google translate or something)
i think i saw a good pixel font that supported arabic too once but of course i cant find it now..
Unifont is also dual-licensed under GPLv2/SIL OFL.
Perhaps a GNU style could be something we could help fund?
One can be forgiven for thinking the author means to imply that all commercial software is non-free. It is a further disappointment that anyone has to ask.
Open source was right to get rid of the intentional and unintentionally anti-commercial motifs that only got in the way of paid open source development.
https://www.gnu.org/philosophy/words-to-avoid.en.html#Commer...
We know that the FSF is aware of the problem. The trouble can only be if we expect more success from repeating the same tactics for the next forty years. I would blame no one for expecting the FSF to stay the course and to achieve similar effects. I would also not blame them for choosing a different path for themselves and recommending so to others.
Do they mean to imply this? It can also be read as a clarification about the mentioned software, not all commercial software in general. Could just be poor wording.
> Open source was right to get rid of the intentional and unintentionally anti-commercial motifs that only got in the way of paid open source development.
Open source did succeed in avoiding the problem present in English language, but in doing so, shifted focus away from freedom and onto different confusing motifs. A rare word like 'libre' arguably does an even better job while staying true to the original ideas behind the term 'free'.
I don't feel strong disagreement with the four freedoms, but the biggest reason I've gone fully _OSS and intentionally avoid "free/libre" is because I don't want to endorse the FSF tactics and because I want to encourage others to demand more radical innovations instead of forty more years of the same.
What I find most disappointing when I talk to the FSF is that if I bring up social finance and technically enabled social decisions that can make social finance a lot more effective, it is rather as if I have spoken some alien language. I believe the non-programmer needs a lever to choose the development model used by programs they rely on. To the FSF insiders, such thinking is so orthogonal as to generate no reaction. If I say "a billion users are important," they refute the necessity. They are content to be monastic, conveniently propped up by donations for saying nice things. I find such abandonment inexcusable, and I get fired up talking about it.