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.
If you like Celeste, check out Studio Pixel [0]. His most recent game Kero Blaster (mobile) is excellent but Cave Story is the classic. Tight controls, retro aesthetic, imaginative levels, very well executed.
Cave Story is a game I looooooved many many years ago and it warms my heart to see it ported to so many modern systems. I got my roommate playing it one night and she was hooked.
I have 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.
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).
You have a point!
You may be able to legally distribute binary builds of a work that is open-source except for these fonts,
as long as the open-source parts aren't copyleft and the fonts aren't part of the source distribution.
I should have said the license didn't allow you to distribute the TTFs with your open-source code and assets.
Sorry for probably overstating the case.
According to https://en.wikipedia.org/wiki/Intellectual_property_protecti...,
typefaces also aren't copyrighted in Japan and South Korea but are in Germany (for no more than 25 years) and the United Kingdom (also 25 years).
So bitmap fonts from classic 8- and 16-bit video games should be in the public domain in all of these countries.
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. 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.
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.
I'm sorry I just don't buy this. Its possible to endlessly obsess over anything. I've noticed things like language/writing/music/calligraphy tend to have high draw to people that are prone to obsessing.
It sounds like gatekeeping to me is my point. Discouraging people from entering a field always makes me a bit triggered.
I am not sure that anyone is trying to discourage people from entering the field of type and design. A child's handwriting (or indeed mine, which is very child-like) can be read but that does not mean that it is readable. In order for the consumption of type to be a pleasurable experience, its design must be considered. Design involves the consideration of the space between foreground elements, the contrast of foreground and background elements, the grouping of foreground elements into familial sets (e.g. beginning, middle and end) etc. People have been concerned with this subject for millennia...
Western fonts derive from Roman lettering which were carved in stone. The dedication inscription at the bottom of Trajan's Column is arguably the most sophisticated example of this. The text at the top of the inscription is larger than that at the bottom so as to appear perceptually uniform from the point of view of the viewer (who is located significantly below the inscription).
Letter forms are weighted towards the bottom. The designers of Bauhaus (who were very reductive in their thinking) tried to do away with this and produced super-regular typefaces based on squares and circles. They quickly realized that this produced a result that humans find unappealing and unreadable.
The digital age saw the adoption of characters that were dimensionally uniform (i.e. monospaced fonts), such as employed in the comment widget of HN. Of course such fonts are easy to digitally express, but as I am sure you will agree for a printed document the effect is clunky and lacks flow.
It is this ongoing dedication to form, structure and readability that is at the heart of effective typography.
I am not a typographer, but have worked with many in my job. I often mock-up page layouts and show it to my designer for their approval. Of course, I think I have done a marvelous job, but their response is always the same: 'yeh, really nice. However, maybe you change this space, this color, this font etc etc'. The result is always 100 times better.
I agree with parent. To create a font family from scratch, also to create many others things from scratch, does not take that much time, at least it does not have to take that much time.
You can create a font quickly, sure. To do a good job will take quite a bit longer.
Helvetica took a year. For the semi-bold variant in one size. The thin, bold, and italic variants took about a year each. Helvetica Neue has fifty-one variants, that's not something you're going to do quickly.
Nobody's gatekeeping, we're just acknowledging the huge amount of work that goes into creating a font. It's easy to forget sometimes as both Apple and Microsoft include very high quality fonts with their products for free.
There are plenty of open source tools to generate fonts. So go ahead. Make your own font. I spent some time trying to make a font based on the writing of some youtuber. It's a fun exercise. And while drawing (tracing) the characters was actually quite a lot of work, that's about the easiest part of making a font.
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 ø. ;-)
I will absolutely consider it. I am getting some good ideas from other comments as well, so I'll put those in my project notes to do as a possible update to the fonts.
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.
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
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.
In that case I encourage you to read up on da Vinci (and not some top 10 dV creations post). It is clear that there was quite a big distinction.
I can model a spacecraft that will take me to Alpha Centauri with "questionable" untested dynamics in Maya. But I am pretty far off from building it and sending it into interstellar space.
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.
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.
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.
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).
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.
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.
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.
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
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?
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
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.
Awesome read! I've never designed a font but often daydreamed about it, and this was a great primer to the process.
Question: Did you find that your automated kerning generator was always satisfactory? Or did you ever catch letter pairings that technically satisfied the criteria but that tripped your subjective kerning radar?
I'm wondering if you had to hard-code kerning exceptions, or if your system even allowed for that.
I absolutely did find examples where I needed to specify. I kind of allude to that in the post, but yeah whenever I add the ability to automate something like this, I almost always make sure to include the ability for me to manually override them. Experience has taught me that no matter how fancy or super special your algorithm is, there's always situations where the naked eye just sees what the robot can't.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
I did a quick search, this for Hungarian support, yes? If those are the only two characters I would have to do to support the language, I'm collecting suggestions from other comments in this post as well and might do a 1-year anniversary update to add support for more languages, and I can add this.
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.
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?
I also took a look and couldn't find any info. If you want to take a leap of faith, once you buy the assets there's metadata files including individual glyph sizes and kerning info so you could find all the ones that fit your project
Check out The Ultimate Oldschool PC Font Pack (https://int10h.org/oldschool-pc-fonts/). Each font description includes glyph dimensions and aspect ratios
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.
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.
some is a homie and does excellent work! They also have a Patreon where you can support/guide them in the creation of new pixel art assets and fonts and stuff like that, if you're into that sort of thing. It's a cool approach, different than mine, and I'm rooting for them.
I wanted to describe how the algorithm works, and show what it looks like to ship a project of that magnitude, and share some of the fun problems complexities that come up. I'd like to see more creatives using code as a way to bolster their projects and reducing tedious work for themselves with automation or deployment scripts, and I think Rust is a really great language for doing this, so I thought it would be inspiring to share how and why I'm doing it.
I agree that it would be overall more valuable to have the whole thing open source online, but sometimes I want to share how I solved problems without open sourcing all my code directly, for various personal reasons. But from the many comments I'm getting across the internet on the article it seems like people are getting a lot of value and motivation out of it, which was the intent, so that makes me happy.
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...