Interesting how easy it is to make an operation like this run on multiple cores in Rust. Inserting a single call into a chain of functions can be enough.
These look absolutely delightful! A quick question: I'm working on retro consoles, and so I need fonts where each glyph is a multiple of 8px wide for easy display on tile-based backgrounds. Are the sizes (in pixels) of your font packs listed anywhere?
each glyph is a multiple of 8px wide
These look to be variable-width fonts. I believe the heights are multiples of 16, but the width will vary by character.
They are variable-width yes but there is also a monospace variation, those will be constant width.
It appears that the "tile sheet" export puts the fonts on a fixed width grid, so that can be used for a fixed width font. They look left-justified in the grid though, and fixed width fonts usually have the glyphs centered in their grid. That could be fixed with some scripting.
The example tile sheet in the article appears to be 8 pixels wide by my count. Count the width in pixels on the "m" and if it's 7 the font will likely work for you.
The main issue is you can't have them literally touching or it'll be really hard to read. Maybe it would work, but most of these "pixel art" fonts really benefit from some faking enabled by running on what's actually a high resolution display.
That's why I said the "m" should only be 7 bits wide for an 8 bit wide font.
Check out The Ultimate Oldschool PC Font Pack (https://int10h.org/oldschool-pc-fonts/). Each font description includes glyph dimensions and aspect ratios
16. Or an integer multiple of that like 32 or 64. It's in the Step 5: Exporting section
Edit: that's the height, the width is not fixed/I think it varies with the exact font and the kerning. It's probably too big for you anyways.
Impressive work!
In the "mixed-case kerning pairs" quality testing image, I notice that the letter "j" sometimes reaches under the previous letter, like in "Fdj". Sometimes it creates a lot of space, like in "Fjo". Is there a stylistic reason for this? The Fjo spacing is the only thing that stood out to me.
Kudos
Nice catch. That's a culprit of the `auto_kerning_min` property that you'll see on a lot of the fonts. this tells the auto kerner not to exceed that.
I added this parameter because I fouund that for a lot of fonts, squeezing letters together over a certain distance would just look bad, so I would set -1 or -2 as a cap.
It looks like that's just one that snuck past my notice. The word "Fjord" would look strange because of this. This is a good example of how even with the quality testing, things can get through, because I still have to visually glance over hundreds of kerning tests.
One thing that might be a nice adjustment is to have an algorithm that detects the "area" between two letters, so basically how many pixels can volumetrically fit between them, and flag ones that go over a certain threshold. I could then color those tuples as red in the sample text, basically the system marking them as "potential problems" that required an author's look.
Thanks for taking the time to answer. I don't understand why in the dj combination, j is able to reach under d for what looks like a kerning of about -4, when the auto_kerning_min property is set to -1 or -2, keeping Fj apart.
Maybe they just manually kerned "j" with the lowercase letters? The "j" line on the lowercase sample would jump out pretty strongly in a way the capitals-with-j don't on the mixed-case one.
Why not just feed that information back into the algorithm itself?
I definitely could, I would have to do a bit of tests to see what kinds of volumes deserved special treatment.
Usually the way I do things is I start by doing work manually. If I find that there's a common pattern in something I'm doing that could be automated, then I am able to transcribe it into the algorithm because I just follow the same steps I've been using in my head.
This wasn't a thing that actually came up a huge amount, as these glaring pairs aren't tremendously common. But they're just common enough that if I sat down and examined them, I could probably say something like "hey if 1.5 vertical lines worth of pixels are between two letters, kern this extra" or something like that.
What I picked up from a lifelong typographer is that kerning should be about the area enclosed by the two letters. The aim is to make that consistent. I think that might help in this kind of case.
Impressive indeed. Making a complete font set can easily take as long as a year. The tasks include to go from 'A' to 'Z', upper and lower case, plus all the glyphs (brackets, ampersand, exclamation marks etc). Optionally the variations (bold, italic etc) without which a font is of limited use. The thing that separates the men from the boys is the kerning (spacing between the characters) which can absorb as much obsessive compulsion as you can throw at it. From TFA:
My new fonts were going to support 176 characters, meaning I might have to enter as many as 176² = 37,976 kerning pairs... yeah not going to happen. So this time, since I was (spoiler alert) writing my own tool to generate the fonts, I decided to semi-automate this process to take care of a huge majority of the kerning, and do manual entry when algorithm didn't suffice.
Making a complete font set can easily take as long as a year.
Making a font family can easily be a lifelong project.It makes me very happy to see people talking about how much work can go into a typeface. Like, these pixel fonts are very quick to make, but fully contoured vector fonts can be tweaked to perfection infinitely, there's always more languages and more diacritics and more weights and styles you could do.
Truly a rabbit hole, but when it's done well it's very worthwhile. I have a lot of respect for font makers.
Has anyone tried training a DL model to handwrite things? That seems like a fascinating rabbit hole as well. In addition to all the context sensitive letter differences, you could even label training pieces with the mood of the writer and the flexiness of the nib/quill. If I type an angry emoji after a sentence it gets scribbled harder when drawn.
Making a font family can easily be a lifelong project.
Donald Knuth made https://www.1001fonts.com/cmu-font.html __and__ designed and implemented an entire typesetting system __and__ did a bunch of other not-so-small things that makes designing a font family seem like a side project.
Tex was the side project. Knuth went on a years long yak shave to write book-making software instead of writing the book because he was unhappy with the fonts in the printer proof.
Making a complete font set can easily take as long as a year. The tasks include to go from 'A' to 'Z', upper and lower case, plus all the glyphs (brackets, ampersand, exclamation marks etc).
That's when you're limiting the font to purely English usage. If you want to support any other language you have to add more characters, even for languages that also use the latin alphabet (e.g., French, Spanish, Italian, Portuguese, etc). Then you may want to support Greek and Cyrillic, Japanese, Chinese, …
For example, “Noto fonts cover over 77,000 characters, which is around half of the 149,186 characters defined in Unicode 15.0” according to the font's Wikipedia entry.
Nice work
I would like microns on the vowles, as we type a lot of Māori words....
Is a micron the name of the straight line over the 'a' in Māori? A single pixel line over a bunch of a's is tremendously simple to do in pixel fonts, I could probably add that to all the fonts in a day... hmmmm
The straight bars over vowels are called “macrons” in English. https://en.m.wikipedia.org/wiki/Macron_(diacritic)
In Māori, there are ā, ē, ī, ō and ū.
Ahh yes there it is, thanks for clarifying. These are quite simple and would be easy to support.
Apologies if this nerd-snipes you, but supporting the caron might also be fairly simple given you could just vertically flip the circumflex https://en.wikipedia.org/wiki/Caron
Together with the macron, pinyin (the main romanization for Chinese) would be mostly supported. https://en.wikipedia.org/wiki/Pinyin
Same here for diacritics in Vietnamese. There are very few font sets which natively support our vast range of diacritics.
This is neat! And cool to hear this made a financial difference for them. Gah, I remember the name Chevy Ray from indie games, but I cannot put my finger on what this person made… would have been like 2010 to 2012?
In the same vein as VVVVVV or nidhogg or canabalt as I recall
I also found Ikenfell to be really delightful!
It was flashpunk! Beacon was rad too — blast from the past, I miss indie games
The game you are probably talking about is Beacon.
Ikenfell
Flashpunk?
Btw anyone who's into fonts should check out https://tomorrow.type.today/ they're a typography studio that does fantastic original and experimental fonts. One of our team is super into typography and has been building a collection of their work at https://play.soot.com/tomorrowtypetoday
just as a note: the company is registered in Russia
Iirc they're originally Russian, but have fled the country out of strong disagreement of the war
Also in Georgia.
Cool fonts, and an interesting post. I kind of want the top-right fake game in https://chevyray.dev/blog/creating-175-fonts/old_previews.pn... to be real. It has a "Wonder Boy in Monster World on the GBA" vibe I think is nice.
I have noticed that the license doesn't allow you to use the TTFs in open-source software, which is something to keep in mind.
Licensed Content may not be distributed to third parties as standalone files or in a way that unreasonably permits the recipient to extract the Licensed Content for use separately and apart from the Work for Distribution.
Licensee may not distribute the Licensed Content in any library or reusable template, including but not limited to game templates, website templates intended to allow reproduction by third parties on electronic or printed products.
Licensee may not distribute Licensed Content in a manner meant to enable third parties to create derivative works incorporating Licensed Content.
To me, a non-lawyer, the last clause reads like it unambiguously forbids it.
https://github.com/ChevyRay/pixel_font_megapack_license/blob...
If you like platformers, give Celeste a try. The scene in that mockup is a reference to an opening scene from that game.
Oh, I didn't realize. Thanks for pointing it out.
I played the original Celeste for PICO-8 (now called Celeste Classic). I plan on playing the full release eventually. The screenshot actually reminded me a little of an earlier game by Maddy Thorson, An Untitled Story. I think it is the way the mountains are drawn in the background and the thick outlines.
A link to play Celeste Classic: https://www.lexaloffle.com/bbs/?tid=2145.
Hmm, it definitely doesn't allow you to distribute them as open source (or CC or whatever) but I don't know that I'd agree that it forbids you from shipping them with something that's otherwise open source.
Though clearly the intent is that these be used more in the final product stage of the kinds of things that are more rarely open source, games vs. engines or templates.
I found myself thinking about a different copyright corner-case when reading the post and this question: the fact that typefaces aren't copyrightable in the US. Fonts are, as computer programs, but typefaces (and so also fonts that are simple bitmaps) aren't. So this workflow goes from a non-copyrighted source, (the original tilesheet) to a copyrighted output (the TTFs) and also back to a non-copyrighted output too (the output tilesheet/atlas).
Very nice! One question: I was curious why you chose this subset of Scandinavian special characters.
There are three extended chars in Swedish (äöå) and Norwegian/Danish (æøå), but your fonts have æ, but not ø, which means you could drop the æ and still support Swedish, or add an ø to also support Norwegian and Danish. Was this an oversight or is there some locale that has just æ and not ø? (and before anyone asks I did not confuse æ with the oe-ligature œ, which is a different glyph used in French, and which the fonts also do support)
This was just an oversight. I actually got very far into the project before I realized that ø was missing from my set.
It’s something that I could definitely go through and patch into all the fonts, but I was waiting to see if there was enough demand for the effort. I think supporting two more languages would be very cool though.
From a Dane that finds multiple of these fonts gorgeous and highly appreciate the elaborate kern pairs: please consider patching the fonts with an ø. ;-)
Was this an oversight or is there some locale that has just æ and not ø?
Well, Icelandic uses ö in place of ø, but also requires ð and ý which are not included.
Æ is sometimes used in older English texts, though, in words like “encyclopædia” or in plurals of latin-derived words: https://en.wiktionary.org/wiki/Category:English_plurals_in_-...
What an amazing accomplishment! Bravo.
I find typography resists my attempts to wrap my head around it, because even though I can do basic analysis like serif vs sans serif, I get a sort of brain fog when it comes to telling fonts apart or intuiting which fonts to use in different situations.
It's really hard to wrap my head around the idea that one person could make 175 fonts and that they would each be meaningfully different from each other. Like, how does one not accidentally recreate the same font?
Actually it is impossible to recreate the same font from memory. Even if you tried the font would be in some ways different. With pixel fonts where the grid is very coarse its much easier to do but normal fonts with curves you wont make it. Even if you are using same image of a font as a reference.
Sometimes I would get pretty far into a new font only to realize it was almost a total copy of another. It happened, I just managed to notice before releasing them lol
Fascinating, I didn't previously realise you were converting pixel fonts to vectors when encoding them to TTF. I guess that gives some ability to seamlessly scale them for folks who load them into a competent text renderer as well (i.e. not a game engine that mostly just uses pixel fonts 1:1)
It also just makes them usable in traditional graphics editors like photoshop, indesign, affinity, aseprite, etc. Those tools do not have the concept of a pixel font, so using a TTF with hinting/antialiasing turned off allows you to use them in those apps.
About kerning. Uppercase Finnish is a nightmare. Odd pairs like LJ and KY and TY . How about an option to let some letter pairs touch ?
It also creates a tendency to use quite light font weights for all-uppercase text, so that whitespace is not so prominent.
Not a bad suggestion at all. Lots of fonts even provide ligatures for certain letter pairs so they can touch, but tweak them so they look a bit better.
That kind of thing is another level of polish that I could definitely do, or even just providing more spaced variations.
This is really excellent work, and a great write-up. I think it would definitely be possible to speed up a lot of the algorithms with some tricks. Replacing hashmaps with bitmaps and byte-index arrays for character painting and ascii-to-variants seems like a lead, based on what I've read. Of course, that doesn't really matter for this code since it's already fast enough.
Glad you brought this up, because it's absolutely true! All the code is not on the site, but I actually allocate and clone a lot of strings and data structures as well. I did optimal code where it was obvious (bitmap copying, easily parallelizable things), and it was SO instant that I didn't even bother trying to optimize the other things. But it could be done!
It's easy to forget how fast on-the-ground languages like Rust and C++ and Go are, not to mention when you use their multi-threading primitives and worker queues/etc.
Curious: Once the fonts are made, how are they marketed and sold?
Where do the people who use them become of aware of them and how?
A combination of word of mouth and itch.io's search system. I have a decent amount of social media followers, many who have used my fonts in the past, so the initial flood of wishlisters put it on the front page for a bit.
After that wave, they get used in various projects here and there, and those projects eventually release or post screenshots. Because it's indie, lots of people also attribute the fonts directly when they post screenshots of their games, posters, videos, and stream overlays where they use them. I am very supportive of people using them, and repost their work, and so it's very casually symbiotic.
They're not lucrative on the scale that you might expect from a company or a popular vector font, but as supplementary income for a solo developer what they bring in helps put food on my table and also helps indie games get made which I think is great.
I actually liked some of the fonts and simple styling used in the site. Luckily it's available as another post: https://chevyray.dev/blog/how-this-site-is-made/#catppuccin-...
Fantastic!
Da Vinci types like the author here always remind me that there was a time when being an artist and an engineer were one and the same, with no clear distinction between the two.
Awesome work! It's a wonder how much hasn't been done in a world of 8 billion people. A single skilled individual with some free time filling in a gap can be HUGE. Gets me looking for gaps.
8 Billion people seems like a lot, but it cuts down fast. When 1/10 people have the freedom and, 1/100 the resources and time, 1/100 the training and experience, and 1/100 have the drive, and with hundreds of domains each with hubdreds of major unfilled niches...
That's 800 people split among tens of thousands of gaps. It pretty quickly gets down to you, the reader, to pick up that keyboard and start tapping away!
These are obviously wild-a* numbers. Constraints may be overstated or understated & they're not fully independent. I'm missing others. The point stands: you need only to cut 8 billion by 100 a few times to get <1.Nice! I'm a user of your last batch of fonts, I'll have to check these new ones out :)
Impressive and a nice site. Regarding font generation, let's not forget Donald Knuth and his https://en.wikipedia.org/wiki/Metafont software which generates raster fonts.
Even though the methods is simple, the way the author visualizing it is really neat.
It's not really unique to Rust. Scala and Java both support this out of the box.
The stronger guarantees/performance fall out of the stronger lifetime/ownership model, combined with errors around ambiguous/invalid lifetimes being a compiler error.
In other languages those violations are things you have to run a race detector and actually evoke the condition to find, or you abandon fine grained/tracked ownership and use garbage collection.
None of that matters with this code. There are no lifetimes here and in fact there is no ownership either. Everything is a primitive char. They’re always copied and no mutation occurs. It’s pure computation. You could write this code exactly the same way in those languages.
Java's HashMap for example is not thread-safe, but if you use it from multiple threads, you may or may not experience all kinds of issues.
Again that only matters if there is mutation. Reads are perfectly safe to happen from any thread. This code is self contained. Rust isn’t a silver bullet here.
True. You could write it in C or asm too, and it would be about as simple. But there's still a difference that if they weren't all primitive (and you can't always rely that they will be), you'll know it won't work straight away in Rust, whereas in the others you need to walk every data type involved to make sure ownership is clear (or rely on a garbage collector to save you).
Yeah, but in Rust it’s far less likely to explode in your face.
Or in Ada. Ada 202x[1] brings enhancements like the parallel block, making parallelism easier to express, somewhat similar to Rust's approach but still with Ada's emphasis on clarity and safety.
[1] https://blog.adacore.com/ada-202x-support-in-gnat (2020)
There may be more enhancements that I may not know about or remember, although I did mention Ada's constructs for safe concurrent code before.
Rust is built to be memory- and thread-safe by default. Assuming you follow the prescribed rules of the language, multithreading is “free”.
Amdahl’s Law still gets a vote, but at least your app won’t blow up in your face.
I'm wondering if you're referring to the async await addition from a few years back, to use of Tokio's crate(s), or something else.
I think they are referring to this section: https://chevyray.dev/blog/creating-175-fonts/#automatic-kern...
In this case they are not using async but Rayon which provides some easy primitives for splitting tasks into smaller parts that can run in parallel. In this case the par_iter and par_extend calls.
IIRC, async/await in most languages doesn't imply multi threading, it just allows other work to be done on the same thread simultaneously.