White space around each letter is completely critical for fonts like this. That makes this font 4x4 as presented, or 3x4 but you lose a lot of readability—too much imho.

The exception to this would be a physical manifestation, where each 2x3 pixel block was surrounded by a dead space, so that the display was actually optimised for this font configuration.

Still, that’s an impressive accomplishment, allowing a 16x32 character display on a sub 1$ oled, and 10x18 on a 3$ integrated computer with built in display.

Nice work.

For anyone actually thinking of using tiny fonts in a practical project, imho 4x5 (3x4 plus padding) is about as small as it gets for a font that doesn’t require extra work to read, giving 1 pixel of (violable) padding bottom and right. Unlike the OP font, it only needs 1px of top padding to be perfectly readable, so you are actually getting “free” readability compared to needing top+bottom padding like the OP font.

▲

gliptic 3 days ago | parent [-]

Glyph advance or line spacing is not part of the bitmaps.

▲

K0balt 3 days ago | parent [-]

I get that, but it figures in when you actually put this on pixels. I’m thinking about practical use of such a font, most likely on a pixel-constrained screen, otherwise you would use a higher definition font.

It’s a cool hack, and for someone actually using little fonts like I do in real world devices it’s very interesting.

I find that you can actually go 4x5 (including padding) and still have great readability. Any less and you have to work to read it.

▲

bigmadshoe 2 days ago | parent [-]

By this definition every n x n font is actually (n + 1) x (n + 1), but that isn’t the convention and fonts are never displayed with 0px vertical or horizontal spacing between letters.

	▲	K0balt 2 days ago \| parent [-]
		I see you didn’t grow up in the 8 bit age lol. Early computers usually displayed characters directly mapped to the screen, with no space between them. There wasn’t enough memory to store a bit for each pixel, so they stored only the characters and wrote them out one line at a time from the ROM character map. Sometimes, you could define a few characters in RAM as well. Then if you were lucky there were “sprites”, characters that could be mapped at arbitrary alignments and sometimes even rotations “on top of” the existing character map. This is how you got a 32x64 display (often only 32x32) mapped into 2k of RAM, instead of the 16k it would take if the pixels were stored— a time when 8k RAM total was pretty standard, and 16k was a lot. Then, color became a thing and ate up a lot of memory, so even with 64k nobody was generally mapping fonts onto a pixel background. That’s why you switched to graphics modes etc. This is also why you will find a bunch of 8x8 pixel fonts out there that have blank rows and columns built into them for spacing. It’s still very common for imbedded work, where you often have screen sizes like 64x128 and other small pixel counts, when you are trying for maximum readable density. You can still find these fonts in the text-only display modes when you are in the POST routines off many PCs, if you unhide them in the bios…. But many BIOSs are graphics mode only now so even that is getting hard to find. Still there when booting Linux though, if you escape out of the splash screen.