The product problem
A PDF preserves a printed layout, but it does not always provide a comfortable experience for reading a novel for hours. Lector reconstructs prose while retaining the connection to the original document and keeping the library, notes and progress on the reader’s device.
Architecture built around continuity
- Ingestion separate from reading: PDF.js extracts the document; a pipeline analyzes lines, columns, paragraphs and chapters before producing a reading model.
- Stable positions: progress is anchored to a text offset. Changing font size, presentation or reading mode should preserve the reader’s place.
- Explicit Electron boundaries: the renderer accesses the system through a minimal preload and IPC operations validated in the main process.
- Recoverable persistence: atomic JSON writes, per-path queues and data validation. The original PDF remains the source of truth; processed text is a rebuildable cache.
Local processing and background tasks
OCR, search, dictionary and speech run locally. Per-book tasks use session tokens and cancellation to discard late results after another document is opened. This prevents a background operation from updating the wrong book.
Verification and status
The repository includes contract tests, extraction fixtures and Electron journeys for reading, persistence and visual experience. The Windows distribution is a public preview, not a signed stable release. Desktop currently supports PDF.
The Android evolution is being developed as a separate product, using Kotlin, Jetpack Compose and PDF/EPUB support through Readium. It is not yet published on Google Play. This does not imply EPUB support on desktop or availability on every platform.
What this project demonstrates
Product design also means handling an app closing during a write, switching books during OCR or reopening damaged data. Lector focuses my work on architecture, privacy and reading continuity alongside interface design.