4e2685cdad
A review of the full-detail packet, page by page: - Page 1: a poster carries its own title, so the packet's title above it printed two headers and shrank the map to fit beneath them. A poster sheet now fills the page inside the white margin by itself; in another language its kicker and title become the packet's own, fitted to the English width. A map-only sheet keeps the packet's title in the band it leaves empty. - The life calendar is laid out like the Module 1 "Life Calendar in Weeks": square boxes, week numbers across the top, the year down the side, a rule between decades, framed and centred. The first 33 years are shaded as the life of Jesus (1,716 weeks). - The %-evangelical grid fills from the top in reading order instead of scattering. - The flow pages had no page padding at all, so their headings sat on the sheet's edge; they keep the same margin as every other page now. - The bounded and centered sets are one page, two square panels side by side as on the Module 1 list of 100, each headed by name with a cross at its centre. The centered set is a target of nine numbered bands, its dots spread through their bands by the shared ringBands geometry (no overlaps, none on the numbers), and the legend explains every ring with its count. - The lightweight packet lists every group as a worksheet: a short note, one column header per page, numbered rows sized for paper with room to tick, no photos or descriptions. Seven new strings in all eleven languages. check:packet-a1-structure and check:packet-variants assert the new contract two-sided (a poster page 1 has one header, a map-only page 1 still has the packet's; every ring is named, a populated one with its count and an empty one with a dash). |
||
|---|---|---|
| .. | ||
| api | ||
| charts/whiteboard | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| dashboards | ||
| data | ||
| elements | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| packets | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| vendor/cldr | ||
| index.js | ||
| ProfileLoader.vue | ||
| README.md | ||
library/ (@map) — the shared map template
The other half of the architecture (see ../plugin-designs/README.md):
every map in plugin-designs/<your-map>/ composes the reusable, parameterized pieces that live here.
Fix something here and every map benefits on the next build; break something here and every map
breaks — read components/WARNING.md before touching shared pieces.
| Folder | What lives there |
|---|---|
ProfileLoader.vue |
The root of every bundle: parses profile-config, loads the profile, provides the stores + config |
components/ |
Shared UI — map, legends, controls, popup (PeopleGroupDetail), tables, charts, hints (README) |
composables/ |
Shared logic — map engine (useMapInstance), provider switch, shadow-DOM styles, theming |
stores/ |
Per-instance Pinia stores (ui / map / data) — provided by ProfileLoader, injected by children |
api/ |
Data-source registry (sources.json) + fetch layer — the JAMstack runtime wiring |
colors/ |
Color sets maps opt into via profile-config.colorSet |
i18n/ |
The shared string catalogs (all maps speak the same languages) |
data/ |
Small shared datasets baked at build time (big served data lives in ../data/) |
constants/ |
Shared constants |
scripts/ |
Maintainer pipelines (posters, research) — not part of any bundle |
The rule of thumb (same as WARNING.md): custom code in your app-profile, reusable code here — and things only move from the first to the second once they've earned it.