I was planning to build an e-ink display when I came across the Xteink X3 online. Somewhere in the fine print, it said the thing was fully programmable.

I was sold.

When it arrived, I liked how flat it was. It felt solid in my hand. I started adding things to the CrossPoint firmware: a different boot animation, dice I could roll by shaking the reader, a LinkedIn QR code for SF networking events.

But getting stuff onto it was tedious. I had to join its hotspot and open a little upload website in my browser.

Yuck.

While looking for a nicer way to send things to it, a thought struck me. If it looks like paper, it should act like paper.

I should be able to print on it.

What makes a printer a printer?

I wanted to open something on my MacBook, press Print, and pick the Xteink. That meant finding out what my computer expected to find at the other end.

I ended up in the Internet Printing Protocol, or IPP. It lets a computer ask a printer what it supports, submit a document, and ask what happened to the job. The messages travel over HTTP. An operation such as Get-Printer-Attributes asks about capabilities; Print-Job sends the work.

I advertised monochrome output, 300 dpi, one copy, and one-sided printing. For document formats, I accepted Apple raster and PWG raster. That meant the Mac had to turn the document into pixels before sending it. penguin would shrink the result to fit its screen.

I declared A5 and Letter paper, media type stationery, and an output bin called face-up.

I called it penguin. It had the right color scheme.

I used Bonjour to announce an _ipp._tcp service under that name. The advertisement included the formats I accepted and the address where print jobs should go.

To get driverless discovery on macOS, I also had to add the _universal subtype. That meant calling ESP-IDF’s mDNS API directly, because the Arduino wrapper didn’t expose it.

Getting the computer to send a page was only part of the job. I still had to receive it on this thing.

Where do I put the page?

A Letter page at 300 dpi is 2,550 × 3,300 pixels. At one byte per grayscale pixel, that’s about 8.4 MB uncompressed.

The X3 has 400 KB of RAM, with 16 KB reserved for cache. I needed to run Wi-Fi, run a printer server, and somehow receive an entire fucking page.

With Wi-Fi running and the printer’s page image allocated, I had 6.8 KB of heap left.

I remembered mmap on Linux. Could I do something like that with the SD card and pretend I had more RAM? The C3’s memory-mapping support was for flash, not files on the SD card.

But wait. Could I make the display my storage?

What if I passed the incoming page through a transformation pipeline and wrote the result straight to the display? Decode the pixels, shrink them to fit, dither them into black and white. As soon as a row was ready, put it in its place on the display and reuse the working space. Keep going until I have a page.

The display already had RAM reserved for its screen image. I could build the page right there as it arrived. Until then, I had been assembling a whole second image just to copy it over.

My decoder already worked row by row. I changed the scaler to hand over finished rows too and wired those into the display’s screen image. At first, I let the page appear in bands, like paper feeding out of a printer. Each intermediate refresh took roughly half a second, so I switched to showing the finished page all at once.

I saved the finished page as a BMP on the SD card using the existing screenshot writer.

That gave the network stack room for its socket buffers.

There was a penguin in Preview

I had a sample manga image from Mushoku Tensei on my MacBook for some reason. I opened it in Preview and went to print it.

There was penguin in the printer list.

Holy shit.

I selected it and printed. The manga page looked really good on the Xteink. From memory, it took about a second to appear. It’s still there.

I spent an evening getting to that first print.

The printer server runs on the reader itself. I can have it join a Wi-Fi network or start its own hotspot, literate-penguin.

My penguin can read now.

The code is in my CrossPoint fork, including the printer implementation.

Saved printouts stay on the SD card, and I can browse them on the reader. My printer has an output tray after all. It’s a folder.