One maker took the Xteink X3, a compact e-ink reader, and made it work as a printer instead. They arranged it so a MacBook can ship papers to the device through Wi-Fi, acting just like a genuine printer would.
A flat, handheld e-ink display known as the X3 caught the attention of its developer after they discovered it was fully open to change. They purchased the device and began modifying the CrossPoint firmware, adding a new boot animation along with dice that roll when the reader is shaken. A LinkedIn QR code was also included for use at SF networking events.
The developer found that putting content onto the device moved at a slow pace. To do so, he needed to join its hotspot and then open a small upload website inside a browser. Given how much the device resembled paper, that method felt wrong.
Finding the right protocol
A person who builds software attempted to start a print job on a MacBook, press Print, and then choose the Xteink from the available options. This required working out what a computer expects to find at the receiving end of a print job.
IPP stands for Internet Printing Protocol, and it is how a computer can ask a printer what it supports, send it a document, and find out what happened to the job. The messages move through HTTP. One operation, Get-Printer-Attributes, requests information on the printer’s capabilities. A second operation, Print-Job, delivers the actual work.
The developer promoted a few key features: black-and-white printing, 300 dpi resolution, single-copy output, and one-sided printing. Document formats were limited to Apple raster and PWG raster, which meant the Mac had to convert text files into pixels before sending them over.
Once the result was prepared, the device would reduce it to suit its display. The creator specified A5 and Letter paper, a stationery media type, and an output tray known as face-up. That printer bore the name penguin, and it matched the correct color scheme.
How a Mac finds the X3
That name was used by the developer when announcing an _ipp._tcp service via Bonjour. The advertisement contained the formats the device accepted, along with the address where print jobs should be sent.
Getting discovery without drivers on macOS required adding the _universal subtype, which meant the team needed to call ESP-IDF’s mDNS API directly since the Arduino wrapper did not expose it.
Sending a page from the computer was just one step. The developer also needed to set up the device to accept it.
The memory wall
At a resolution of 300 dpi, a Letter page spans 2,550 by 3,300 pixels. Given that each gray pixel takes up one byte, the total size works out to roughly 8.4 MB uncompressed.
This device packs 400 KB of RAM total, with 16 KB allocated specifically for cache. The programmer’s challenge was to manage three separate functions at once: running Wi-Fi, running a printer server, and receiving an entire page.
The printer’s page image was put aside with Wi-Fi turned on, leaving the device with 6.8 KB of heap remaining.
The amount was insufficient for a complete page. The programmer recalled mmap on Linux and considered whether something comparable could be done with the SD card. However, the C3’s memory-mapping capabilities were designed for flash, not for files stored on the SD card.
The display as storage
The central concept arrived next: the display serving as its own storage space.
A pipeline changed the page’s contents, and the developer wrote the output directly to the display. Pixels were reduced in size and turned black and white along the way. Once a line was finished, it took its place on the screen, and the memory space was freed up again for the next pass.
Before, the developer had to piece together an entire second image just to copy it over. Now the display already holds RAM set aside for its screen image, so the page can be built right there as it arrives.
The row-by-row decoding was already in place. The developer altered the scaler to deliver completed rows as well and connected those directly to the display’s screen image.
The page began appearing in strips, similar to paper emerging from a printer. Refreshing the center of it took about half a second each time. To fix this, the developer decided to show the whole page at once instead of piece by piece.
The completed page was stored as a BMP on the SD card with the help of the existing screen-shot writer, which freed up space in the network stack for its socket buffers.
The first print
A sample image from Mushoku Tensei was sitting on a MacBook, and the developer decided to open it in Preview. From there, they moved straight into the print menu.
There was penguin in the printer list.
The developer picked it and made it show up. The page came out looking great on the Xteink. I recall it took about a second to turn up. It remains visible now.
The developer spent an evening getting to that first print.
A reader that prints
The reader hosts the printer server. It can either connect to a Wi-Fi network or start its own hotspot instead.
This machine serves two purposes: it prints and it reads. The software sits within the CrossPoint fork, where the printing work was added alongside other changes.
Printed documents remain on the SD card, allowing the maker to examine them using the reader. There is an output tray for finished pages, which functions as a holding place for the files.
| Feature | Xteink X3 as printer | Source detail |
|---|---|---|
| Result | E-ink display, saved to SD card | Page appears on screen, BMP saved to card |
| Memory | 8.4 MB page, 400 KB on hand | 400 KB RAM, 16 KB for cache |
| Connection | Wi-Fi via IPP | IPP over HTTP, Bonjour discovery |
| Page size | A5 and Letter, black and white | Declared in printer attributes |
| Output tray | A folder on the SD card | Folder browsed on the reader |
Hard numbers
- Xteink X3: 400 KB RAM, 16 KB set aside for cache
- Heap left with Wi-Fi and page image: 6.8 KB
- Letter page at 300 dpi: 2,550 × 3,300 pixels, about 8.4 MB uncompressed
- First print time: about one second
- Time to first print: one evening
- Printer name: penguin
What made the developer’s method stand out was its reliance on a shift in perspective rather than hardware expansion. No larger processor and no extra storage were needed. Instead, the solution hinged on reimagining how data is stored.
In the CrossPoint fork where the project sits open, the developer has not said if they intend to add color or faster speeds. What they have confirmed is that the printed page remains on the display.
For now, the penguin prints.
Source: nishantjosh.dev
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.