@openpresentation/opf 0.17.0 → 0.18.1

package/dist/repo-readme.js

@@ -1,5 +1,5 @@
 // src/generated/repo-readme.ts
-var repoReadmeRaw = '# Open Presentation Format (OPF)\n\n[![npm version](https://img.shields.io/npm/v/@openpresentation/opf?label=npm)](https://www.npmjs.com/package/@openpresentation/opf)\n[![npm downloads](https://img.shields.io/npm/dw/@openpresentation/opf)](https://www.npmjs.com/package/@openpresentation/opf)\n[![license](https://img.shields.io/npm/l/@openpresentation/opf)](./LICENSE)\n\nPublic npm package: [`@openpresentation/opf`](https://www.npmjs.com/package/@openpresentation/opf) (`npm install @openpresentation/opf`).\n\nOpen Presentation Format is the portable, human-readable JSON document format for slide decks.\n\nThis repository is the canonical home for the OPF **spec**, **JSON Schemas**, **catalog presets**, examples, generated developer types, local validation tooling, and integration docs for the render/edit/convert toolkit. OpenPresentation publishes open-source code and documentation only; it does not provide hosted APIs, hosted rendering functions, queues, storage, authentication, jobs, previews, SLAs, telemetry, or managed infrastructure.\n\nFor AI agents, use the [OPF skill set](docs/agent-skills.md) for authoring, layout, presets, editing, export, and schema inspection.\n\nPublished CLI 0.16.0 installs all six skills into your project with `npx @openpresentation/cli@0.16.0 skills install`. It uses local copies, preserves existing instructions and refuses to overwrite customized skills. See the [installation and update guide](docs/agent-skills.md) for personal or agent-specific targets and source development.\n\nFor a fresh Node 24 project that installs **published** packages (not this\ncheckout), follow the [developer quickstart](docs/quickstart.md) and the\n[compatibility matrix](docs/compatibility-matrix.md).\n\nFor LLM authoring, start with [the authoring guide](docs/llm-authoring.md), [dynamic composition](docs/dynamic-composition.md), and [local ecosystem verification](docs/ecosystem-development.md).\n\n## File naming\n\nOpen Presentation Format documents are JSON files. Use `*.opf.json` for complete OPF presentation documents, for example `board-review.opf.json` or `deck.opf.json`.\n\nAvoid using bare `*.opf` for OPF JSON. The `.opf` extension is already used by other document and project formats, while `.opf.json` keeps the OPF identity and still makes the underlying JSON format clear to editors, validators, agents, and version-control tooling.\n\n## Naming and reuse\n\nThe format name is **Open Presentation Format**. The schemas, catalogs, packages, and local tooling in this repository are free and open source under the MIT license, so third-party tools may read, write, validate, render, convert, and describe support for Open Presentation Format without adopting any product-specific branding.\n\n## Why OPF\n\n`.pptx` is a zipped bundle of XML. Humans can\'t diff it, LLMs can\'t read or write it reliably, and git can\'t track it meaningfully. Every change looks like a binary blob.\n\nOPF is plain JSON. A human can open it in an editor. A model can read and write it without guessing at schema-by-example. Decks live in git like the rest of your work.\n\nThat\'s the shift that lets LLMs actually *author* decks. When the format stops fighting them, models can do the work that matters \u2014 narrative structure, persuasive framing, data analysis, chart recommendations, ruthless revision passes \u2014 instead of wrestling with `<p:sp>` tags.\n\nAnd they don\'t start from a blank canvas. [pptx.gallery](https://pptx.gallery) is the human-browsable reference for OPF catalog presets: layouts, themes, color schemes, font schemes, chart types, narratives, audiences, purposes, tones, languages, and social platforms.\n\n## Start in three steps\n\n1. **Install the coordinated published packages** on Node 24. See [the developer quickstart](docs/quickstart.md) for the current pin set: core 0.16.0, renderer 0.16.0, editor 0.16.0, PPTX 0.16.1 and CLI 0.16.0.\n2. **Author, validate, paginate, preview and export.** Copy [`docs/quickstart/developer-quickstart.opf.json`](./docs/quickstart/developer-quickstart.opf.json) and run the commands in that guide. From code, `convert("deck.opf.md", "deck.pdf")` of `@openpresentation/opf/node` is the simple path to a PDF, PNG, SVG or PPTX file. `validate` / `opf validate` is one local checker for format, references, accessibility, layout and content ([guide](docs/validate.md)), not visual verification.\n3. **Know the limits.** The [compatibility matrix](docs/compatibility-matrix.md) lists shipped APIs versus renderer issue 24, native PowerPoint issue 87, and other deferred work. Browse presets at [pptx.gallery](https://pptx.gallery).\n\nYour deck can live in git from the first commit. After installing dependencies and supplying referenced assets, these commands run locally without a model provider, account or hosted OPF API.\n\n## JavaScript and TypeScript\n\nThe canonical JavaScript/TypeScript package is published at [`packages/javascript`](./packages/javascript) as [`@openpresentation/opf`](https://www.npmjs.com/package/@openpresentation/opf). The schema is pre-stable (0.x \u2014 expect breaking changes between minor versions until 1.0). Its responsibility is local and format-level only:\n\n- export the canonical schemas from [`spec/`](./spec)\n- export the pinned default catalog (the pptx.gallery snapshot in [`spec/catalogs/`](./spec/catalogs)) as the opt-in `@openpresentation/opf/catalog`, for hosts to register\n- export a typed raw spec file manifest for package-addressable `spec/` content\n- generate TypeScript types, with `Presentation` as the top-level type\n- validate OPF JSON and catalog records locally\n\nIts Node-only `@openpresentation/opf/node` entry reads and writes files (`convert`, `open`, `save`) and draws them through the optional engines below; the root and every other entry run in a browser. It does not generate content with AI, fetch remote catalogs, call hosted APIs, or provide managed services. Render/edit/convert packages live in separate MIT repos that depend on `@openpresentation/opf`. The format package also exposes pure composition geometry so those packages share layout behavior.\n\n## Toolkit libraries\n\nOPF is five packages. **Core** (`@openpresentation/opf`) is the format and its API: it reads and writes the text formats (JSON, YAML, Markdown) and validates, and `@openpresentation/opf/node` reads and writes files. **The CLI** (`@openpresentation/cli`) is the `opf` command. **Render** (`opf-render`), **PPTX** (`opf-pptx`) and **the editor** (`opf-editor`) are the engines: drawing, PowerPoint and editing, installed as needed. The engines and the editor live in sibling repositories. See [ecosystem development](docs/ecosystem-development.md) for coordinated builds and verification, and [dynamic composition](docs/dynamic-composition.md) for portable layout rules.\n\n| Repo | Role | Boundary |\n|---|---|---|\n| `cli` (`@openpresentation/cli`, this repository) | `opf` command | Runs core\'s `/node` engine: reads and writes files and calls the engines below as optional peers |\n| `opf-render` | OPF to SVG/PNG/PDF | Local and embeddable rendering library |\n| `opf-editor` | WYSIWYG bindings/components | Headless editor primitives plus optional UI components |\n| `opf-pptx` | OPF to PPTX and PPTX to OPF | Pure local import/export library for browser and server use where supported |\n\nThese repos provide OSS primitives only. Downstream applications own hosting, auth, storage, collaboration, queues, previews, analytics, support, and workflow UX.\n\n## Usage\n\nInstall from npm:\n\n```sh\npnpm add @openpresentation/opf\n# or: npm install @openpresentation/opf\n```\n\nTo work on the package itself, clone this repo and build the workspace:\n\n```sh\npnpm install\npnpm build\n```\n\nUse the format package from JavaScript or TypeScript:\n\n```ts\nimport { presentation, validate } from "@openpresentation/opf";\nimport { defaultCatalog } from "@openpresentation/opf/catalog";\n\nimport type { Presentation } from "@openpresentation/opf";\n\nconst deck: Presentation = {\n  name: "Quarterly Review",\n  slides: [{ title: "Quarterly Review", items: ["Revenue", "Product", "Hiring"] }],\n};\n\nconst report = validate(deck);\nconsole.log(report.valid); // no finding has severity "error"\nconsole.log(report.findings); // every finding: rule id, severity, category, JSON Pointer path, message, fixes\n// Core ships no catalog records in its main entry; a host registers the catalogs it trusts.\nconsole.log(validate({ ...deck, design: { theme: "classic" } }, { catalogs: [defaultCatalog] }).valid);\nconsole.log(Object.keys(defaultCatalog.audiences).length);\n```\n\nConvert, open and save files in Node with `@openpresentation/opf/node` (the engines `@openpresentation/opf-render` and `@openpresentation/opf-pptx` are optional peers, installed as needed; see [OPF files in Node](docs/node.md)):\n\n```ts\nimport * as opf from "@openpresentation/opf/node";\n\nawait opf.convert("deck.opf.md", "deck.pdf");\nconst deck = await opf.open("deck.opf.md");\ndeck.slides.push({ title: "Q4" });\nawait opf.save(deck, "deck.opf.md");\nconst { files } = await opf.convert(deck, { format: "pptx" }); // bytes, nothing written\n```\n\nUse focused imports when you only need one surface:\n\n```ts\nimport { presentation } from "@openpresentation/opf/schemas";\nimport { defaultCatalog } from "@openpresentation/opf/catalog";\nimport { specFileEntries } from "@openpresentation/opf/spec-files";\nimport { validate } from "@openpresentation/opf/validator";\nimport type { Presentation } from "@openpresentation/opf/types";\n```\n\nUse raw JSON when an engine or resolver needs package-addressable files:\n\n```ts\nimport presentationSchema from "@openpresentation/opf/spec/schemas/opf.schema.json" with {\n  type: "json",\n};\n```\n\nUse the [installable OPF CLI](./packages/cli/README.md) to create, validate, and edit files locally:\n\n```sh\npnpm --filter @openpresentation/cli build\nnode packages/cli/dist/index.js create deck.opf.json --title "Decision brief"\nnode packages/cli/dist/index.js validate deck.opf.json\nnode packages/cli/dist/index.js edit deck.opf.json --patch changes.json --in-place\n```\n\nSee [CSV and JSON data import](./docs/data-import.md) for editable tables and charts in the editor, CLI, and package API, and [content conversions](./docs/conversions.md) for the pure converters (`@openpresentation/opf/convert`) that change a block\'s kind, nest list items, restructure a slide and split or merge slides, and [Markdown and outlines](./docs/markdown.md) for the deterministic Markdown dialect (`@openpresentation/opf/markdown`, `opf from-md`, `opf to-md`) that reads and writes a whole deck as text.\n\n[OPF as YAML](./docs/yaml.md) describes the strict YAML form of a deck (`@openpresentation/opf/yaml`, `opf from-yaml`, `opf to-yaml`, `.opf.yaml` files in every command, editor autocomplete); JSON stays the canonical form. A deck can equally be a Markdown file, `deck.opf.md`: every command reads and writes it (see [Markdown decks in every command](./docs/markdown.md#markdown-decks-in-every-command)), and `parse` / `stringify` read and write a deck in JSON, YAML or Markdown with one call.\n\nSee [Templates and variables](./docs/templates-and-variables.md) for fillable OPF templates: typed variables, `{{id}}` tokens, `opf fill` and `resolveVariables`.\n\n## Layout\n\n| Path | Contents |\n|---|---|\n| [`spec/schemas/opf.schema.json`](./spec/schemas/opf.schema.json) | Canonical JSON Schema for top-level OPF `Presentation` documents. |\n| [`docs/how-opf-works.md`](./docs/how-opf-works.md) | Conceptual introduction: the document model, content shapes, catalog resolution, and the validation philosophy. Start here. |\n| [`docs/design-resolution.md`](./docs/design-resolution.md) | The design precedence algorithm (slide design \u2192 deck design \u2192 resolved theme \u2192 engine defaults) with worked examples. |\n| [`docs/schema-reference.md`](./docs/schema-reference.md) | Author-facing reference for top-level OPF fields and every presentation schema `$defs` object/type. |\n| [`docs/catalog-schema-reference.md`](./docs/catalog-schema-reference.md) | Author-facing reference for every companion catalog schema. |\n| [`docs/content-payloads.md`](./docs/content-payloads.md) | Author-facing notes for slide and region content payloads, including chart and table object shapes. |\n| [`docs/footnotes-citations-captions.md`](./docs/footnotes-citations-captions.md) | Citations (`cite`), inline footnotes, the deck `references` list, captions on images, charts, tables and videos, and how every engine draws them. |\n| [`docs/examples.md`](./docs/examples.md) | Guide to the expanded scenario-oriented examples under `examples/gallery/`. |\n| [`docs/live-editor.md`](./docs/live-editor.md) | Browser canvas, live OPF editing, font loading, published packages, and current fidelity limits. |\n| [`docs/release-process.md`](./docs/release-process.md) | Maintainer runbook for tagging, trusted npm publishing, verification, and GitHub release notes. |\n| [`spec/schemas/*.schema.json`](./spec/schemas) | Companion schemas for catalog records and sub-objects. |\n| [`spec/catalogs/<catalog-kind>/`](./spec/catalogs) | The pinned snapshot of the default catalog pptx.gallery publishes (shipped as `@openpresentation/opf/catalog`). |\n| [`spec/openapi.yaml`](./spec/openapi.yaml) | Optional reference OpenAPI contract for downstream services that choose to expose OPF over HTTP. OpenPresentation does not host this API. |\n| [`examples/technical/`](./examples/technical) | Focused OPF fixtures for validator, renderer, catalog-resolution, design, content-payload, and region behavior. |\n| [`examples/gallery/`](./examples/gallery) | Broader OPF example decks organized by industry, function, education, government, presentation type, international, and design/media scenarios. |\n| [`packages/javascript/`](./packages/javascript) | Public pre-stable source for `@openpresentation/opf`. |\n| [`packages/cli/`](./packages/cli) | Installable local CLI for creating, validating, editing, and inspecting OPF. |\n| [`legacy/`](./legacy) | Tombstone for service-specific clients, CLIs, tool integrations, and workflows removed from the OpenPresentation OSS repo. |\n\n## OpenPresentation Boundary\n\nOpenPresentation defines the format, bundled presets, local validation, examples, docs, and planned local render/edit/convert libraries. It does not provide hosted functions or managed product surfaces.\n\nFuture non-JavaScript OPF packages should follow the same local-first boundary: Python and Go packages should expose schemas, types/models, catalogs, validation, and package-addressable assets. Future toolkit packages should expose embeddable library APIs with no required network calls, hosted callbacks, hidden telemetry, or managed infrastructure assumptions.\n\nThe published JavaScript package copies package-addressable OPF schemas, catalogs, reference assets, and the optional reference `spec/openapi.yaml` from `spec/`. It intentionally remains `@openpresentation/opf` instead of introducing a separate `@openpresentation/opf-spec` package so downstream imports can advance by semver-pinning one canonical package.\n\n## License\n\nMIT. See [LICENSE](./LICENSE).\n';
+var repoReadmeRaw = '# Open Presentation Format (OPF)\n\n[![npm version](https://img.shields.io/npm/v/@openpresentation/opf?label=npm)](https://www.npmjs.com/package/@openpresentation/opf)\n[![npm downloads](https://img.shields.io/npm/dw/@openpresentation/opf)](https://www.npmjs.com/package/@openpresentation/opf)\n[![license](https://img.shields.io/npm/l/@openpresentation/opf)](./LICENSE)\n\nPublic npm package: [`@openpresentation/opf`](https://www.npmjs.com/package/@openpresentation/opf) (`npm install @openpresentation/opf`).\n\nOpen Presentation Format is the portable, human-readable JSON document format for slide decks.\n\nThis repository is the canonical home for the OPF **spec**, **JSON Schemas**, **catalog presets**, examples, generated developer types, local validation tooling, and integration docs for the render/edit/convert toolkit. OpenPresentation publishes open-source code and documentation only; it does not provide hosted APIs, hosted rendering functions, queues, storage, authentication, jobs, previews, SLAs, telemetry, or managed infrastructure.\n\nFor AI agents, use the [OPF skill set](docs/agent-skills.md) for authoring, layout, presets, editing, export, and schema inspection.\n\nPublished CLI 0.17.1 installs all six skills into your project with `npx @openpresentation/cli@0.17.1 skills install`. It uses local copies, preserves existing instructions and refuses to overwrite customized skills. See the [installation and update guide](docs/agent-skills.md) for personal or agent-specific targets and source development.\n\nFor a fresh Node 24 project that installs **published** packages (not this\ncheckout), follow the [developer quickstart](docs/quickstart.md) and the\n[compatibility matrix](docs/compatibility-matrix.md).\n\nFor LLM authoring, start with [the authoring guide](docs/llm-authoring.md), [dynamic composition](docs/dynamic-composition.md), and [local ecosystem verification](docs/ecosystem-development.md).\n\n## File naming\n\nOpen Presentation Format documents are JSON files. Use `*.opf.json` for complete OPF presentation documents, for example `board-review.opf.json` or `deck.opf.json`.\n\nAvoid using bare `*.opf` for OPF JSON. The `.opf` extension is already used by other document and project formats, while `.opf.json` keeps the OPF identity and still makes the underlying JSON format clear to editors, validators, agents, and version-control tooling.\n\n## Naming and reuse\n\nThe format name is **Open Presentation Format**. The schemas, catalogs, packages, and local tooling in this repository are free and open source under the MIT license, so third-party tools may read, write, validate, render, convert, and describe support for Open Presentation Format without adopting any product-specific branding.\n\n## Why OPF\n\n`.pptx` is a zipped bundle of XML. Humans can\'t diff it, LLMs can\'t read or write it reliably, and git can\'t track it meaningfully. Every change looks like a binary blob.\n\nOPF is plain JSON. A human can open it in an editor. A model can read and write it without guessing at schema-by-example. Decks live in git like the rest of your work.\n\nThat\'s the shift that lets LLMs actually *author* decks. When the format stops fighting them, models can do the work that matters \u2014 narrative structure, persuasive framing, data analysis, chart recommendations, ruthless revision passes \u2014 instead of wrestling with `<p:sp>` tags.\n\nAnd they don\'t start from a blank canvas. [pptx.gallery](https://pptx.gallery) is the human-browsable reference for OPF catalog presets: layouts, themes, color schemes, font schemes, chart types, narratives, audiences, purposes, tones, languages, and social platforms.\n\n## Start in three steps\n\n1. **Install the coordinated published packages** on Node 24. See [the developer quickstart](docs/quickstart.md) for the current pin set: core 0.17.0, renderer 0.17.1, editor 0.17.0, PPTX 0.17.0 and CLI 0.17.1.\n2. **Author, validate, paginate, preview and export.** Copy [`docs/quickstart/developer-quickstart.opf.json`](./docs/quickstart/developer-quickstart.opf.json) and run the commands in that guide. From code, `convert("deck.opf.md", "deck.pdf")` of `@openpresentation/opf` is the simple path to a PDF, PNG, SVG or PPTX file. `validate` / `opf validate` is one local checker for format, references, accessibility, layout and content ([guide](docs/validate.md)), not visual verification.\n3. **Know the limits.** The [compatibility matrix](docs/compatibility-matrix.md) lists shipped APIs versus renderer issue 24, native PowerPoint issue 87, and other deferred work. Browse presets at [pptx.gallery](https://pptx.gallery).\n\nYour deck can live in git from the first commit. After installing dependencies and supplying referenced assets, these commands run locally without a model provider, account or hosted OPF API.\n\n## JavaScript and TypeScript\n\nThe canonical JavaScript/TypeScript package is published at [`packages/javascript`](./packages/javascript) as [`@openpresentation/opf`](https://www.npmjs.com/package/@openpresentation/opf). The schema is pre-stable (0.x \u2014 expect breaking changes between minor versions until 1.0). Its responsibility is local and format-level only:\n\n- export the canonical schemas from [`spec/`](./spec)\n- export the pinned default catalog (the pptx.gallery snapshot in [`spec/catalogs/`](./spec/catalogs)) as the opt-in `@openpresentation/opf/catalog`, for hosts to register\n- export a typed raw spec file manifest for package-addressable `spec/` content\n- generate TypeScript types, with `Presentation` as the top-level type\n- validate OPF JSON and catalog records locally\n\nIn Node (and Bun and Deno) its root also reads and writes files (`convert`, `open`, `save`) and draws them through the optional engines below; in a browser or a worker the same import is a browser-safe build with the same names, where those three reject with `node-only`. Every other entry runs in a browser. It does not generate content with AI, fetch remote catalogs, call hosted APIs, or provide managed services. Render/edit/convert packages live in separate MIT repos that depend on `@openpresentation/opf`. The format package also exposes pure composition geometry so those packages share layout behavior.\n\n## Toolkit libraries\n\nOPF is five packages. **Core** (`@openpresentation/opf`) is the format and its API: it reads and writes the text formats (JSON, YAML, Markdown) and validates, and in Node reads and writes files, through the same import. **The CLI** (`@openpresentation/cli`) is the `opf` command. **Render** (`opf-render`), **PPTX** (`opf-pptx`) and **the editor** (`opf-editor`) are the engines: drawing, PowerPoint and editing, installed as needed. The engines and the editor live in sibling repositories. See [ecosystem development](docs/ecosystem-development.md) for coordinated builds and verification, and [dynamic composition](docs/dynamic-composition.md) for portable layout rules.\n\n| Repo | Role | Boundary |\n|---|---|---|\n| `cli` (`@openpresentation/cli`, this repository) | `opf` command | Runs core\'s Node engine: reads and writes files and calls the engines below as optional peers |\n| `opf-render` | OPF to SVG/PNG/PDF | Local and embeddable rendering library |\n| `opf-editor` | WYSIWYG bindings/components | Headless editor primitives plus optional UI components |\n| `opf-pptx` | OPF to PPTX and PPTX to OPF | Pure local import/export library for browser and server use where supported |\n\nThese repos provide OSS primitives only. Downstream applications own hosting, auth, storage, collaboration, queues, previews, analytics, support, and workflow UX.\n\n## Usage\n\nInstall from npm:\n\n```sh\npnpm add @openpresentation/opf\n# or: npm install @openpresentation/opf\n```\n\nTo work on the package itself, clone this repo and build the workspace:\n\n```sh\npnpm install\npnpm build\n```\n\nUse the format package from JavaScript or TypeScript:\n\n```ts\nimport { presentation, validate } from "@openpresentation/opf";\nimport { defaultCatalog } from "@openpresentation/opf/catalog";\n\nimport type { Presentation } from "@openpresentation/opf";\n\nconst deck: Presentation = {\n  name: "Quarterly Review",\n  slides: [{ title: "Quarterly Review", items: ["Revenue", "Product", "Hiring"] }],\n};\n\nconst report = validate(deck);\nconsole.log(report.valid); // no finding has severity "error"\nconsole.log(report.findings); // every finding: rule id, severity, category, JSON Pointer path, message, fixes\n// Core ships no catalog records in its main entry; a host registers the catalogs it trusts.\nconsole.log(validate({ ...deck, design: { theme: "classic" } }, { catalogs: [defaultCatalog] }).valid);\nconsole.log(Object.keys(defaultCatalog.audiences).length);\n```\n\nConvert, open and save files in Node with `@openpresentation/opf`, the same import a browser uses (the engines `@openpresentation/opf-render` and `@openpresentation/opf-pptx` are optional peers, installed as needed; see [OPF files in Node](docs/node.md)):\n\n```ts\nimport * as opf from "@openpresentation/opf";\n\nawait opf.convert("deck.opf.md", "deck.pdf");\nconst deck = await opf.open("deck.opf.md");\ndeck.slides.push({ title: "Q4" });\nawait opf.save(deck, "deck.opf.md");\nconst { files } = await opf.convert(deck, { format: "pptx" }); // bytes, nothing written\n```\n\nUse focused imports when you only need one surface:\n\n```ts\nimport { presentation } from "@openpresentation/opf/schemas";\nimport { defaultCatalog } from "@openpresentation/opf/catalog";\nimport { specFileEntries } from "@openpresentation/opf/spec-files";\nimport { validate } from "@openpresentation/opf/validator";\nimport type { Presentation } from "@openpresentation/opf/types";\n```\n\nUse raw JSON when an engine or resolver needs package-addressable files:\n\n```ts\nimport presentationSchema from "@openpresentation/opf/spec/schemas/opf.schema.json" with {\n  type: "json",\n};\n```\n\nUse the [installable OPF CLI](./packages/cli/README.md) to create, validate, and edit files locally:\n\n```sh\npnpm --filter @openpresentation/cli build\nnode packages/cli/dist/index.js create deck.opf.json --title "Decision brief"\nnode packages/cli/dist/index.js validate deck.opf.json\nnode packages/cli/dist/index.js edit deck.opf.json --patch changes.json --in-place\n```\n\nSee [CSV and JSON data import](./docs/data-import.md) for editable tables and charts in the editor, CLI, and package API, and [content conversions](./docs/conversions.md) for the pure converters (`@openpresentation/opf/convert`) that change a block\'s kind, nest list items, restructure a slide and split or merge slides, and [Markdown and outlines](./docs/markdown.md) for the deterministic Markdown dialect (`@openpresentation/opf/markdown`, `opf convert deck.md deck.opf.json`) that reads and writes a whole deck as text.\n\n[OPF as YAML](./docs/yaml.md) describes the strict YAML form of a deck (`@openpresentation/opf/yaml`, `opf convert deck.opf.json deck.opf.yaml`, `.opf.yaml` files in every command, editor autocomplete); JSON stays the canonical form. A deck can equally be a Markdown file, `deck.opf.md`: every command reads and writes it (see [Markdown decks in every command](./docs/markdown.md#markdown-decks-in-every-command)), and `parse` / `stringify` read and write a deck in JSON, YAML or Markdown with one call.\n\nSee [Templates and variables](./docs/templates-and-variables.md) for fillable OPF templates: typed variables, `{{id}}` tokens, `opf fill` and `resolveVariables`.\n\n## Layout\n\n| Path | Contents |\n|---|---|\n| [`spec/schemas/opf.schema.json`](./spec/schemas/opf.schema.json) | Canonical JSON Schema for top-level OPF `Presentation` documents. |\n| [`docs/how-opf-works.md`](./docs/how-opf-works.md) | Conceptual introduction: the document model, content shapes, catalog resolution, and the validation philosophy. Start here. |\n| [`docs/design-resolution.md`](./docs/design-resolution.md) | The design precedence algorithm (slide design \u2192 deck design \u2192 resolved theme \u2192 engine defaults) with worked examples. |\n| [`docs/schema-reference.md`](./docs/schema-reference.md) | Author-facing reference for top-level OPF fields and every presentation schema `$defs` object/type. |\n| [`docs/catalog-schema-reference.md`](./docs/catalog-schema-reference.md) | Author-facing reference for every companion catalog schema. |\n| [`docs/content-payloads.md`](./docs/content-payloads.md) | Author-facing notes for slide and region content payloads, including chart and table object shapes. |\n| [`docs/footnotes-citations-captions.md`](./docs/footnotes-citations-captions.md) | Citations (`cite`), inline footnotes, the deck `references` list, captions on images, charts, tables and videos, and how every engine draws them. |\n| [`docs/examples.md`](./docs/examples.md) | Guide to the expanded scenario-oriented examples under `examples/gallery/`. |\n| [`docs/live-editor.md`](./docs/live-editor.md) | Browser canvas, live OPF editing, font loading, published packages, and current fidelity limits. |\n| [`docs/release-process.md`](./docs/release-process.md) | Maintainer runbook for tagging, trusted npm publishing, verification, and GitHub release notes. |\n| [`spec/schemas/*.schema.json`](./spec/schemas) | Companion schemas for catalog records and sub-objects. |\n| [`spec/catalogs/<catalog-kind>/`](./spec/catalogs) | The pinned snapshot of the default catalog pptx.gallery publishes (shipped as `@openpresentation/opf/catalog`). |\n| [`spec/openapi.yaml`](./spec/openapi.yaml) | Optional reference OpenAPI contract for downstream services that choose to expose OPF over HTTP. OpenPresentation does not host this API. |\n| [`examples/technical/`](./examples/technical) | Focused OPF fixtures for validator, renderer, catalog-resolution, design, content-payload, and region behavior. |\n| [`examples/gallery/`](./examples/gallery) | Broader OPF example decks organized by industry, function, education, government, presentation type, international, and design/media scenarios. |\n| [`packages/javascript/`](./packages/javascript) | Public pre-stable source for `@openpresentation/opf`. |\n| [`packages/cli/`](./packages/cli) | Installable local CLI for creating, validating, editing, and inspecting OPF. |\n| [`legacy/`](./legacy) | Tombstone for service-specific clients, CLIs, tool integrations, and workflows removed from the OpenPresentation OSS repo. |\n\n## OpenPresentation Boundary\n\nOpenPresentation defines the format, bundled presets, local validation, examples, docs, and planned local render/edit/convert libraries. It does not provide hosted functions or managed product surfaces.\n\nFuture non-JavaScript OPF packages should follow the same local-first boundary: Python and Go packages should expose schemas, types/models, catalogs, validation, and package-addressable assets. Future toolkit packages should expose embeddable library APIs with no required network calls, hosted callbacks, hidden telemetry, or managed infrastructure assumptions.\n\nThe published JavaScript package copies package-addressable OPF schemas, catalogs, reference assets, and the optional reference `spec/openapi.yaml` from `spec/`. It intentionally remains `@openpresentation/opf` instead of introducing a separate `@openpresentation/opf-spec` package so downstream imports can advance by semver-pinning one canonical package.\n\n## License\n\nMIT. See [LICENSE](./LICENSE).\n';
 
 // src/repo-readme.ts
 var repoReadme = repoReadmeRaw;

