Last project log I discussed trying to reduce MuPDF to a size that could fit on memory reasonable for a micro-controller. Thankfully, the library's maintainers designed it so including or removing certain modules is as simple as changing a single configuration file. With the help of the maintainers, and their excellent documentation, I quickly realized that the size of the library is not due to the code itself but an artifact of the fonts included.

Removing all the fonts dropped a test program (desktop, not embedded) from 40MB to 5MB with no other optimizations. Now, an e-reader with no fonts is not very useful. So I looked for small font families and slammed into a old problem. As of writing this, Unicode contains 149,878 characters. However, only 65,535 characters can be in a True Type font file. As a result, no single font family can represent all Unicode text an e-reader might encounter from an arbitrary book file.

There are attempts to make a uniform typeface for all writing systems like Google Noto or GNU Unifont. But, for example, all the GNU Unifont OpenType fonts are ~12MB and the Google Noto fonts are ~10MB. Even ambitious projects like Joey Castillo's Babel use 2MB to represent Unicode's basic multilingual plane (65,520/149,878 characters as of version 15). EPDiy, an ESP32-based e-Reader project, requires editing the source to add or change fonts. Other generic micro-controller font libraries, like OpenFontRender for the Arduino ecosystem, MCUFont, or mcu-renderer require preprocessing the fonts on the host machine before programming the target device--almost always reducing the subset of characters that can be rendered.

Simply put, fonts take a lot of storage. A micro-controller certainly can represent all the Unicode characters, but, given the low resource environment, it makes the most sense to limit the characters that can be rendered.

I started down this path to decide if I should continue this project with a embedded Linux system or with a micro-controller system. Given the project's goal: democratizing e-books, supporting as many characters sets as possible is a priority. Thus embedded Linux is the better path to follow.

My first step down this path is getting familiar with Buildroot, a tool that simplifies embedded Linux configuration. There are lots of examples for the Raspberry Pi boards, but I plan on eventually moving away from them to a custom board with a different chipset. There probably won't be any new hardware or software features for a while as I figure out Buildroot. Maybe I'll write up a getting started guide once I find a configuration I like. We'll see. Wish me luck.