How to build a printer

Original Article ↗ Hacker News Discussion ↗

Emulating a network printer that “prints” directly to an e‑ink reader instead of paper is inspiring creative ways to decouple reading from phones and laptops while reusing existing print workflows. Commenters dig into technical trade‑offs like raster formats versus full PDFs on low‑RAM devices, IPP/AirPrint standards, and optimizing for 1‑bit e‑ink displays, while sharing related CUPS hacks and alternative formats such as DjVu. The thread also surfaces broader frustrations with traditional printers and imagines new use cases, from recipe displays and digital photo frames to tighter integration with Kindles and other open e‑ink hardware.

Overall reaction

  • Many commenters find the “e‑ink device as a printer” concept delightful and “so correct.”
  • Some were initially expecting a tutorial on physical printers (ink/heads, etc.) but still enjoyed the twist of “paper that acts like a printer.”
  • A few express confusion about the point of the project, but others describe clear personal use cases.

Why emulate a printer to an e‑ink device?

  • Core appeal: every OS already has a print dialog; selecting the e‑ink as a printer is frictionless.
  • Use cases mentioned:
    • Printing recipes to keep phones out of messy kitchens.
    • A portable reading device that reduces phone usage.
    • A digital photo frame that receives photos via “print.”
    • An e‑reader that saves printed material as PDFs.
    • Potential as an outdoor-friendly secondary display.

PDF vs raster and device capabilities

  • Some ask why not send PDFs directly, especially since product specs claim PDF support.
  • One explanation: running a full PDF rendering stack on constrained hardware (esp32-class, limited RAM/ROM) is complex and heavy.
  • Others counter that the device is marketed as an e‑reader with significant storage and native PDF support, so capabilities are somewhat unclear.
  • Consensus in the thread: for this hack, receiving simple raster data is often easier and more robust than implementing full PDF handling.

Printing protocols and optimizations

  • Discussion of modern printer standards: AirPrint/IPP Everywhere, Apple Raster, PWG Raster, HP’s “raster PDF” (PCLm).
  • Suggestions:
    • Declare the screen’s exact media size in IPP so the host formats correctly.
    • Use 1‑bit (bi‑level) mode instead of 8‑bit grayscale to reduce data size and memory usage.
    • Tuning dithering is important; the software stack is complex and full of legacy issues.

Alternative formats and e‑ink behavior

  • DjVu is proposed as a possibly better fit than PDF; others note it mainly shines for grayscale/color scans with more gray levels than e‑ink typically uses.
  • Detailed explanation of e‑ink’s limited, temperature‑sensitive grayscale and ghosting, leading to a preference for 1‑bit or low‑bit-depth rasterization.

Broader ecosystem: devices, DIY, and software support

  • Some compare Xteink models (X3, X4, X4 Pro): trade‑offs between backlight, USB‑C, and battery life.
  • DIY printer ideas surface: pen plotters, daisy wheel projects, open‑source printers, and reusing 3D‑printer mechanics.
  • A CUPS backend for another e‑reader is mentioned as a similar approach.
  • Concern that printing support is disappearing from some modern apps (e.g., popular editors on macOS), despite long historical linkage between text editors and printing.
  • Side thread praises cheap, long‑lived mono laser printers over disposable inkjets.