package/dist/schemas.d.ts

@@ -43,7 +43,8 @@ declare const presentation: JsonSchemaDocument & {
         readonly "ImageBorder": JsonObject;
         readonly "ImageRecolor": JsonObject;
         readonly "PatternBackground": JsonObject;
-        readonly "LogoSet": JsonObject;
+        readonly "OrganizationLogo": JsonObject;
+        readonly "LogoSource": JsonObject;
         readonly "Watermark": JsonObject;
         readonly "HeaderFooter": JsonObject;
         readonly "HeaderFooterItem": JsonObject;
@@ -179,7 +180,8 @@ declare const schemas: {
             readonly "ImageBorder": JsonObject;
             readonly "ImageRecolor": JsonObject;
             readonly "PatternBackground": JsonObject;
-            readonly "LogoSet": JsonObject;
+            readonly "OrganizationLogo": JsonObject;
+            readonly "LogoSource": JsonObject;
             readonly "Watermark": JsonObject;
             readonly "HeaderFooter": JsonObject;
             readonly "HeaderFooterItem": JsonObject;

package/dist/schemas.js

@@ -1 +1 @@
-export { audience, chartType, colorScheme, fontScheme, language, layout, narrative, presentation, purpose, schemaEntries, schemaNames, schemas, socialPlatform, theme, tone } from './chunk-RA64UQKI.js';
+export { audience, chartType, colorScheme, fontScheme, language, layout, narrative, presentation, purpose, schemaEntries, schemaNames, schemas, socialPlatform, theme, tone } from './chunk-6WW2EDUW.js';

package/dist/spec/schemas/opf.schema.json

@@ -36,7 +36,7 @@
           "minItems": 1
         }
       ],
