Converter: Collabora convert-to driver — drop Gotenberg on Collabora-equipped deployments #631

New issue

Closed

opened 2026-09-20 21:21:04 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-20 21:21:04 +00:00

Owner

Follow-up from #629. The office→PDF step for previews always needs a LibreOffice engine, but it does not need to be a separate one: Collabora Online exposes a convert-to endpoint (POST /cool/convert-to, multipart, format=pdf) backed by the same LibreOffice core it uses for editing. Deployments that run Collabora for the editing story (office.url) can then run zero Gotenberg — one service covers editing and office heroes.

Scope:

internal/preview gains a second driver next to the Gotenberg-compatible one. Selection: explicit preview.converterKind: "gotenberg" | "collabora" in config (defaulting to gotenberg for compatibility), OR — nicer — a documented convention that preview.converterUrl pointing at a Collabora origin uses convert-to (sniff on first use via discovery, cache the answer). Decide at build time; explicit config is the safer default and matches the "config = how to find your services" line.
Request shape: multipart field data (Gotenberg uses files), target format in the URL path or format field per Collabora's API; response is the PDF body either way, so /api/v1/preview/pdf and everything above it are unchanged.
Docs: deployment.md gains the three honest converter postures — none (PDF/image/text heroes only), Collabora only (editing + office heroes, one service), Gotenberg (office heroes without an editor) — and the homelab dogfood can dogfood the Collabora path since code.c0rdyceps.ch already runs.
Test: unit tests against a recorded convert-to exchange; live interop against CODE on the runner as a manual-dispatch workflow (the interop-rclone.yml pattern).

Not in scope: convert-to's PNG output (heroes rasterize client-side per #629), any converter UI beyond the existing admin health row.

Build after pane v2 slices land.

Follow-up from #629. The office→PDF step for previews always needs a LibreOffice engine, but it does not need to be a *separate* one: Collabora Online exposes a `convert-to` endpoint (`POST /cool/convert-to`, multipart, `format=pdf`) backed by the same LibreOffice core it uses for editing. Deployments that run Collabora for the editing story (`office.url`) can then run **zero Gotenberg** — one service covers editing and office heroes. Scope: - `internal/preview` gains a second driver next to the Gotenberg-compatible one. Selection: explicit `preview.converterKind: "gotenberg" | "collabora"` in config (defaulting to gotenberg for compatibility), OR — nicer — a documented convention that `preview.converterUrl` pointing at a Collabora origin uses convert-to (sniff on first use via discovery, cache the answer). Decide at build time; explicit config is the safer default and matches the "config = how to find your services" line. - Request shape: multipart field `data` (Gotenberg uses `files`), target format in the URL path or `format` field per Collabora's API; response is the PDF body either way, so `/api/v1/preview/pdf` and everything above it are unchanged. - Docs: deployment.md gains the three honest converter postures — none (PDF/image/text heroes only), Collabora only (editing + office heroes, one service), Gotenberg (office heroes without an editor) — and the homelab dogfood can dogfood the Collabora path since code.c0rdyceps.ch already runs. - Test: unit tests against a recorded convert-to exchange; live interop against CODE on the runner as a manual-dispatch workflow (the `interop-rclone.yml` pattern). Not in scope: convert-to's PNG output (heroes rasterize client-side per #629), any converter UI beyond the existing admin health row. Build after pane v2 slices land.