[stevenaleach]

I'm waiting impatiently for two ESP32 devices to arrive now - one, an M5Paper from DigiKey, and the second an M5Faces kit from AdaFruit because... well... I'll figure out lots of becauses for that little bit of kit I'm sure ;-)

The Paper though: I think I've figured out how I plan to put it to work: With .PDF as an intermediary format, books/papers/notes/etc. can be converted (thanks to the Python pdf2Image library on PyPi) to greyscale images of any desired size. I'll be going with 960 X 1706 ((Y/X)*Y, Y) - that means text that is too small to read in portrait mode (down-scaled by .5625 to native screen resolution) can be read in landscape, scrolling a full-page width window down a quarter screen at a time (that allows for some overlap since the page will take 3.259 landscape-screens to cover). With images adjusted to four-bit per pixel and run-length encoded (with RLE for both pixels in lines and for entire lines since there will be so much white-space involved), tons of "books" should fit on an SD card.

Now the goal of all that is to turn the paper into something I can "print-to" from the computer. Since I can print to .PDF from any application (which might be a desktop publishing program, might be a web browser if I simply want to "print out" a page I'm looking at), and since it would be so easy to set up custom scripts to convert from ePub/Mobi/Markdown/etc. to a .PDF, that means I can convert all the documents I wish I could print if I only had a printer sitting here (I don't) and carry them in a relatively high resolution in my pocket.

I'm picturing an interface where all of the basic features can be accessed with just the three buttons (so page turning or scrolling depending on orientation with the "up" and "down" buttons, center button to select menu to return to library, to jump to a page, to change screen orientation. That way the resulting code could be run on any MicroPython device hooked up to an eInk display regardless of whether the touch interface is available or not....

but... if the touch interface is there, that also allows pinched scroll and zoom (which might come in handy even in portrait view where you might need to upscale to 2X or more to view tiny text underneath an image in a technical document for instance.

Features using the touch-screen should be enabled and disabled from the menu because by relying on the buttons alone, the device can sleep with just the ULP and RTC running (Main cores, memory, wireless, and display powered down) and can be woken for page-turn events, with the current document filename stored in flash and the current page-number and scroll position stored in RTC memory -

Now I'll probably try to also extract plain-text for each .PDF page as well, and store that on the SD along with each page to make texts searchable (just returning a list of pages that a search string appears on - since the page is a bitmap, it won't be able to highlight search results.. .but that's fine).

I'm liking this plan - using .PDF as an intermediary format makes sense, and the 1.7777 upscaled 1706x960 virtual screen size *SHOULD* do quite nicely with most any documents (It would *almost* fill my laptop screen, and it's a whole lot bigger than the 1360x768 display I have turned in portrait orientation next to my laptop that I often use to read .PDFs on. I'd imagine, then, that with 1.25 times the pixel width (in landscape mode, compared to my existing side-monitor in portrait), the M5Paper with it's crisp eInk pixels aught to do just fine as a reader for any and all content I can convert to .PDF if it isn't there already.