-      "description": "Organization associated with the presentation, usually the presenting company. Array form supports hosts, partners, clients, and sponsors. The primary organization (Organization.role 'primary', else the first item) supplies the default deck logo, the 'socials' header/footer field and the 'organization.<field>' built-in variables; the others are available by id as 'organization.<id>.<field>' and are not drawn automatically."
+      "description": "Organization associated with the presentation, usually the presenting company. Array form supports hosts, partners, clients, and sponsors. The primary organization (Organization.role 'primary', else the first item) supplies the cover and section logo, the 'socials' header/footer field and the 'organization.<field>' built-in variables; the others are available by id as 'organization.<id>.<field>' and are not drawn automatically."
     },
     "speaker": {
       "oneOf": [
@@ -494,7 +494,7 @@
     },
     "Organization": {
       "type": "object",
-      "description": "An organization associated with the presentation, typically the presenting company, but also hosts, partners, clients, or sponsors. The primary organization (role 'primary', else the first one) supplies the default deck logo (unless design.logo overrides it) and the 'socials' header/footer field (its socials). Every field is also a built-in variable ('{{organization.name}}', 'var:organization.logo', 'organization.<id>.<field>'). Nothing else about an organization is drawn automatically. See docs/templates-and-variables.md.",
+      "description": "An organization associated with the presentation, typically the presenting company, but also hosts, partners, clients, or sponsors. The primary organization (role 'primary', else the first one) supplies the cover and section logo (unless design.logo overrides it) and the 'socials' header/footer field (its socials). Every field is also a built-in variable ('{{organization.name}}', 'organization.<id>.<field>'), and every logo a slide-scoped image ('var:organization.logo.icon', 'var:organization.<id>.logo'). Nothing else about an organization is drawn automatically. See docs/templates-and-variables.md.",
       "required": ["id", "name"],
       "properties": {
         "id": {
@@ -514,12 +514,16 @@
           "examples": ["Acme Corporation, Inc.", "Beta Industries, LLC"]
         },
         "logo": {
-          "$ref": "#/$defs/Asset",
-          "description": "Source for the organization's logo image. Accepts an HTTPS URL, data URI, relative path (resolved against the OPF file location), local path, or 'asset:<id>' reference. Common formats are SVG (preferred for vector logos), PNG (with transparency), or JPG. The primary organization's logo (role 'primary', else the first organization) is the fallback source wherever the deck logo is drawn: a slide's design.logo, then design.logo, then this value. It is therefore drawn on cover and section slides and by header/footer zones with logo: true, exactly as design.logo would be (see design.logo and docs/design-resolution.md). It is also the built-in image variable 'organization.logo' (or 'organization.<id>.logo'), placed with 'var:organization.logo' in an image field.",
+          "oneOf": [
+            { "$ref": "#/$defs/Asset" },
+            { "$ref": "#/$defs/OrganizationLogo" }
+          ],
+          "description": "The organization's logo. A path, URL or Asset is one logo for every shape; an object gives up to four shapes (full, stacked, icon, wordmark), each a path or Asset, or { onLight, onDark } for the two backgrounds. A path is resolved against the OPF file location; an HTTPS URL, data URI or 'asset:<id>' reference works too. SVG (preferred for vector logos) or PNG with transparency are typical. The primary organization's full logo (role 'primary', else the first organization) is drawn on cover and section slides unless design.logo names another or is false. Every logo is also a slide-scoped built-in image, placed with a whole-field reference in any image field: 'var:organization.logo' (the full logo), 'var:organization.logo.icon' (likewise stacked, wordmark, full), and 'var:organization.<id>.logo' or 'var:organization.<id>.logo.<shape>' for another organization. A missing shape falls back to full, and full to the first defined of wordmark, stacked and icon. The onLight or onDark value is chosen for each slide's background; a missing one uses the other. See docs/templates-and-variables.md and docs/design-resolution.md.",
           "examples": [
+            "./assets/acme-logo.svg",
+            { "full": "./assets/acme-logo.svg", "icon": "./assets/acme-mark.svg" },
+            { "full": { "onLight": "./assets/acme-logo.svg", "onDark": "./assets/acme-logo-white.svg" }, "icon": "./assets/acme-mark.svg" },
             "https://cdn.acme.com/logo.svg",
-            "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/x8AAusB9V3iWggAAAAASUVORK5CYII=",
-            "./assets/logo.jpg",
             "asset:acme-logo"
           ]
         },
@@ -547,7 +551,7 @@
         "role": {
           "type": "string",
           "enum": ["primary", "partner", "client", "sponsor", "host"],
-          "description": "Role of the organization relative to the presentation. Only 'primary' has behavior: it selects the primary organization (deck logo, the 'socials' header/footer field, and the 'organization.<field>' built-ins). When no organization has role 'primary', the first one is primary. 'partner', 'client', 'sponsor' and 'host' are descriptive labels that change nothing."
+          "description": "Role of the organization relative to the presentation. Only 'primary' has behavior: it selects the primary organization (cover and section logo, the 'socials' header/footer field, and the 'organization.<field>' built-ins). When no organization has role 'primary', the first one is primary. 'partner', 'client', 'sponsor' and 'host' are descriptive labels that change nothing."
         },
         "socials": {
           "$ref": "#/$defs/Socials",
@@ -691,14 +695,14 @@
         },
         "logo": {
           "oneOf": [
-            { "$ref": "#/$defs/Asset" },
-            { "$ref": "#/$defs/LogoSet" }
+            {
+              "type": "string",
+              "pattern": "^var:organization(\\.[A-Za-z0-9_-]+)?\\.logo(\\.(full|stacked|icon|wordmark))?$"
+            },
+            { "type": "boolean", "const": false }
           ],
-          "description": "Deck logo assets used by covers, section dividers, headers, footers and picture bullets. A string or Asset object is the default logo source; the LogoSet object form provides light/dark, stacked, icon, and wordmark variants (see LogoSet for the selection order). Source precedence: a slide's design.logo, then this value, then the primary organization's logo; absence inherits. Placement (reference engines, vetoable): on a cover or section slide (no body payload on a heading-only layout such as title, title-subtitle or section-divider, or no layout) the lockup variant is drawn at the top-left of the free area, inside the slide padding and below any header furniture, in a box 56 reference pixels tall and at most four times as wide; the tag/title/subtitle group then centers in the remaining span. Content slides never get an automatic logo. Header and footer zones draw the icon variant when they set logo: true, and design.listBullet 'image' draws it as the picture bullet. composeSlide returns the cover box as geometry.logo.",
-          "examples": [
-            "asset:acme-logo",
-            { "default": "asset:acme-logo", "light": "asset:acme-logo-white", "icon": "asset:acme-icon" }
-          ]
+          "description": "Which logo covers, section dividers and picture bullets draw. Logos live on the organization (Organization.logo); without this field covers and sections draw the primary organization's full logo and picture bullets its icon. A logo reference overrides that: 'var:organization.beta.logo' draws organization beta's logo, and a reference that names a shape ('var:organization.logo.wordmark') draws that shape everywhere this field applies. false draws no logo. A slide's design.logo overrides the deck's; absence inherits. An override naming an organization without a logo draws nothing (validation warns). Placement (reference engines, vetoable): on a cover or section slide (no body payload on a heading-only layout such as title, title-subtitle or section-divider, or no layout) the logo is drawn at the top-left of the free area, inside the slide padding and below any header furniture, in a box 56 reference pixels tall and at most four times as wide; the tag/title/subtitle group then centers in the remaining span. Content slides never get an automatic logo; a header or footer zone places one with image: 'var:organization.logo.icon'. composeSlide returns the cover box as geometry.logo.",
+          "examples": ["var:organization.logo.wordmark", "var:organization.beta.logo", false]
         },
         "watermark": {
           "oneOf": [
@@ -715,7 +719,7 @@
             { "$ref": "#/$defs/HeaderFooter" }
           ],
           "description": "Repeated header furniture rendered outside the main slide content. Use false to suppress an inherited header.",
-          "examples": [false, { "left": { "text": "{{slide.section}}" }, "right": { "image": "asset:acme-logo" } }]
+          "examples": [false, { "left": { "text": "{{slide.section}}" }, "right": { "image": "var:organization.logo.icon" } }]
         },
         "footer": {
           "oneOf": [
@@ -725,7 +729,7 @@
           "description": "Repeated footer furniture rendered outside the main slide content. Use false to suppress an inherited footer.",
           "examples": [
             false,
-            { "left": { "image": "asset:acme-logo" }, "center": { "text": "Confidential" }, "right": { "text": "{{slide.number}}" } }
+            { "left": { "image": "var:organization.logo.icon" }, "center": { "text": "Confidential" }, "right": { "text": "{{slide.number}}" } }
           ]
         },
         "titleAlignment": {
@@ -760,7 +764,7 @@
         "listBullet": {
           "type": "string",
           "enum": ["character", "image"],
-          "description": "Marker style for items and bullets lists. Effective value: the slide's design, then the deck's design, then the layout record's design.listBullet, then 'character'. 'character' (the default) draws the glyph marker. 'image' draws the deck's icon logo (a slide's design.logo, then design.logo, then the primary organization's logo; light variants on dark backgrounds) as a picture bullet: a square of the marker's font size whose bottom sits on the marker baseline, so list geometry does not change. Without a logo the glyph is drawn and the engine reports unresolved-content at this field."
+          "description": "Marker style for items and bullets lists. Effective value: the slide's design, then the deck's design, then the layout record's design.listBullet, then 'character'. 'character' (the default) draws the glyph marker. 'image' draws the primary organization's icon logo (or the organization and shape design.logo names; the onDark value on dark backgrounds) as a picture bullet: a square of the marker's font size whose bottom sits on the marker baseline, so list geometry does not change. Without a logo the glyph is drawn and the engine reports unresolved-content at this field."
         }
       }
     },
@@ -1027,7 +1031,7 @@
       "additionalProperties": {
         "$ref": "#/$defs/Variable"
       },
-      "description": "Named variables, keyed by stable kebab-case id. A variable is a typed, named value the deck declares once and uses in many places: a color ('var:<id>' in color fields, the original use), or content that fills a template (text, number, date, image, url, list). Content is referenced inline as '{{<id>}}' inside any string, or whole as 'var:<id>' in a field of the matching type; '\\{{' writes a literal '{{'. A hex string is shorthand for a color variable. A variable with no 'value' is unfilled: expected in a template (root 'template': true), an error in a normal deck. Engines resolve variables with resolveVariables() before composing, rendering or exporting, so a template plus its values previews and exports exactly like the equivalent hand-written deck. Read-only built-in variables come from the deck's own metadata and use dotted names that a user id can never take: 'deck.name', 'deck.description', 'deck.author', 'speaker.name|title|email|phone|bio|photo' (first speaker), 'speakers' (every speaker's name, a list), 'organization.name|legalName|tagline|domain|email|phone|logo' (primary organization), and 'speaker.<id>.<field>' / 'organization.<id>.<field>' by id. They are written the same two ways ('{{speaker.name}}', 'var:speaker.photo'), are never declared, and an unknown built-in path is a validation error; a known one with no source value resolves to nothing with a warning. The id 'speakers' is reserved. Three built-ins are slide-scoped and written only as inline tokens: '{{slide.number}}' (the displayed slide number after pagination), '{{slide.section}}' (the slide's section) and '{{deck.slideCount}}' (the number of slides after pagination). resolveVariables() leaves them as written; they resolve per slide as it is composed (resolveSlideVariables(), and header/footer text in layoutFurniture()), so every 'slide.' name is reserved and 'var:slide.*' or 'var:deck.slideCount' is a validation error. See docs/templates-and-variables.md.",
+      "description": "Named variables, keyed by stable kebab-case id. A variable is a typed, named value the deck declares once and uses in many places: a color ('var:<id>' in color fields, the original use), or content that fills a template (text, number, date, image, url, list). Content is referenced inline as '{{<id>}}' inside any string, or whole as 'var:<id>' in a field of the matching type; '\\{{' writes a literal '{{'. A hex string is shorthand for a color variable. A variable with no 'value' is unfilled: expected in a template (root 'template': true), an error in a normal deck. Engines resolve variables with resolveVariables() before composing, rendering or exporting, so a template plus its values previews and exports exactly like the equivalent hand-written deck. Read-only built-in variables come from the deck's own metadata and use dotted names that a user id can never take: 'deck.name', 'deck.description', 'deck.author', 'speaker.name|title|email|phone|bio|photo' (first speaker), 'speakers' (every speaker's name, a list), 'organization.name|legalName|tagline|domain|email|phone' (primary organization), and 'speaker.<id>.<field>' / 'organization.<id>.<field>' by id. They are written the same two ways ('{{speaker.name}}', 'var:speaker.photo'), are never declared, and an unknown built-in path is a validation error; a known one with no source value resolves to nothing with a warning. The id 'speakers' is reserved. Three built-ins are slide-scoped and written only as inline tokens: '{{slide.number}}' (the displayed slide number after pagination), '{{slide.section}}' (the slide's section) and '{{deck.slideCount}}' (the number of slides after pagination). resolveVariables() leaves them as written; they resolve per slide as it is composed (resolveSlideVariables(), and header/footer text in layoutFurniture()), so every 'slide.' name is reserved and 'var:slide.*' or 'var:deck.slideCount' is a validation error. Organization logos are slide-scoped whole-field images: 'var:organization.logo', 'var:organization.logo.<shape>' (full, stacked, icon, wordmark), 'var:organization.<id>.logo' and 'var:organization.<id>.logo.<shape>' resolve per slide to the onLight or onDark asset for its background. See docs/templates-and-variables.md.",
       "examples": [
         {
           "risk": "#B42318",
@@ -1732,60 +1736,55 @@
         }
       }
     },
-    "LogoSet": {
+    "OrganizationLogo": {
       "type": "object",
-      "description": "Deck logo variants surfaced by covers, section dividers, headers, footers and picture bullets. Organization identity lives in organization; this object only controls visual rendering assets. Engines select one variant per slot and background tone (resolveLogo in @openpresentation/opf): same-tone variants first, neutral ones next, the opposite tone last. Lockup on a dark background: light, default, stackedLight, stacked, wordmarkLight, wordmark, iconLight, icon, then dark, stackedDark, wordmarkDark, iconDark; on a light background: dark, default, stackedDark, stacked, wordmarkDark, wordmark, iconDark, icon, then light, stackedLight, wordmarkLight, iconLight. The icon slot (headers, footers, picture bullets) tries iconLight or iconDark for the tone, then icon, then the lockup chain; the stacked slot tries stackedLight or stackedDark, then stacked, then the lockup chain.",
+      "description": "An organization's logo in up to four shapes. Each shape is a path or Asset, or { onLight, onDark } for the two backgrounds. A missing shape falls back to full, and full to the first defined of wordmark, stacked and icon; within a shape a missing onLight or onDark uses the other. Shapes are placed with slide-scoped references such as 'var:organization.logo.icon'.",
       "additionalProperties": false,
+      "minProperties": 1,
       "properties": {
-        "default": {
-          "$ref": "#/$defs/Asset",
-          "description": "Default full-lockup logo. Used as fallback when no more specific variant is set."
-        },
-        "light": {
-          "$ref": "#/$defs/Asset",
-          "description": "Light-colored full-lockup logo intended for rendering on dark backgrounds."
-        },
-        "dark": {
-          "$ref": "#/$defs/Asset",
-          "description": "Dark-colored full-lockup logo intended for rendering on light backgrounds."
+        "full": {
+          "$ref": "#/$defs/LogoSource",
+          "description": "The full logo (lockup): mark and name side by side. Drawn on cover and section slides, and placed by 'var:organization.logo'."
         },
         "stacked": {
-          "$ref": "#/$defs/Asset",
-          "description": "Stacked vertical logo lockup, suited to portrait or square brand-mark slots."
-        },
-        "stackedLight": {
-          "$ref": "#/$defs/Asset",
-          "description": "Light-colored stacked logo variant intended for rendering on dark backgrounds."
-        },
-        "stackedDark": {
-          "$ref": "#/$defs/Asset",
-          "description": "Dark-colored stacked logo variant intended for rendering on light backgrounds."
+          "$ref": "#/$defs/LogoSource",
+          "description": "The stacked lockup: mark above the name, for portrait or square slots. Placed by 'var:organization.logo.stacked'."
         },
         "icon": {
-          "$ref": "#/$defs/Asset",
-          "description": "Default icon, mark, or symbol without wordmark. Useful for tight spaces such as footers, badges, and slide-corner marks."
-        },
-        "iconLight": {
-          "$ref": "#/$defs/Asset",
-          "description": "Light-colored icon variant intended for rendering on dark backgrounds."
-        },
-        "iconDark": {
-          "$ref": "#/$defs/Asset",
-          "description": "Dark-colored icon variant intended for rendering on light backgrounds."
+          "$ref": "#/$defs/LogoSource",
+          "description": "The mark or symbol without the name, for tight spaces such as header and footer zones and picture bullets. Placed by 'var:organization.logo.icon'."
         },
         "wordmark": {
-          "$ref": "#/$defs/Asset",
-          "description": "Default wordmark: the organization name set in branded typography, without icon."
-        },
-        "wordmarkLight": {
-          "$ref": "#/$defs/Asset",
-          "description": "Light-colored wordmark variant intended for rendering on dark backgrounds."
-        },
-        "wordmarkDark": {
-          "$ref": "#/$defs/Asset",
-          "description": "Dark-colored wordmark variant intended for rendering on light backgrounds."
+          "$ref": "#/$defs/LogoSource",
+          "description": "The name set in the brand's lettering, without the mark. Placed by 'var:organization.logo.wordmark'."
         }
-      }
+      },
+      "examples": [
+        { "full": "./assets/acme-logo.svg", "icon": "./assets/acme-mark.svg" },
+        { "full": { "onLight": "./assets/acme-logo.svg", "onDark": "./assets/acme-logo-white.svg" } }
+      ]
+    },
+    "LogoSource": {
+      "description": "One logo shape: a path or Asset for every background, or { onLight, onDark }. onLight is drawn on light backgrounds (usually dark artwork) and onDark on dark backgrounds (usually light artwork), by each slide's background; a missing one uses the other.",
+      "oneOf": [
+        { "$ref": "#/$defs/Asset" },
+        {
+          "type": "object",
+          "additionalProperties": false,
+          "minProperties": 1,
+          "properties": {
+            "onLight": {
+              "$ref": "#/$defs/Asset",
+              "description": "The logo for light backgrounds, usually dark artwork."
+            },
+            "onDark": {
+              "$ref": "#/$defs/Asset",
+              "description": "The logo for dark backgrounds, usually light or white artwork."
+            }
+          }
+        }
+      ],
+      "examples": ["./assets/acme-mark.svg", { "onLight": "./assets/acme-logo.svg", "onDark": "./assets/acme-logo-white.svg" }]
     },
     "Watermark": {
       "type": "object",
@@ -1835,13 +1834,9 @@
     },
     "HeaderFooterItem": {
       "type": "object",
-      "description": "One header/footer zone. Every configured field renders; fields in one zone stack top to bottom in the order logo, image, text, socials, date. Generated values such as the slide number, the slide count, the section, the organization or the speaker are variables inside text ('{{slide.number}} / {{deck.slideCount}}', '{{organization.name}}'), so one text writes several values in the author's order; a line break is '\\n'. Put a date and a slide number in different zones to keep each on the zone's single line. See docs/templates-and-variables.md.",
+      "description": "One header/footer zone. Every configured field renders, side by side in one row in the order image, text, socials, date (mirrored in a right-to-left deck), aligned to the zone's edge (left, center or right) and vertically centered on each other; a line break inside text or socials ('\\n') stacks lines within that part. When the parts are wider than the zone their text wraps, and a row that cannot fit even so is reported as overflow. Generated values such as the slide number, the slide count, the section, the organization or the speaker are variables inside text ('{{slide.number}} / {{deck.slideCount}}', '{{organization.name}}'), so one text writes several values in the author's order. An organization logo is image: 'var:organization.logo.icon'. See docs/templates-and-variables.md.",
       "additionalProperties": false,
       "properties": {
-        "logo": {
-          "type": "boolean",
-          "description": "Whether to render the deck's icon logo in this zone: a slide's design.logo, then design.logo, then the primary organization's logo (LogoSet icon variants first, light ones on dark backgrounds). It is a generated image part in the same box as image; without a logo the engine reports unresolved-content at this field. Use image for a literal picture that is not the deck logo."
-        },
         "text": {
           "type": "string",
           "description": "Text rendered in this zone. Variables resolve inside it like any string: deck-wide ones ('{{organization.name}}', '{{speaker.name}}, {{speaker.title}}', '{{customer}}') before composition, and the slide-scoped built-ins '{{slide.number}}', '{{slide.section}}' and '{{deck.slideCount}}' for each slide as it is laid out. Each '{{slide.number}}' is a live slide-number field: PPTX export writes it as a native field when its value fits within one accepted text line, and as static text with a diagnostic otherwise. '{{deck.slideCount}}' is fixed text, because PowerPoint has no slide-count field. Write '\\{{' for literal braces.",
@@ -1849,8 +1844,8 @@
         },
         "image": {
           "$ref": "#/$defs/Asset",
-          "description": "Generic image rendered in this zone, such as a logo, partner mark, certification badge, or icon.",
-          "examples": ["asset:acme-logo", "./assets/footer-badge.svg"]
+          "description": "Image rendered first in this zone's row, such as a logo, partner mark, certification badge, or icon: a path, URL or Asset, or an organization logo reference ('var:organization.logo.icon', 'var:organization.<id>.logo.wordmark'), which resolves for each slide's background (onLight or onDark).",
+          "examples": ["var:organization.logo.icon", "./assets/footer-badge.svg", "var:organization.beta.logo"]
         },
         "date": {
           "oneOf": [
@@ -2171,7 +2166,7 @@
         },
         "hidden": {
           "type": "boolean",
-          "description": "Whether the slide is hidden from the presented sequence. The player skips it, the PPTX export writes it as a hidden slide, and per-slide image and PDF output skips it unless the caller asks to include hidden slides (opf CLI: --include-hidden; the deck-level renderSvg: the opt-in skipHidden). A slide named explicitly (opf render --slides, renderSvg slideIndex) is still rendered."
+          "description": "Whether the slide is hidden from the presented sequence. The player skips it, the PPTX export writes it as a hidden slide, and per-slide image and PDF output skips it unless the caller asks to include hidden slides (opf CLI: --include-hidden; the deck-level toSvg: the opt-in skipHidden). A slide named explicitly (opf convert --slides, toSvg with a slide number) is still rendered."
         },
         "composition": {
           "$ref": "#/$defs/Composition"

package/dist/types.d.ts

@@ -1,7 +1,7 @@
-export { P as Presentation } from './presentation-fb8CZmRq.js';
-export { c as CatalogKind } from './catalog-refs-C4K4y-vh.js';
+export { P as Presentation } from './presentation-HondgJ3l.js';
+export { C as CatalogKind } from './catalog-refs-BSfGELpt.js';
 export { SchemaName } from './schemas.js';
-export { F as Finding, a as FindingCategory, b as FindingFix, c as FindingFocus, d as FindingLocation, e as FindingReport, f as FindingSeverity, g as FindingSuggestion, J as JsonPatchOperation, V as ValidationIssue } from './finding-CDQ_wH8j.js';
+export { a as Finding, d as FindingCategory, e as FindingFix, f as FindingFocus, b as FindingLocation, F as FindingReport, c as FindingSeverity, g as FindingSuggestion, J as JsonPatchOperation, V as ValidationIssue } from './finding-CT_f_vbD.js';
 import './json-BFSdESOE.js';
 
 /**

package/dist/{validation-types-iZbXfES6.d.ts → validation-types-PbGDrNUr.d.ts}

@@ -1,6 +1,6 @@
-import { b as Catalog } from './catalog-refs-C4K4y-vh.js';
-import { T as TextMeasurement } from './composition-BbZ_9C-c.js';
-import { f as FindingSeverity, e as FindingReport } from './finding-CDQ_wH8j.js';
+import { a as Catalog } from './catalog-refs-BSfGELpt.js';
+import { T as TextMeasurement } from './composition-C-OoqvAr.js';
+import { c as FindingSeverity, F as FindingReport } from './finding-CT_f_vbD.js';
 import { J as JsonPrimitive } from './json-BFSdESOE.js';
 
 /**
@@ -136,13 +136,16 @@ interface BuiltinVariableInfo {
     label: string;
     /**
      * `deck` for a value read once from the document; `slide` for `slide.number`, `slide.section` and
-     * `deck.slideCount`, which vary per slide and resolve as each slide is composed (inline tokens only).
+     * `deck.slideCount`, which vary per slide and resolve as each slide is composed (inline tokens only), and for the
+     * organization logos (`organization.logo`, `organization.logo.icon`, `organization.<id>.logo.wordmark`), whose
+     * onLight or onDark asset follows each slide's background (whole-field `var:` references only).
      */
     scope: "deck" | "slide";
     /** The value the document gives it, when it has one (a string, an Asset or the list of names). Never set for a slide-scoped built-in. */
     value?: unknown;
     /**
-     * True when the document has a source value for it. Unavailable built-ins resolve to nothing. A slide-scoped
+     * True when the document has a source value for it. Unavailable built-ins resolve to nothing. A logo is available
+     * when its organization has a logo (in any shape: missing shapes fall back). A slide-scoped
      * built-in is available when every slide gives it a value: always for `slide.number` and `deck.slideCount`, and
      * for `slide.section` when at least one slide has a section.
      */
@@ -154,7 +157,9 @@ interface BuiltinVariableInfo {
  * The built-in variables of a deck, for pickers and agents: the generic names (`deck.*`, `speaker.*`, `speakers`,
  * `organization.*`) first, then the id-addressed ones (`speaker.<id>.*`, `organization.<id>.*`) of each speaker and
  * organization that has an id, then the slide-scoped `slide.number`, `slide.section` and `deck.slideCount` (scope
- * `slide`, no value). Each carries its kind, current source value and where the document uses it.
+ * `slide`, no value), then the slide-scoped organization logos (`organization.logo` and its `stacked`, `icon` and
+ * `wordmark` shapes, then the same per organization id; kind `image`, scope `slide`, no value). Each carries its kind,
+ * current source value and where the document uses it.
  */
 declare function listBuiltinVariables(presentation: unknown): BuiltinVariableInfo[];
 
@@ -284,4 +289,4 @@ interface ValidationReport extends FindingReport {
     unfilledVariables?: string[];
 }
 
-export { variableDeclarations as A, type BuiltinVariableInfo as B, type Contract as C, DEFAULT_VARIABLE_DATE_FORMAT as D, OPFVariableError as O, type ResolveVariablesOptions as R, VARIABLE_KINDS as V, type ResolveVariablesResult as a, type ValidateFonts as b, type ValidateOptions as c, type ValidationCategory as d, type ValidationChecks as e, type ValidationReport as f, type ValidationRuleCost as g, type ValidationRuleInfo as h, type ValidationThresholds as i, type VariableDeclaration as j, type VariableDiagnostic as k, type VariableDiagnosticCode as l, type VariableDiagnosticSeverity as m, type VariableInfo as n, type VariableKind as o, type VariableUse as p, type VariableUseForm as q, type VariableValues as r, coerceVariableValue as s, formatVariableNumber as t, hasContentVariables as u, isTemplate as v, listBuiltinVariables as w, listVariables as x, resolveVariables as y, validationCategories as z };
+export { variableDeclarations as A, type BuiltinVariableInfo as B, type Contract as C, DEFAULT_VARIABLE_DATE_FORMAT as D, OPFVariableError as O, type ResolveVariablesOptions as R, type ValidationReport as V, type ValidateOptions as a, type ValidationThresholds as b, type ValidationRuleInfo as c, type ValidateFonts as d, type ValidationCategory as e, type ValidationChecks as f, type ValidationRuleCost as g, type VariableDiagnostic as h, type ResolveVariablesResult as i, VARIABLE_KINDS as j, type VariableDeclaration as k, type VariableDiagnosticCode as l, type VariableDiagnosticSeverity as m, type VariableInfo as n, type VariableKind as o, type VariableUse as p, type VariableUseForm as q, type VariableValues as r, coerceVariableValue as s, formatVariableNumber as t, hasContentVariables as u, validationCategories as v, isTemplate as w, listBuiltinVariables as x, listVariables as y, resolveVariables as z };

package/dist/validator.d.ts

@@ -1,13 +1,13 @@
-import { a as CatalogRecordKind } from './catalog-schemas-g7RFQBdc.js';
-import { F as Finding } from './finding-CDQ_wH8j.js';
-import { P as Presentation } from './presentation-fb8CZmRq.js';
-import { i as ValidationThresholds, h as ValidationRuleInfo, f as ValidationReport, c as ValidateOptions } from './validation-types-iZbXfES6.js';
-export { C as Contract, b as ValidateFonts, d as ValidationCategory, e as ValidationChecks, g as ValidationRuleCost, z as validationCategories } from './validation-types-iZbXfES6.js';
-import './catalog-refs-C4K4y-vh.js';
+import { a as CatalogRecordKind } from './catalog-schemas-CinPh5WA.js';
+import { a as Finding } from './finding-CT_f_vbD.js';
+import { P as Presentation } from './presentation-HondgJ3l.js';
+import { b as ValidationThresholds, c as ValidationRuleInfo, V as ValidationReport, a as ValidateOptions } from './validation-types-PbGDrNUr.js';
+export { C as Contract, d as ValidateFonts, e as ValidationCategory, f as ValidationChecks, g as ValidationRuleCost, v as validationCategories } from './validation-types-PbGDrNUr.js';
+import './catalog-refs-BSfGELpt.js';
 import './schemas.js';
 import './json-BFSdESOE.js';
-import './composition-BbZ_9C-c.js';
-import './chart-data-DTxdRRT1.js';
+import './composition-C-OoqvAr.js';
+import './chart-data-BnNqgnC-.js';
 
 /**
  * The series palette opf-render and opf-pptx draw charts with (`CHART_COLORS`), in series order. A host with

package/dist/validator.js

@@ -1,5 +1,5 @@
-export { DEFAULT_CHART_PALETTE, DEFAULT_VALIDATION_THRESHOLDS, OPFValidationError, assertValid, assertValidCatalogRecord, findValidationRule, validate, validateCatalogRecord, validationCategories, validationRules } from './chunk-NLNYNBTS.js';
-export { promotedRegionKeys } from './chunk-CW7GEAV3.js';
+export { DEFAULT_CHART_PALETTE, DEFAULT_VALIDATION_THRESHOLDS, OPFValidationError, assertValid, assertValidCatalogRecord, findValidationRule, validate, validateCatalogRecord, validationCategories, validationRules } from './chunk-JT3QXA22.js';
+export { promotedRegionKeys } from './chunk-MBU42S5Y.js';
 import './chunk-TRDXRRQK.js';
 import './chunk-SPFV27O5.js';
-import './chunk-RA64UQKI.js';
+import './chunk-6WW2EDUW.js';

package/dist/yaml.d.ts

@@ -1,9 +1,9 @@
-import { b as Catalog } from './catalog-refs-C4K4y-vh.js';
-import { P as Presentation } from './presentation-fb8CZmRq.js';
-import { c as ValidateOptions, f as ValidationReport } from './validation-types-iZbXfES6.js';
-import { F as Finding, d as FindingLocation } from './finding-CDQ_wH8j.js';
-import './composition-BbZ_9C-c.js';
-import './chart-data-DTxdRRT1.js';
+import { a as Catalog } from './catalog-refs-BSfGELpt.js';
+import { P as Presentation } from './presentation-HondgJ3l.js';
+import { a as ValidateOptions, V as ValidationReport } from './validation-types-PbGDrNUr.js';
+import { a as Finding, b as FindingLocation } from './finding-CT_f_vbD.js';
+import './composition-C-OoqvAr.js';
+import './chart-data-BnNqgnC-.js';
 import './json-BFSdESOE.js';
 
 /** A finding located in the YAML source: `yaml/<rule>` syntax and dialect errors (category `format`) and the OPF findings of the parsed deck. */

package/dist/yaml.js

@@ -1,9 +1,9 @@
-export { OPFYamlError, YAML_SCHEMA_URL, fromYaml, parseYamlData, scanYamlComments, toYaml } from './chunk-TCD2FB2K.js';
-import './chunk-IS5H5JKH.js';
-import './chunk-YT7FMQER.js';
-import './chunk-PPROJP2E.js';
-import './chunk-NLNYNBTS.js';
-import './chunk-CW7GEAV3.js';
+export { OPFYamlError, YAML_SCHEMA_URL, fromYaml, parseYamlData, scanYamlComments, toYaml } from './chunk-NS3VYB57.js';
+import './chunk-CJPDTLGD.js';
+import './chunk-JXVS7BJK.js';
+import './chunk-RAKEVM52.js';
+import './chunk-JT3QXA22.js';
+import './chunk-MBU42S5Y.js';
 import './chunk-TRDXRRQK.js';
 import './chunk-SPFV27O5.js';
-import './chunk-RA64UQKI.js';
+import './chunk-6WW2EDUW.js';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openpresentation/opf",
-  "version": "0.17.0",
+  "version": "0.18.1",
   "description": "Canonical Open Presentation Format schemas, TypeScript types, local validation and composition; the pinned default catalog ships as the opt-in @openpresentation/opf/catalog.",
   "license": "MIT",
   "author": "Open Presentation",
@@ -32,7 +32,13 @@
   "exports": {
     ".": {
       "types": "./dist/index.d.ts",
-      "import": "./dist/index.js"
+      "bun": "./dist/index.js",
+      "deno": "./dist/index.js",
+      "workerd": "./dist/browser.js",
+      "worker": "./dist/browser.js",
+      "browser": "./dist/browser.js",
+      "node": "./dist/index.js",
+      "default": "./dist/browser.js"
     },
     "./schemas": {
       "types": "./dist/schemas.d.ts",
@@ -116,13 +122,9 @@
       "types": "./dist/convert.d.ts",
       "import": "./dist/convert.js"
     },
-    "./node": {
-      "types": "./dist/node.d.ts",
-      "import": "./dist/node.js"
-    },
-    "./node/engine": {
+    "./internal/engine": {
       "types": "./dist/node-engine.d.ts",
-      "import": "./dist/node-engine.js"
+      "node": "./dist/node-engine.js"
     }
   },
   "files": [
@@ -169,8 +171,8 @@
     "typescript": "~5.9.3"
   },
   "peerDependencies": {
-    "@openpresentation/opf-pptx": "^0.17.0",
-    "@openpresentation/opf-render": "^0.17.0"
+    "@openpresentation/opf-pptx": "^0.18.0",
+    "@openpresentation/opf-render": "^0.18.0"
   },
   "peerDependenciesMeta": {
     "@openpresentation/opf-pptx": {