So I now have an actual reader build underway, to be "finished" (except for building a case for it) in a month or so when UPS brings me my Waveshare display (I went with the 10.3" 1872x1404 'flexible' display with IT8951 HAT).
The rest of the hardware consists of an ESP-32 with 4MB flash and 4MB PSRAM, a "SHARP Memory Display" (very low power, monochrome, 400x240, 2.7" diagonal, reflective/daylight readable like e-ink), one 512KB SPI FRAM breakout, and two push-button knob rotary encoders. (plus, of course a battery and SD card).
The E-Ink display is to be used only as a page canvas, while status information, menus, and other UI elements will all be placed on the little "memory display" placed beneath it. The ESP-32 will spend most of its time in deep sleep - or shut off entirely by a toggle-switch on the battery line - rather than relying (exclusively) on RTC Memory, it will make use of the FRAM to store the current file and page number as well as last page viewed for other recent files, etc. Thus waking from a cold-boot and waking from deep-sleep will behave the same. The two knobs will be positioned on each side of the little screen, the right hand knob will usually act as a page turn/page select control (pressing the knob brings up the current page number on the mini-display and you can spin 'forward'/'backward' to the page number you want to jump to, pressing the knob again to select) - most of the time this will be the knob that wakes the controller with a page-up/page-down event for which it will update the display and page-number in FRAM before returning to sleep. The left-hand knob will usually be a file-selection knob rotate to scan through the names of recently opened documents, press to select, or just press to browse directories and select documents within (information displayed will be from associated "card" files rather than path names in order to display nice title,author,date, etc. information rather than just filenames while browsing the library).
All of the hardware (but for the display on the way) is wired, tested, and working happily together, and I've now been focusing on the software side for the past few days. The native file format will be, essentially, .PDF --- converted by a python script that handles cropping and sizing, converts to 4-bit per pixel and then compresses it via a run-length encoding scheme.
The file stored on the SD will consist of a header block consisting of a null-terminated list of byte sizes for pages followed by the non-terminated concatenation of compressed pages - on first loading, the reader scan the header, adding up the sizes until it has counted to the page number it wants and then scan to the end of the index to find the base. Adding the size total to the base gives the offset to seek to to begin reading the compressed page -- ALL pages have the same width and height (1404x1872), and so the run-length decoder just scans and fills in pixels in the display buffer until it reaches and fills buffer[1404*1872] - no end of page terminator and also, I suppose, no fault tolerance in case of a cosmic ray flipping a bit somewhere, but it will both offer good-enough compression (should be able to fit a few thousand books or a few tens or hundreds of thousands of academic papers on the 32GB SD card I'm using), and extremely simple decoding easy to implement for the little micro-controller and with minimal overhead.
A serial shell will both allow for file transfer and management using python scripts on my laptop, and will offer real-time display commands -- it will easily act as an attached USB e-paper display that scripts can use for real-time information displays, for sending plots to from a Jupyter notebook, to display a "NOTES" file that can be edited and
updated as an extra memory besides paper and pencil while working on stuff... etc.. etc.
In my initial testing, I'm VERY pleased with the battery life with the esp32 running continuously, updating the display with encoder pin states, voltage, etc. on the little 1200mAh battery I got just to test/prototype with... I'd planned to order the largest battery that would fit in the case whenever I get to the case-building point, but my test code ran for well over six hours bringing the voltage from ~4.16 down to ~3.86 without ever going into sleep... it's a 3.7V battery... so with the device in deep sleep (or off) most of the time between briefly waking to turn the page, the battery I've got should actually provide days if not weeks of charge before it reaches a conservative low cut-off like 3V... and... shoot... it weighs nothing... and since I was chicken and paid more for the flexible screen because I had images of the glass e-ink panels shattering in eventual drops, the end build should be remarkably light which is a nice surprise since that wasn't a feature I was trying to optimize for.