I instantly thought of Nielsen's personal homepage - http://useit.com - which has moved on to a little softer and corporate design - but still linger in the Internet Archive:
> have a system python binary and virtual envs linked to it
I'm not sure if you're saying avoid using system python?
In my experience so far, you never want to develop complex software locked to system versions of runtimes. Too often you need a bleeding edge feature, or conversely need to postpone updating due to needing an old version for some reason.
Now that PNPM supports managing runtimes [0], I found that most of Mise's offerings are actually built into package managers. Maybe I will have it graduates from my machine when I have time.
That's the beauty of asdf and then mise; they leverage existing solutions where possible, and unify how to get versioned runtimes for projects. Rust? rustup with mise, ruby? Precompiled when possible, otherwise ruby-build. Etc.
I'm not sure if I trust or want pnpm to support bundling rust for binary plugins, or various sundry toolchains.
For fast updates / high frame rate, especially also smooth fade from previous to next page, those displays only do black/white.
They can typically modulate about 14 levels of gray in-between but reliably (without really bad ghosting, due to strong temperature sensitivity of the pixel's transition response and the display being static so all gray has to be done by carefully interrupting a transition part way through) only from a nice flash-to-black -> flash-to-white -> fade-to-target-greyscale (sometimes one or two alternating full contrast flashes prepended to more intensely equalize the pixels/erase ghosting, but should only be needed every couple dozen page flips in grayscale mode).
I think the nice b/w no-flicker fade transitions chop the transitioning of all changing pixels into small burst/chunks and interleave/alternate the chunks of white-to-black with the chunks of black-to-white, so it's perceptually simultaneous.
Or it's actually pulling off some kind of tri-state driving leaving unchanging pixels alone and pulling those that change to either plus or minus polarity depending on what transition direction they are supposed to go in...
Sadly IIRC all quite proprietary-gated :(
What that means for djvu is that at least for text-only content on those readers that manage the 300 dpi "threshold" you'd just rasterize to pure 300dpi black/white (1 bit per pixel) comparable to a 300dpi "don't skimp on toner but don't you dare take half a second longer than you must in order to make the text crisp enough for $reader to have no good reason to whine about it being not crisp enough" laser printer job.
Djvu is particularly for displays with more than about 5bits of grayscale as well as for lossy compression of grayscale/color scans. And maybe also some efficiency gains on 1-bit-per-pixel quantized scans, but those aren't usually the target content for these readers, IMO.
Might want to try for them, though!
Hm.. I just tried on my Google pixel 7 Pro (obviously very different display - OLED) - and certainly seems like the result of a test conversion pdf2djvu should be at home on an eink screen. Not sure if there's a simple way to test on the only eink I have to hand; a Remarkable.
Fwiw google Gemini cane up with the following to convert pdfs on device in termux after some prodding (koreader can display DjVu):
You'll need access to storage:
termux-setup-storage
Then pipe/paste this to a script:
(Sorry for the verbose slop)
You can just render to the 1bpp text/4bpp images monochrome 300dpi target; perhaps some tone mapping due to the limited contrast ratio of the eink vs. your OLED should be done at rasterization time.
Then just map the resulting 16 brightness levels according to the contrast ratios/progression they have on your eink. Use phone camera and adjust whole image contrast/brightness/black-intensity sliders holding them side by side until the grayscale matches.
Then just pick pixel RGBs from a gray-bars test image you have opened on the remarkable before you took the picture with your pixel 7 pro. Might not easily be done on the phone but can let a python using AI grab those for you. (If it's wrong it'll be obvious or so harmless it doesn't matter anyways.)
Then you take that rasterized-to-1/4-bpp-djvu apply the color palette you just built yourself, and zoom to 300dpi.
Other than the screen backlight which you've taken care of when you held both devices side-by-side and played with the sliders, there's no substantial difference left.
Should be pretty representative.
Don't look with too much of a magnifying glass though the phone doesn't have exactly the same dpi so there are resampling artifacts your eyes resolve if you're too close to it.
https://www.cve.org/CVERecord?id=CVE-2007-0882
Might be a 32 year old bug, but it's practically also a 19 years old exploit?
Ed: I'm confusing TFA with
https://nvd.nist.gov/vuln/detail/cve-2026-24061
Which seems pretty much identical with the 2007 cve.
reply