Export a catalogue record as a PDF (offline backup + printable copy) #39

New Issue

2026-06-05T11:46:20Z

logaritmisk commented

2026-06-05 11:46:20 +00:00

Motivation

Curators need a durable, human-readable copy of a catalogue record — both as an
offline backup (store on HDD/DVD/external media, independent of the running
system) and as a printable sheet for a physical archive. A PDF fits both: it's
self-contained, archival, printable, and doesn't require the app to be online.

Scope (v1)

Export a single catalogue object (/objects/:id) as a PDF.
Out of scope (file as follow-ups): bulk / whole-collection export, scheduled
backups, ZIP-of-PDFs, embedded images/media (no media subsystem yet).

What the PDF should contain

Header: product name (app_name from config — never hardcoded) + object
number + visibility.
Core fields: object_name, object_number, number_of_objects, brief_description,
current_location, current_owner, recorder, recording_date.
Flexible fields: each field definition's localized label + value, with
term/authority values resolved to human-readable labels (not raw UUIDs)
and localized_text rendered per language.
Footer: generation timestamp; optionally a record id for provenance.
Self-contained: no external fetches, so it's a valid offline backup.

Open design questions (resolve in brainstorm before implementing)

Where to render: backend endpoint (e.g. GET /api/admin/objects/{id}/export.pdf
— server-rendered, deterministic, scriptable for batch backup, reachable from a
future CLI) vs. frontend (print-styled detail view → browser "Save as PDF" — zero
new deps, simpler, but less deterministic/automatable). The backup use-case
leans backend; print is satisfied by either. Likely: backend endpoint + a
frontend "Export PDF" button that hits it.
PDF library (if backend): Rust options — typst (lib; modern typography),
genpdf/printpdf (pure-Rust, lower-level), or HTML→PDF via headless Chromium
(heavy runtime dep — probably avoid given self-host is a first-class target).
Auth/visibility: which capability gates export (likely ViewInternal).
Language: single language with a selector, or a bilingual (sv/en) sheet.
Layout/branding: plain catalogue-card vs. a designed template / letterhead.

Acceptance (v1)

A curator can export any object they can view as a well-formed, self-contained PDF
containing the core + resolved flexible fields, with product name + object number.
Reachable from the object detail UI (an "Export PDF" action), and — if backend —
via a stable endpoint.

Follow-ups (separate issues when this lands)

Bulk export (selection / whole collection) as individual PDFs or a combined doc/ZIP.
Scheduled/automated backup export.
Embed media/images once a media subsystem exists.

Filed at the user's request — a PDF export feature for record backup + physical printing.

## Motivation Curators need a durable, human-readable copy of a catalogue record — both as an **offline backup** (store on HDD/DVD/external media, independent of the running system) and as a **printable sheet** for a physical archive. A PDF fits both: it's self-contained, archival, printable, and doesn't require the app to be online. ## Scope (v1) - Export a **single** catalogue object (`/objects/:id`) as a PDF. - Out of scope (file as follow-ups): bulk / whole-collection export, scheduled backups, ZIP-of-PDFs, embedded images/media (no media subsystem yet). ## What the PDF should contain - **Header:** product name (`app_name` from config — never hardcoded) + object number + visibility. - **Core fields:** object_name, object_number, number_of_objects, brief_description, current_location, current_owner, recorder, recording_date. - **Flexible fields:** each field definition's localized label + value, with `term`/`authority` values **resolved to human-readable labels** (not raw UUIDs) and `localized_text` rendered per language. - **Footer:** generation timestamp; optionally a record id for provenance. - **Self-contained:** no external fetches, so it's a valid offline backup. ## Open design questions (resolve in brainstorm before implementing) 1. **Where to render:** backend endpoint (e.g. `GET /api/admin/objects/{id}/export.pdf` — server-rendered, deterministic, scriptable for batch backup, reachable from a future CLI) vs. frontend (print-styled detail view → browser "Save as PDF" — zero new deps, simpler, but less deterministic/automatable). The *backup* use-case leans backend; *print* is satisfied by either. Likely: backend endpoint + a frontend "Export PDF" button that hits it. 2. **PDF library (if backend):** Rust options — `typst` (lib; modern typography), `genpdf`/`printpdf` (pure-Rust, lower-level), or HTML→PDF via headless Chromium (heavy runtime dep — probably avoid given self-host is a first-class target). 3. **Auth/visibility:** which capability gates export (likely `ViewInternal`). 4. **Language:** single language with a selector, or a bilingual (sv/en) sheet. 5. **Layout/branding:** plain catalogue-card vs. a designed template / letterhead. ## Acceptance (v1) - A curator can export any object they can view as a well-formed, self-contained PDF containing the core + resolved flexible fields, with product name + object number. - Reachable from the object detail UI (an "Export PDF" action), and — if backend — via a stable endpoint. ## Follow-ups (separate issues when this lands) - Bulk export (selection / whole collection) as individual PDFs or a combined doc/ZIP. - Scheduled/automated backup export. - Embed media/images once a media subsystem exists. _Filed at the user's request — a PDF export feature for record backup + physical printing._

logaritmisk referenced this issue

2026-06-05 13:16:50 +00:00

Frontend: render timestamps in the instance timezone (Intl), once there's a display #42

logaritmisk referenced this issue

2026-06-07 11:52:13 +00:00

Frontend UX: object detail renders term/authority/localized values as raw JSON #45

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: logaritmisk/biggus-dickus#39