← Back to context

Comment by greazy

11 hours ago

I don't understand the purpose. What am I missing?

The author "prints" to the eink display. Why not load say the pdf directly?

I've wanted something like this for a long time to print recipes that I'm about to cook. I don't want my phone in the kitchen getting gunk on it, so I'll usually print on paper, get the gunk on the paper, and then throw it out.

I'm not going to create a recipe PDF and load it on an e-reader. That's too much work. But I will happily press control-P on a recipe web page and select the eink display as the target.

  • Right! I like this usecase very much. For uses existing software infra to perform the required task.

    I wonder now what else we've reinvented when it comes to sending data...

From the 4th line in the article:

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

Anyway, very creative, I like the idea a lot.

I'd like my e-reader to show up as a printer, and when I print something on it it actually gets saved as a pdf on the reader. Like in the article, but multi-page pdf.

I often do 'print to A5 pdf => copy pdf to e-reader'. Would be nice to do that in one step from any program that can print.

> I was thinking of this, but rendering PDF takes a lot out of a 400KB RAM'd device. It also needs a ton of things to actually work which the ROM can't hold.

> Kindles have a ton of RAM, this one didn't.

  • It's an e-reader. According to the specs it has native support for PDF.

    • It's an esp32 MCU, even if it can somehow run the PDF render pipeline, it won't be more ideal than just accept the raw byte stream and display.