A recurring do-it-yourself project takes articles from RSS subscriptions and renders them onto an e-ink display or a printed sheet, so reading happens on a single-purpose surface instead of a phone that also carries notifications.
Key takeaways
- The core idea is straightforward: pull items from RSS or Atom feeds, filter them down to a manageable set, and render the result as a static page for an e-ink screen or a printed sheet.
- E-ink is chosen because it refreshes slowly and has no backlight, which makes it poor for interactive browsing and therefore useful as a deliberate constraint.
- Most builds share the same three stages — fetch, curate, render — and the differences between them are mostly in which tools fill each stage.
- A batch-oriented “daily edition” is the defining feature, because it removes the pull-to-refresh loop that makes phone reading hard to stop.
- The approach has real limits: it handles text well, images and video poorly, and it requires ongoing maintenance when feeds break or disappear.
- Anyone can approximate the outcome without hardware by generating a print-ready page from the same feeds and printing it.
What is actually being built here
The project described by this kind of post is a small personal publishing pipeline. Instead of reading feeds in an app, the reader runs a program on a schedule — often once a day, early in the morning — that visits every subscribed RSS or Atom feed, collects the new items, and assembles them into a single document. That document is then pushed to an e-ink device, or sent to a printer, or saved as a file that a dedicated reader picks up.
The output deliberately looks like a newspaper: a fixed set of stories, in a fixed layout, with no way to scroll into an endless tail. Once the edition is generated, it does not change until the next run. That fixed quality is the point. A phone feed reader always has more to show; a printed or rendered edition ends.
Three stages appear in almost every version of this build. The first is fetching, where a script or an existing feed aggregator reads the subscription list and pulls new entries. The second is curation, where the raw pile is trimmed — by feed, by keyword, by recency, or simply by taking the first few items from each source. The third is rendering, where the surviving items are laid out as HTML, then converted to an image or a PDF sized precisely to the target screen or paper.
Why this keeps surfacing now
Interest in single-purpose reading devices has grown alongside broader unease about phone use. E-ink hardware has also become easier to obtain: bare display panels, e-reader devices that can run third-party software, and small screens intended for hobbyist electronics are all more widely available than they once were, and the software libraries for driving them are more mature.
At the same time, RSS has stayed alive as a quiet standard. It never regained mainstream visibility, but it remains widely supported by blogs, news sites and content management systems, which makes it a stable foundation for a project like this. The specific number of publishers still offering feeds is not something that can be stated precisely, and it varies a great deal by category — many large outlets do, some do not.
What tends to make an individual project post spread is not novelty of concept but the fact that someone finished one and documented the details. The discussion that follows usually turns into an exchange of alternative approaches rather than a debate about whether the idea works.
The background a newcomer needs
RSS, and its close relative Atom, are formats that let a website publish a machine-readable list of its recent items: title, link, date, and often a summary or the full text. A feed reader subscribes to that list and checks it periodically. Nothing about the format requires an app — it is just structured text over the web, which is why it is easy to script against.
E-ink, or electronic paper, works by moving pigment particles to form a static image that stays on screen without power. It is high-contrast in ambient light and does not emit its own, which is why it is comfortable for long reading. The trade-off is refresh speed: updates are slow and often involve a visible flash, and colour support, where present, is limited compared with an LCD or OLED panel. Those weaknesses are precisely why the medium suits a fixed daily edition rather than live browsing.
The third piece of background is layout. Converting a web page to a fixed-size image is a solved problem in general terms — headless browsers can render HTML and capture the result — but getting good typography at a specific pixel dimension, in greyscale, without pagination artefacts, is where most of the fiddly work in these projects lives.
Who this suits and who it does not
The clearest fit is a reader who already maintains a feed list, reads mostly text, and wants a defined stopping point. For that person, the payoff is not technical elegance but the change in reading behaviour: the edition is finite, so the session ends.
It suits people who are comfortable running a scheduled script on a machine that stays on — a home server, a small single-board computer, or a laptop that wakes on a timer. Cloud-hosted variants exist, but they add account management and cost.
It fits poorly for readers who follow visual publications, video channels, or anything where images carry the meaning. Greyscale e-ink flattens photographs, and many feeds provide only a headline and a stub of text, which produces an edition full of teasers rather than articles. It also fits poorly for anyone who needs to read breaking news, since the whole design is built around batching.
There is a maintenance cost that is easy to underestimate. Feeds move, get discontinued, change from full text to summary, or start including boilerplate that has to be stripped. A pipeline that works perfectly on the day it is built will need attention over months.
Where informed people disagree
The most common disagreement is whether hardware is necessary at all. One camp argues that the behavioural benefit comes from batching and finiteness, not from the display technology, and that printing to paper or generating a single static file achieves the same result with far less effort. The other camp holds that a device with no browser and no notifications is what actually breaks the habit, and that a file on the same phone will simply be read on the phone.
A second split concerns build-versus-buy. Existing self-hosted feed readers, read-later services and e-reader send-to-device features already cover much of this ground, and some argue a custom pipeline is effort spent re-solving solved problems. Others value the control: exact layout, exact selection rules, no dependence on a service that might change.
A third area of disagreement is full-text extraction. Pulling the complete article from a summary-only feed makes the edition far more useful, but it works against the publisher’s chosen distribution and can break unpredictably when page structures change. Practices here vary, and there is no settled consensus.
What this means in practice
If you want to try the minimum viable version, start without hardware. Take your existing feed list, export it as an OPML file from whatever reader you use, and write or adapt a script that fetches those feeds, keeps items from the last day, and renders them into one HTML page with print styles. Print it or read it as a PDF for a week. That test tells you whether batching is the part that helps you.
If it does help, the hardware decision follows from your reading volume. A small panel suits headlines and short posts; a larger e-reader-class display suits full articles. Whatever you choose, confirm before buying that the device can be driven by software you control, since that is the constraint that most often stops these projects.
Two design choices matter more than the rest. Decide how many items per feed you will allow, because an unbounded edition recreates the problem you set out to solve. And decide what happens to items you did not read: discarding them keeps the edition fresh, while carrying them forward slowly rebuilds a backlog.
What to watch next
Watch whether feed availability holds up, particularly as more publishers move content behind sign-in walls or shift distribution to newsletters and apps. Watch the hardware side, where wider availability of hobbyist e-ink panels and more open e-reader firmware would lower the barrier for this kind of build.
Also worth watching is whether any of the existing self-hosted feed readers add a first-class daily-edition output. That feature — a batched, fixed, exportable edition — is the part these do-it-yourself projects keep rebuilding, and it is the part most readily turned into a standard option.
Frequently asked questions
Do I need an e-ink device to make this work?
No. The batching behaviour — a fixed set of articles, generated once, with no refresh — can be achieved by rendering your feeds to a PDF or printing them on paper. An e-ink device adds the benefit of a screen with no browser or notifications, which some people find necessary and others do not. Testing the paper version first is a low-cost way to find out which group you fall into.
What is RSS and is it still supported?
RSS is a format that lets a website publish a machine-readable list of its recent posts, including titles, links and often summaries. Atom is a similar standard used interchangeably in most tools. It remains widely supported by blogs and content management systems, and by many news sites, though support varies by publisher and cannot be stated as a precise figure. Its longevity is the main reason projects like this remain feasible.
Can I get full articles rather than just summaries?
Sometimes. Some feeds publish the complete article text, in which case nothing extra is needed. Others publish only a headline and a short summary, and getting the full text means fetching the linked page and extracting the body, which is technically possible but breaks when sites change their structure. It also runs against how some publishers intend their content to be distributed, so views on the practice differ.
How often should the edition be generated?
Once a day is the most common choice, because it mirrors a newspaper and creates a clear reading slot. Some people prefer twice daily for higher-volume feeds, or weekly for slower ones. The key variable is not the interval itself but whether it is fixed: a schedule you cannot trigger early is what removes the refresh habit, so on-demand generation tends to undermine the purpose.
What hardware do people typically use?
Builds vary widely. Common ingredients include a small always-on computer to run the fetch-and-render job on a schedule, and a display target that is either a bare e-ink panel driven by hobbyist electronics or an e-reader that accepts files from software you control. Specific models and their capabilities change frequently, so check current compatibility before buying rather than relying on older project write-ups.
How much maintenance does a setup like this need?
Expect ongoing but light upkeep. Feeds get discontinued or move, some switch from full text to summaries, and layouts occasionally break when a source changes its formatting. The rendering step needs adjustment if you change display size. None of this is difficult individually, but a pipeline left untouched for a year will usually have accumulated several dead or degraded sources.
Sources and further reading
- Public technical documentation for the RSS and Atom feed specifications, which define the structure these projects parse.
- Manufacturer and industry technical material on electrophoretic display technology, covering refresh behaviour, contrast and colour limitations.
- Community discussion threads on programming and technology forums, where builders compare pipelines and report failure modes.
- Documentation for open-source self-hosted feed readers and headless browser tools, which describe the fetching and rendering steps in general terms.
Surfaced from the hackernews signal “a DIY e-ink feed reader”. AI-assisted draft, editorially reviewed.
