Add LFRM (Le Mans Arnage) customs form

[roznet]

Adds the airport-specific préavis douane for LFRM, and fixes a rendering bug in the shared PDF filler that it surfaced.

The form

lfrm.json + lfrm_customs.pdf, scoped to icao: LFRM, 4 crew / 7 passenger rows, routed to preavis-vols-douane-le-mans@douane.finances.gouv.fr cc codt-idf@… — the same routing the generic french_customs entry already used for LFRM. That generic form stays available as a second option for LFRM; no other airport's form list changes.

The template asks for Heure Locale, so the mapping declares time_reference: "local" with Europe/Paris.

Two quirks of the template are handled in the mapping rather than by re-authoring the PDF:

• the four tick boxes are text fields, not checkboxes, so they take an "X" via checkbox_on
• passenger rows are named …Row{n}_2 for rows 1–4 and plain …Row{n} for rows 5–7, which no single {n} pattern spans, so they use the filler's literal-index form

The filler fix

_fix_autosize_fields only rebuilt appearance streams for auto-size (0 Tf) fields. Fields with a fixed size were left alone even when that size overflowed a short box — pypdf then places the text baseline below the box and the value renders clipped.

This is already affecting LFQA in production: "Nature du vol: private" is cut off on every form generated today. Confirmed by rendering the current main output.

The function now rebuilds the appearance whenever the declared size doesn't fit, clamped to the box height, and additionally handles two things LibreOffice-authored templates do that the old code skipped: widgets whose /T lives on a parent field node, and fields with no appearance stream at all (previously left to whatever the viewer chose to draw).

Font sizes are read from the template, because filling rewrites an inherited auto-size /DA to a concrete 12 Tf on the field node — the same check against the filled document finds nothing.

Value-neutral: no existing snapshot changed; only the two new LFRM snapshots were created. The change is purely in how text is drawn.

Also in the filler

Three additions, none used by any existing mapping:

• local-time conversion when a mapping declares time_reference: "local"
• arrival.remote / departure.remote (+ _name, _country) for the Provenance / Aéroport / Pays triple, filled only on the side matching the flight direction
• | alternation on enum checkboxes (flight.nature.private|business). Without it, mapping two nature values to the same field would have the second silently overwrite the first with "off"

Testing

153 passed. The 2 flatten failures are pre-existing — verified they fail on a clean tree too.

Previews visually verified in both directions with self-describing values; ORIG/OriginCity/OriginCountry on arrival and DEST/DestCity/DestCountry on departure land in the right boxes, and only the active direction's column fills.

Note for review

The lower rows (Provenance / Aéroport / Pays / Nature du vol) render at ~7.6pt vs 12pt above, because those boxes are progressively shorter and sit slightly below their printed labels. Nothing is clipped and it's legible. Making those boxes ~14pt tall in LibreOffice would even it out — deliberately not done here as a re-export would discard any geometry edited outside the source document.

🤖 Generated with Claude Code

https://claude.ai/code/session_015cLZEJUmiCnbxfytMKN18e

[claude]

Code Review

Reviewed against designs/form-system.md (no repo-root CLAUDE.md exists in this repo). The mapping structure, registry resolution, and text-appearance fix all match the documented design. One correctness issue worth fixing before merge:

Local time can cross midnight without the paired date field following it — src/flightforms/fillers/pdf_filler.py:110-120

def _time(time_str, date_str):
if mapping.time_reference == "local" and mapping.time_zone:
return _utc_to_local(time_str, date_str, mapping.time_zone)
return time_str
...
local_date = request.flight.arrival_date if is_arrival else request.flight.departure_date
local_time = arr_time if is_arrival else dep_time

arr_time/dep_time are converted to local wall-clock time, but arrival.date/departure.date (and flight.date) still use the raw UTC-based date from the request, unconverted. For a flight where the UTC time is late evening, converting to Europe/Paris can roll the local time into the next calendar day (e.g. 2024-06-01 23:50 UTC -> 2024-06-02 01:50 local CEST), but the date field printed on the form stays 2024-06-01. This is exactly the field pair (ARRIVAL_DATE/ARRIVAL_LOCAL_TIME, DEPARTURE_DATE/DEPARTURE_LOCAL_TIME) that lfrm.json fills, and this is a customs pre-notification document, so a mismatched date+time is a real problem for flights near midnight UTC, not just cosmetic.

Since this is the first mapping to actually exercise time_reference: "local" in pdf_filler.py, this edge case has not been hit by any existing form. Suggest deriving the printed date from the same converted local datetime (e.g. have _utc_to_local also expose the local date) rather than reusing the UTC-based date string.

Everything else looks solid: the _fix_autosize_fields -> _fix_text_appearances change is well-scoped (font size read from template, box-height clamping, LibreOffice parent-node /T lookup, missing-/AP handling) and is documented as value-neutral with passing snapshots for existing forms; the | -alternation fix for enum checkboxes correctly addresses a real last-value-wins overwrite bug when two enum values map to the same box; lfrm.json follows the documented mapping schema (scope, email_overrides, literal-index person fields for the irregular Row{n}_2/Row{n} naming) and preview.py additions match the checklist in designs/form-system.md.

[roznet]

Good catch on the midnight roll — confirmed and fixed in 55bf449.

Reproduced on main: a flight arriving 23:50Z on 1 June printed ARRIVAL_DATE = 01/06/2026 against ARRIVAL_LOCAL_TIME = 01:50, a day out.

Fixed by converting each date/time pair together rather than exposing a local date from the time helper — same result, but it makes it structurally hard to convert one without the other, since the caller gets both back or neither.

One thing beyond what the review flagged: french_customs_filler.py has the identical defect, and unlike the new form it is already in production for the entire LF prefix. It converted dep_time/arr_time to local while departure_date/arrival_date stayed UTC-based. Fixed there too, and the conversion now lives in a shared fillers/_datetime.py instead of two copies that had drifted.

Regression tests added for three cases: the midnight roll, a same-day conversion that must not shift the date, and a UTC-reference form (lfqa) that must not convert at all.

157 tests pass; no existing snapshot moved.

[claude]

Code Review

Reviewed the LFRM form addition and the shared filler changes it surfaced. Overall solid: the appearance-stream fix is well targeted at the described LFQA clipping bug, _datetime.py correctly converts date+time together (with good regression tests for the midnight-roll case), and the LFRM mapping's row-naming quirks match what the snapshot fixtures show. No logic bugs found in the diff.

Two minor gaps worth a follow-up (not blocking):

1. No test coverage for _fix_text_appearances/_template_font_sizes (pdf_filler.py). This is the actual fix for the motivating bug (clipped "Nature du vol" text), but nothing in the suite exercises the sizing/skip logic or the new "build appearance stream from scratch" path — the snapshot tests only assert field /V values, not rendered font size or appearance stream contents. A unit test asserting the computed font size for a too-tall fixed-size field (and that a field within bounds is left untouched) would catch regressions here that snapshots can't.

2. designs/form-system.md wasn't updated for this PR: the "Current Form Inventory" table doesn't list lfrm, and the "Canonical Field Names" section doesn't mention the new arrival.remote/departure.remote (+ _name/_country) fields added to the filler's vocabulary.

🤖 Generated with Claude Code