Plugin idea: CV and letter template packs and extra document renderers #1255

New issue

Open

opened 2026-11-13 10:51:53 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-11-13 10:51:53 +00:00

Owner

Idea

Documents are drawn by themes and renderers (documents/themes, the Europass plugin, the postulo-templates repository). A person or an organisation could ship a template pack (country styles, sector styles, accessible variants) or a renderer (a different output: plain text for an online form, a JSON Resume, a LaTeX source, an ODT) as a plugin.

What to settle

The kinds: a theme pack (styles and layouts only, data in, document out) and a renderer (new output format); which of the two exists in the plugin API today and what is missing (read the postulo-templates plan and the Europass plugin first).
How a pack declares the countries and languages it suits, so the picker can suggest the right one (see #1251 and #1250).
Accessibility of the output (tagged PDF, reading order) as a published check every pack passes.

Wanted

A written gap analysis against the current plugin surface, then the missing kind or hook as a separate issue, and one reference pack.

Rules that apply to every plugin

Off until the person enables it; a plugin that calls a service names the host and the data it sends in its manifest and on the consent screen (plugins/consent.py); nothing is fetched on page load.
Core keeps no import of it: the application runs with it absent, and data it created stays readable as plain data when it is removed.
The plugin surface (plugins/api.py, the published postulo.plugins.testing check) gets a contract test for any new kind; the plugin ships its own translation catalogues (the plugin locale rule); strings go through Weblate only.
Its own repository if it is not bundled (see the plugin repositories and #1170's shared CI).

Filed as an idea after a discussion on plugin kinds, with #1252 (reference data and lookups as plugins). Not started; the maintainer decides if and when.

## Idea Documents are drawn by themes and renderers (`documents/themes`, the Europass plugin, the postulo-templates repository). A person or an organisation could ship a **template pack** (country styles, sector styles, accessible variants) or a **renderer** (a different output: plain text for an online form, a JSON Resume, a LaTeX source, an ODT) as a plugin. ## What to settle - The kinds: a *theme pack* (styles and layouts only, data in, document out) and a *renderer* (new output format); which of the two exists in the plugin API today and what is missing (read the postulo-templates plan and the Europass plugin first). - How a pack declares the countries and languages it suits, so the picker can suggest the right one (see #1251 and #1250). - Accessibility of the output (tagged PDF, reading order) as a published check every pack passes. ## Wanted A written gap analysis against the current plugin surface, then the missing kind or hook as a separate issue, and one reference pack. ## Rules that apply to every plugin - Off until the person enables it; a plugin that calls a service names the host and the data it sends in its manifest and on the consent screen (`plugins/consent.py`); nothing is fetched on page load. - Core keeps no import of it: the application runs with it absent, and data it created stays readable as plain data when it is removed. - The plugin surface (`plugins/api.py`, the published `postulo.plugins.testing` check) gets a contract test for any new kind; the plugin ships its own translation catalogues (the plugin locale rule); strings go through Weblate only. - Its own repository if it is not bundled (see the plugin repositories and #1170's shared CI). Filed as an idea after a discussion on plugin kinds, with #1252 (reference data and lookups as plugins). **Not started; the maintainer decides if and when.**

tiagoagueda added the

enhancement

label

2026-11-13 10:51:53 +00:00