* The repository code is 8 GIF files, not actually a font per se, nor even the source code for one (despite the name of the ZIP archive). The only actual font here is a binary file in an asset attached to a release tag, and it's only provided in one font format.
* Not all systems will work with this, as the idea of font fallback is not universal. The built-in terminal emulators in the FreeBSD kernel and in Linux only load one font at any given time. (I've written a user-space terminal emulator with the goal of providing a user-space workalike for those terminal emulators, which does have font fallback mechanisms, but kernel built-in terminal emulators forego the ability to have multiple fonts and a lot of other things for obvious reasons.)
* 200 by 200 is excessive for some uses. Not everything is a GUI program talking to a display server with a font manager on the side. The font tools for Linux's built-in terminal emulator limit glyph bitmaps to 32 by 32, for example. (https://unix.stackexchange.com/a/574583/5132)
* Life gets even more fun when one has to deal with the ("East Asian") widths of undefined code points. (-:
I would guess/hope the GIFs are only for display in the README.md and the actual glyphs are vector-based like a regular font (so the 200x200px problem shouldn't be one)
We can only take them at their word, when the downloadable file hyperlink is entitled "Source Code (zip)" and it hyperlinks to a ZIP file of these GIFs, that these are supposed to be the source glyphs.
Nothing this detailed will fit into 32 by 32 , vector-based or no. There simply aren't enough pixels for the words and numbers on the borders. Also notice that the significanty smaller "last resort glyphs" at http://unicode.org/charts/lastresort.html are not the same as what is purportedly in this font.
No, I'm fairly sure that was not their intent. It says at the bottom of the readme:
NOTE: The sources and build scripts may be added after Unicode Version 14.0.0 has been released (2021), and as time and resources permit.
So this repo doesn't have the source currently, despite what it may say earlier in the readme. I'm assuming the TTF file in the release is the actual font, and the "Source code" zip is just an automatic archive of what's currently in the repository.
This is great! It's informative enough to end users when a glyph is missing, and stands out for developer eyes when a web font subset doesn't include particular characters.
I am a native Sinhalese (that ක is from it), and there aren't enough web fonts that cover those glyphs. If the system fonts don't cover those glyphs (Windows, Linux, and MacOS versions do, but many feature phones, treadmill browsers, etc don't). I'd love to see this font (which appears to be only sub 500kb) instead of those ugly boxes that don't convey any information whatsoever.
Technogym Run 700, the one I see at my gym. They have a multi language setup including chinese, Japanese, and Korean, and that's as far as glyphes seem to go.
A question I've had for a while: Is there some reason the entire set of Unicode reference glyphs can't be used as a last-resort font? Sure, this would render various things wrong (e.g. Arabic, although Arabic is common enough that you're likely to have a font for it installed so this wouldn't come up), but why couldn't this be done as a better-than-nothing fallback?
From https://www.unicode.org/faq/font_keyboard.html:
The fonts used in the PDF code charts on our website are licensed by their owners for chart usage only, and they may not be re-used without permission of the font suppliers.
License is one factor, but more importantly due to the limitation of OpenType. Last-resort fonts work because a single glyph maps to lots of characters (typically with a special support [1]); otherwise you wouldn't be able to have more than 140 thousand glyphs.
I think the issue comes with new Unicode releases with older oses not getting updates. In the browser world I’m not sure how bad it is since browsers get auto updates frequently, but e.g. iPhone 5 users are never going to see the newest emojis.
I like that the font they decided to use for the text embedded in this font is Chicago. It's a good choice, since it was designed to be legible at a low resolution. (I'm pretty sure it's Chicago and not just a Chicago-esque font because of the distinctive shape of &.)
It certainly looks like it. Which raises the question — and I know font copyrights are complicated — can they really license this as SIL OFL when it contains designs from Chicago?
Note the different goals of unifont and Last Resort Font. Last Resort Font is intended to provide descriptive glyphs for all codepoints, even for those that are non-characters (which would presumably be out of scope for unifont), and to distinguish between private-use and unassigned codepoints, which would all simply be missing glyphs in something like unifont.
The idea is that if you are working on some software that produces or works with Unicode, you can see at a glance what type of character you have (if no other font provided a glyph), or if the codepoint is private-use, non-character, or not assigned yet.
I love unifont! Not only will you pretty much never see tofu boxes with it but (IMO) their emoji graphics are better than most. I think it might violate the standard but I really hate having emojis rendered with a different color than the surrounding text. And personally I prefer the bitmap style for graphics even if text itself is better as vectors (which is the way the font is intended to be used anyway.)
It says it only covers the BMP, which aligns with my expectations that common font formats can't contain enough characters to define all printable characters in Unicode.
Edit: Ah, I see, they use more fonts for higher points - but haven't covered everything yet? Aren't there already font families that cover everything? I was under the impression that Source Sans Pro does.
To my taste Google's Noto project is the better choice for most purposes, since they're vector, and cover more than just the BMP. I also happen to think they look better.
Neither of our posts have much to do with the article, though, which is a collection of marks to display what script family a missing character belongs to, when a font for that script is missing. This has the advantage of being much smaller, while still at least telling the user what sort of font to look for to decode the content.
Unifont covers all of the BMP (and more), so it's impossible for any other font to cover more of it. But Noto has nicer glyphs for the parts it does cover, so it's better to use Unifont as the fallback for characters not in Noto instead of the other way around.
It appears Noto isn't complete (nor is Unifont), which surprised me when I checked it. I can't recall ever seeing text which wasn't rendered by it in the wild.
Unifont itself covers only the BMP. There are a couple of supplements which go past that, which I wasn't aware of.
What’s the deal with the Git repo not including any source code? Is this a common way to use GitHub these days, as a download server for closed source projects?
It seems like it should be fine based on their acceptable use policy[0]. There is a clause about excessive bandwidth use, but nothing about what constitutes "source code."
On another note, I do not know why you were down voted. You asked a valid question.
>The obvious way to use system fonts in CSS is to… just list all of the ones you can imagine by name:
font-family: "San Francisco", "Roboto", "Segoe UI";
Why? Isn't the obvious way to just use "sans-serif" and let the system fallback to whatever the system font is? What if some Windows users install "Roboto" on their OS, in this case?
(I have this question with any of these"system font stacks" for a long time.)
sans-serif stands for Arial or Helvetica by default. The system UI font is distinct from that. You can specify system-ui, but not all browsers support that on all platforms [0]. To solve the Roboto problem, most system font stacks put it after SF and Segoe UI, which are less likely (but still possible) to be installed on systems where they aren’t the default font.
> sans-serif stands for Arial or Helvetica by default
Not really, I think it just means "sans serif". On iOS and Android, it will fallback to the default system font fine.
On Windows (and maybe MacOS, but I never use it), it will likely fallback to Arial because that's most of browsers default to [1], which is one layer before the system one.
However, users can always change this default font in browser setting [1] to whatever they want.
And I think this is a superior approach (just use "sans serif") than typical "system font stack" because
1) Users not necessarily want the same font for system UI and web page. I knew I don't because Segoe UI is too bulky. Anyway, If they do, they can always just set so in their browsers.
2) it's not hard-coded. What if an Android user changed their system front from Roboto to something else? Now whole premise "consistent look and feel" breaks down by having the hard-coded "Roboto" in your website's CSS.
3) The users still get the consistent look across all the websites that use such rule. And even better, they can control what exactly (back to point 1).
I don't get it. Why not use actual font with actual glyphs as last resort font? Wouldn't it be better to be able to render something readable rather than placeholders, as last resort?
Ligatures that might not be supported by any known fonts, otherwise unprintable characters, etc etc etc.
This is for those situations where you’ve got a stream of Unicode coming in and there’s some sort of weird behavior you’re trying to figure out due to some glyph that’s not otherwise representable, ie, is that end-of-line a carriage-return, a new-line, is there a space afterwards, and did that program just include a null-character as record delimiter before the new-line??? That sort of thing.
* The repository code is 8 GIF files, not actually a font per se, nor even the source code for one (despite the name of the ZIP archive). The only actual font here is a binary file in an asset attached to a release tag, and it's only provided in one font format.
* Not all systems will work with this, as the idea of font fallback is not universal. The built-in terminal emulators in the FreeBSD kernel and in Linux only load one font at any given time. (I've written a user-space terminal emulator with the goal of providing a user-space workalike for those terminal emulators, which does have font fallback mechanisms, but kernel built-in terminal emulators forego the ability to have multiple fonts and a lot of other things for obvious reasons.)
* 200 by 200 is excessive for some uses. Not everything is a GUI program talking to a display server with a font manager on the side. The font tools for Linux's built-in terminal emulator limit glyph bitmaps to 32 by 32, for example. (https://unix.stackexchange.com/a/574583/5132)
* Life gets even more fun when one has to deal with the ("East Asian") widths of undefined code points. (-: