Why some PDF planners crawl on an e-ink tablet, and what a fast one looks like inside
Slow page turns are usually the file, not the tablet. Here is what a PDF costs an e-ink reader to draw, measured page by page on a 468-page planner, plus how to judge a file before you buy it.
· 6 min read
E-ink basicsBuying guides
A tablet that redraws a page in half a second with one planner and takes six seconds with another is not a broken tablet. Same panel, same processor, same firmware. The difference lives inside the file.
This is worth understanding before you buy a planner, because the thing that makes a PDF slow is invisible from a product listing. Two files can look identical in the preview images and behave nothing alike in your hand.
We build these files for a living, so we went and measured ours. Here is what an e-ink reader is doing when you tap.
The hardware you are asking to do the work
The processors in writing tablets are modest by design. Battery life measured in weeks does not come from a fast chip. What these devices have instead is a low-power ARM core doing a job that is not small: rasterizing a page at 226 to 300 dots per inch, which across the current lineup means somewhere between two and five million pixels.
It also has to do that from scratch on most page turns. There is no scrolling buffer to slide sideways. The page is drawn, then pushed to the panel, then the panel physically moves pigment around.
So the file is asking a small computer to do real work, several times a minute.
Three costs, and they fail differently
Lumping this into “the file is too big” hides what is going on. There are three separate costs and a file can be terrible at one while being fine at the others.
Opening the file. Before the first page appears, the reader parses the document’s object table, the index of every piece of content in the file. This is paid once. It scales with how many separate objects the file contains, which is loosely related to file size and not at all related to page count. This is the cost you feel as the pause after you tap the cover thumbnail.
Turning a page. The reader executes that one page’s drawing instructions and builds its list of tap targets. This is paid every single time, and it is the one people actually notice, because you do it hundreds of times a week. It depends on the complexity of that page alone. Nothing about the other 467 pages matters here.
The panel refresh. This part is physics, not software. E-ink displays have several refresh modes, and the fast ones only update pixels that changed. Large dark areas force the panel into a slower full refresh, the one that flashes black and back, because that is how it clears the ghost of the previous page. A planner with heavy black headers and filled boxes triggers that flash more often than one drawn in hairlines.
What we measured on our own planner
The file below is a full year for a Supernote Manta with every module switched on. It is the heaviest thing our generator produces.
| Pages | 468 |
| File size | 1.8 MB |
| Internal links | 9,065 |
| Drawing instructions, median page | 346 |
| Drawing instructions, heaviest page | 2,051 |
| Images | 0 |
| Page area under a dark fill | 0.3 % |
The number to look at is 346. That is how many operations the reader executes to draw a typical day page: set a line width, move to a point, draw a rule, show a string of text. A few hundred of those is a rounding error even on a low-power ARM core.
The heaviest page in the document is the year overview, at 2,051, because it prints twelve mini calendars and every day number in the year on one sheet. Even that one is comfortable. What matters more is that there is no third tier: after the year page, the next heaviest is 435. No page turn feels different from its neighbours, which is a property we now test for rather than hope for.
The 0.3 % dark fill is the tab rail’s active-tab marker, and it is deliberately the only filled shape on the page. Everything else is a line.
What makes a planner slow
Raster images. This is the big one, by a wide margin. Plenty of planners are built by designing pages in a graphics tool and exporting each one as a picture. The result looks right and behaves badly, because now every page turn is an image decode and a rescale rather than a few hundred line-drawing calls. It also means the text is not text, so your reader cannot search it, and zooming softens the letters instead of sharpening them. The tell is file size per page: an image-built planner runs into the hundreds of kilobytes per page, a drawn one lives under ten.
Enormous vector complexity. The opposite failure. Some PDFs, especially ones exported from CAD or mapping software, contain hundreds of thousands of tiny line segments per page. Vector content cannot be cached the way a decoded image can, so it gets redrawn at every zoom level you visit. Rare in planners, brutal when it happens.
Transparency and gradients. Soft shadows, translucent overlays, colour fades behind a header. These force the renderer through a compositing pass to produce something a one-bit panel then has to approximate with a dither pattern. You pay for an effect the screen cannot show you.
Heavy ink coverage. Back to the physics. Solid black bands and filled cells look sharp in a listing screenshot and cost you full-panel flashes in daily use.
Owner reports across the Boox and Kindle Scribe communities line up with all of this: the complaints cluster around image-heavy and scanned documents, and the same devices handle text-and-line documents of similar size without much fuss.
How to check a file before you buy
Two things, and neither takes long.
Divide the file size by the page count. This is a crude measure and a reliable one. A drawn planner is single-digit kilobytes per page. Ours is about 3.9 KB. Anything in the hundreds of kilobytes per page is built from images, and no tablet will make that fast.
Then load your free first month on the device you own. Not a phone, not a desktop preview, which will both be misleadingly quick. Turn pages back and forth for a minute, jump through a few links, and watch for one page that stalls when the others do not.
If a seller offers no sample for your specific device, that is its own piece of information.
What we do about it
We built a tool that scores our own files on this, and it runs on every build. It walks every page of a generated planner, counts the drawing instructions the reader will have to execute, measures how much of each page sits under a dark fill, checks that no link target has shrunk below a comfortable finger-tap size, and fails the build if the file has picked up anything an e-ink reader handles badly. Images, transparency, gradients, and a few older file-structure tricks are treated as defects rather than choices.
Every planner we generate scores in the nineties out of a hundred on that scale, and the two devices with the smallest screens score lowest, which is the honest result. Small panels mean smaller tap targets and thinner rules, and there is no getting around that with clever file structure.
None of this is exotic. A planner is text and lines on a page. Keep it that way and a decade-old processor draws it instantly.
Every planner Planned Pages generates is real text and vector lines, sized for your exact model, and your first month is free to try on your own tablet. Related: why planner links stop working and getting PDFs onto a Kindle Scribe without breaking them.