Parchment: a warm-paper Android PDF reader built with Compose

The reading surface Parchment is trying to build

Parchment is an Android PDF reader whose argument is about feel rather than features. The description calls it a production-grade reader with a Warm Paper aesthetic and a gesture-driven interface, and the README frames it as a response to digital readers that feel cold and industrial. The intended user is someone holding a phone, reading offline, who wants the page to behave like paper rather than like a document viewer. Privacy is part of the pitch rather than a footnote: the acknowledgements section states zero network calls, zero analytics and no tracking, and the whole app is released under Apache 2.0. The audience is narrower than the phrase production-grade implies. This is a single-screen reading app for books the developer bundled into the APK, not a document management system with an import pipeline.

How a page becomes a bitmap on the screen

The rendering path is short and entirely native. PdfUtils copies a bundled asset into the cache when needed and returns a FileDescriptor, PdfViewerScreen initialises the platform PdfRenderer, and PdfPageRenderer opens pages one at a time, receives a bitmap at twice the base resolution and applies a night mode filter to it before display. The README describes this lifecycle as targeting a sub-100ms time to first page, and the super-sampling exists so that the VerticalZoomBar, a custom Canvas based scaling controller, can magnify text without turning it to mush. Rendering happens page by page inside a loop, which is where a long document starts to cost you: every page bitmap stays alive for as long as the screen holds on to it, and PdfPageRenderer is described in the module guide as the native to bitmap bridge with memory management.

Three layers and the classes that sit inside them

The architecture is a strict modular layered one. MainActivity hosts PdfViewerScreen, which reaches down to BookRepository and ReadingPreferences in the domain layer, and BookRepository resolves a BookConfig model that points at PDF assets in the data layer. The stated goal is full cohesion and zero coupling between the rendering engine and the data source, so that a different book source could replace the bundled assets without touching the renderer. Four components carry most of the weight. PdfViewerScreen orchestrates navigation and HUD states, VerticalZoomBar is the Canvas based scaling controller, PdfPageRenderer is the native to bitmap bridge, and BookRepository is the single source of truth for all book metadata. The docs/ directory is where the deeper architectural notes live, and the source tree is organised feature first, with data, ui and utils packages under the reader module.

Building and testing the app on your own machine

The development setup is documented precisely: Android Studio Ladybug or newer, JDK 17, SDK 36 as the target and 28 as the minimum. Two Gradle tasks do the work, and the README gives them as the build and verify commands:

./gradlew assembleDebug  # Build
./gradlew test           # Verify

The first task produces a debug APK, the second runs the unit test suite, and both are reachable from the gradlew wrapper that ships in the repository root. Continuous integration mirrors that shape on every push and pull request: a linting check runs first, then the debug build, then the unit tests, and only a green run is marked ready to merge while a failure notifies the maintainer. That pipeline is drawn as a workflow graph in the README, so the order of the gates is visible before you clone anything.

Gestures, the auto-hiding HUD and the remembered place

The interaction model is gesture first, and each piece has a named mechanism behind it. The Smart HUD hides itself so the page can sit alone on the display, the table of contents is driven by a flexible TocItem model, and page movement runs through a LazyColumn with haptic feedback loops so you can feel progress without looking down. ReadingPreferences is synchronised through a SharedPreferences layer, which is what keeps your place in the text when you leave the app and come back. A vertical zoom bar drawn directly on a Canvas gives finer control than a pinch gesture alone, and the design tokens are a custom HSL tailored system rather than stock Material colours, so the Warm Paper palette is applied consistently rather than hand tuned per screen. These are small choices, but they are the entire argument of the project.

Where Parchment stops short

The boundaries are concrete rather than philosophical. There is no documented import flow: PDF documents live in the app's assets and BookConfig points at them, so the reader as shipped opens the books the developer bundled, not a library of your own. There is also no text layer to work with, because every page arrives as a bitmap from PdfRenderer, so text selection, in-document search and screen reader support are not among the capabilities the README describes. No cloud sync, no DRM, no annotation tools and no OCR for scanned pages appear anywhere in the documentation. The project also publishes no tagged builds, so getting the app onto a phone means building it yourself and keeping it current means repeating that step.

Parchment next to a full featured PDF reader

The alternative approach is the one used by general purpose Android readers: a Pdfium backed engine with a text layer, a document picker that imports arbitrary files from storage, bookmarks that sync to an account, and an annotation model on top. The difference in approach is not polish, it is scope. Parchment drops the document picker, the text layer, the account system and the sync backend, and in exchange you get a single-purpose surface that runs with no permissions, no network traffic and a fixed catalogue of bundled books. A Pdfium based reader wins when the file on your phone is the thing you care about. Parchment wins when the document set is curated, the connection is unreliable, and reading privately matters more than managing files.

Licence, pipeline and the state of the repository

Parchment is licensed under Apache 2.0, with a LICENSE file in the root and a matching badge in the README, and that licence allows commercial use and modification provided its notice and attribution conditions are met, though how those conditions map onto your own product is a question for your own counsel. The last push was on 2026-06-30, the repository is not archived, and the project publishes no GitHub releases, so CHANGELOG.md is the only record of what changed between versions and an update means pulling the main branch yourself.

Editorial conclusion

Parchment suits a developer or reader who wants to read a fixed set of bundled documents on a phone, offline and without telemetry, and who is prepared to build the app from source. It does not suit anyone who needs to open arbitrary PDFs from device storage, search inside a document, or sync a library across devices, because the rendering path produces bitmaps and the repository publishes no builds. Before adopting it, check the Android version range against your own devices, read the LICENSE file to confirm the Apache 2.0 terms match your intended use, and decide whether the bundled book set is the whole point or a placeholder.

Frequently asked questions

Official sources

1. AhmadHassan-BTed/Parchment on GitHub
2. Issues
3. License: Apache-2.0
4. README