Quote:
Originally Posted by murraypaul
I think you are working more directly with the hardware, rather than using the M5 development stack?
Because the board API they supply already has code for the device to render arbitrary TTF fonts at different sizes and display them. They don't have to be fixed-width either.
I have a toy-working text + basic bold/italic display with full justification with non-fixed-width fonts, the API does most of the work already.
|
And the Adafruit GFX library provides (mono-spaced, scalable - though only by multiples of the base size bitmap) font support as well - and is what I'll be using for printing to the little "interface" screen on the device - an Adafruit SHARP Memory Display - it's what the memory display library is built on/with -- there's a Waveshare library built on Adafruit GFX as well, but it doesn't yet support the display I ordered and I don't yet know how hard it would be to modify -- but I'll probably skip that and go with minimal code based on Waveshare's examples on Github that just implements a full page update.
The big 1404x1872 e-ink display will be used as a page canvas only (never being used for menus/UI display, which is why I really don't need fancy stuff like partial updates). I *could* print text on that canvas and basically duplicate the traditional ereader experience (when used to view EPUB/MOBI) - but that wouldn't really justify the nice display..
But by using compressed pixmaps and a simple container format, I can render the page on the computer from a .PDF file that looks *exactly* how I want. The first book I converted, as I said, was 'Hackers' by Steven Levy. One of my favorite books as a kid, and I can honestly say, a text without which I probably never would have wound up soldering together an ereader thirty years later (or be quite as strange in general),.... now the .PDF that Google served up to me is *EXACTLY* the same as the print version, and it feels like the book I know and love and have owned several physical copies of over the years. The second book I converted was K&R's "The C Programming Language, 2nd Edition". Now again, this is a text I've owned many copies of through the years, a text I know and love, and the .PDF is exactly the same presentation as the printed text - the way it "should" be.
Now your argument is that these documents "should" be handled as text instead... well... there's plenty of affordable e-readers on the market that can display .MOBI/.EPUB/plain-text... but I wanted something that I could actually put books on... not just the text content of the book, but the actual pages as they should be... and for technical documents, it's absolutely essential - think Arxiv papers with graphs, figures, text associated with figures, equations, etc. etc... There's at least a few very-much-not-affordable (>$600, some in the thousands) e-ink tablets that can handle .PDFs.... but even if the cost weren't a concern all of these are too-much device - lots of extra features I don't want, don't offer battery life I'd be happy with, take time to boot up a full OS, and and general aren't what I want -- and none could be taught other tricks like acting as a USB display to plot/'print' things to from the laptop... so the DIY route it is.
Text that isn't in .PDF form yet.... that's what Pandoc is for ;-) If I want to read a book in EPUB/MOBI format, I can convert it using Pandoc, playing around until I find a font and other options that I like, and then I can convert the .PDF and load it onto the device.
And just imagine trying to implement Arduino/Espressif code to handle Latex Math in the available memory.... and if you COULD pull off that superhuman feat, how long would it take to draw a page with a lot of formulas? Yikes... But why would I want to do anything like that, when I can let Latex handle the typesetting for me and generate a nice .PDF ready to be converted and loaded on the device.... That's a lot more straight-forward.
Or sheet music.. Yea... I COULD come up with a markup scheme for chords, chord-notes, melody notes, and draw a score on the screen --- or I could use LilyPond if I want to typeset a score from scratch and it'll produce an absolutely beautiful .PDF. ... and my collection of 'Real'/'Fake'-book leadsheet collections that are, of course, all in .PDF form... sure I *could* figure out a way to draw the staff and some sort of markup scheme and then I could treat it all as 'text' (after typing it all in)... but... well... I'd most certainly rather not ;-)
The only thing I wanted to change from the "print" pages was the margins - since the screen will be surrounded by a bezel/matting, the visual effect of the original margin will be replaced and I want the "ink" brought as close to the edges of the display as possible, while leaving cover pages and similar with full-page artwork alone - all of which that script takes care of.
While MOBI/EPUB type formats were appropriate and necessary when the first Kindle came out (with only 250MB storage, and a 800x600 black and white screen), I'm using the cast-off 32GB SD card that used to live in my phone (until my music collection *finally* got too big for it), and could upgrade it so cheap if storage becomes an issue that I'm absolutely not worried about storage space -- 150MB to 200MB for a book around 500 pages at the absurd resolution of the big Waveshare screen is just fine.
For the M5Paper that I'm also... stilll.... waiting to arrive at my door, it's a bit of a toss-up - since the smaller screen might be too darn small, converting .PDFs to display on it probably isn't as attractive of an option, I won't be able to get the same experience for most books on the M5Paper of having it look and feel "just like the paper version", But really I doubt if I'll even be using the M5 as a reader much - I expect it will be spending most of its time as a bluetooth macro-keyboard and password manager along with various temporary display and control panel duties every now and then - it'll probably always just be the thingamajig that I will usually be able to reflash into something else periodically without losing anything important. Also, the M5Paper has a touchscreen -- which means that actually interacting with text on the screen and entering search terms becomes an option, making having text as text rather than mysterious and unsearchable pixmaps much much more attractive.
That won't be the case with my DIY reader which will have two 'knobs' for a user interface - one to select and switch between files, and one to turn the page or jump to a desired page... no keyboard, no touchscreen. It will be very much a single-purpose device (well... two purpose device), acting essentially as an alternative to a printer and physical bookshelf/filing cabinet full of 'printed' documents. It's second role will be acting as a USB connected display through a 'receive and display' command in the serial shell - which will take a single raw pixmap and throw it on the screen -- that'll be nice... I already have a second monitor turned to portrait orientation next to my laptop that a Jupyter-Lab session always lives on -- I can't wait to be able to park the e-ink screen next to that to send plots to, to display reference material on, to preview 'printed' pages on, etc.