Quote:
Originally Posted by Quoth
Obviously you mean PDFs that are envelopes for images and not ones that can can have the text extracted and converted to something more CPU and screen friendly?
How does it compare with greyscale and 1 bit monochrome multipage TIFF, which used to be more common for scanners and electronic Fax reception before PDFs were misused for the purpose?
|
I'd originally expected to use plain-text/markdown for a reflowable format for the device and only convert .PDFs for technical documents, and etc. where I wanted to preserve the original formatting and rendering, but I think now that I'll skip the plain-text entirely -- converting and sending .PDFs to the device really achieves all I need and compression is good enough that I don't need to save space by storing plaintext instead.
Plus, reflowable text would mean having rendered characters in a set of sizes in a set of fixed-width fonts (at least a serif and non-serif in regular, bold, italic, and bold-italic) -- a route I'd started to go down, generating three-bit (to free a bit as a run-length repeat flag) packed-pixel font pixmaps... but if I were to cover all the characters I'd like to support (basic and extend Latin, Greek characters, mathematical symbols and operators) in a range of sizes useful on the e-ink display... well... yikes... that's a lot of data just for fonts.
It turns out that just doing the heavy lifting and rendering on the computer instead is a whole lot easier. And the results are nicer - if I start with a .PDF of the text I want that's nicely laid out, the results will look great on the screen.
The format I'm using is designed around offering reasonably good compression, while still being extremely easy for a microcontroller to interpret - the bit depth is always and only four-bits per pixel, all pages are the same dimensions, and the pages are fast and easy to decompress after determining the page's offset into the file from the header.