Trevor PaughSystems engineer
Trevor PaughProject Chronicles

Chronicles / Eboda Gymnast

My own Acrobat

Milestone

A new project, planned and started in one day. The owner wants a personal Windows replacement for Adobe Acrobat: read, fill forms, edit text on the page, sign, rearrange pages, with full feature parity as the long ambition. Seven phases were planned, one mockup round was accepted without notes, the repository was created, and the first slice, a desktop shell with a PDF reader, was built, reviewed, and merged before the day ended. The stack was chosen for portability and licence freedom.

No trigger, the owner said: just because. The want is simple to state and long to build: one tool they own that does what Acrobat does, starting with the three verbs read, edit, and sign, and growing from there. The pull quote sets the ceiling.

Who it is for

The owner first, a technical Windows user who does not want telemetry or a subscription. Then the handful of people the owner might hand it to, who must be able to install it and open a PDF without being told anything. Nobody pays. The documents are the four kinds people actually edit: government and business forms, exports from word processors, scanned paper, and designed documents with custom fonts.

The decisions

Three choices came out of the planning conversation, each from a question the owner asked or a line the owner drew.

The shell is Tauri with a Rust core, over a native Windows toolkit, because the owner asked what would make it easiest to port to Mac and Linux later. The rendering engine is PDFium, under a permissive licence, over the copyleft engines, so the project can go open source or stay closed without rework. And everything in it is free: “No, all free and open components.”

One behaviour was decided before any code: a text edit whose font is not on the machine is refused until the owner picks one, and the picker helps, proposing the exact or closest font by name and then by style. In the owner’s words, “Refuse to edit until I choose a font and it should offer some assistance in selecting the closest or exact font available.”

In-place text editing is the hard part. The research found no free library that does it, so that will be custom work.

The day

Planning ran through seven phases and one mockup round, accepted with no notes. The repository was created, a manager and team stood up, and the first slice, the desktop shell with a working reader, was built and put up for review the same day. Saves will go through a temporary file that is reopened and checked before it replaces the original, so a save can never corrupt a document.

Slice one, merged

The reader merged the same evening. The shell opens, scrolls, zooms, and thumbnails PDFs through the engine, and remembers the last page and zoom per file. The plan ordered the slices riskiest first, and this one answered the first risk: the engine, driven from Rust inside the shell, renders the owner’s real documents in tens of milliseconds a page.

Review found four things to fix before merge, all applied that evening: the engine’s fetch script failed on Windows paths, the embedded browser view still answered its own keyboard shortcuts and right-click menu, the engine’s third-party licence notices were not bundled, and the recent-files commands blocked the interface. The second of those came from a rule the owner set at planning, “Tools not available should stay hidden until they are”: a print shortcut would have printed the interface itself before print exists. Next slice: editing text in place.