# Accepted ecosystem objective — September 9, 2026

The user supplied the following expanded objective on September 9. It supersedes the earlier goal and remains open; the current release milestone does not establish its completion.

Complete the OpenPresentation ecosystem as a polished, reliable, fully open and provider-neutral workflow for humans and external AI agents: JSON authoring, automatic layout, browser preview, intuitive editing with undo, and editable PowerPoint export.

OPF itself must not depend on AI or embed an AI design agent. All essential functionality must work locally without model calls, API keys, accounts or paid services. Humans and external AI agents supply content, intent and editorial judgment; OPF provides deterministic tools for expressing, arranging, validating, editing and exporting that content. Proprietary presentation applications may be used for compatibility testing, but must not become runtime dependencies.

Resume from the GitHub checkpoints in docs/handoff-2026-09-08.md and subsequent recorded milestones. Inspect current branches, PRs, registry versions and deployments before acting. Preserve existing work and finish checks, reviews, merges and releases in dependency order, including any unfinished renderer 0.5.0, PPTX 0.5.0 and editor 0.4.0 work. Never republish an already released version, including core 0.7.0 and CLI 0.4.0. Update the core release plan and immutable CI references, then verify fresh registry installations.

Make reliable automatic layout a first-class capability. Humans and agents should be able to provide structured content and design intent without manually positioning every element. Build a deterministic layout-and-repair loop that generates candidate arrangements, measures content using resolved fonts, evaluates documented criteria, and repairs problems before accepting a result. Support rows, columns, grids, nested groups and weighted space allocation. Evaluate readability, hierarchy, balance, whitespace, image proportions and chart/table density through explicit constraints and measurable rules. Identical inputs, font bytes, engine versions and settings should produce identical results.

Unify payload measurement and placement across composition, browser rendering and PowerPoint export, including internal elements such as quote footers, metric labels, chart labels and timeline annotations. Detect actual overflow and collisions. When content cannot fit readably, try better arrangements and space allocation, then paginate according to explicit policy. Preserve content, reading order, rich formatting, metadata and source mappings. Never silently delete, truncate, summarize or shrink below the selected readability floor. Editorial changes belong to the human or external agent through a separate authoring operation. Bound repair attempts and return actionable diagnostics when constraints cannot be satisfied.

Expose layout through supported APIs, CLI commands, agent skills and an intuitive canvas “Auto arrange” action with preview and undo. Humans and agents must use the same underlying operations. Expose structured diagnostics, candidate scores, decision reasons and guarded repairs. Respect explicit positioning and human adjustments, and avoid unnecessary rearrangement after small changes. Preview and export must consume the same accepted document and pagination.

Restore font compatibility and fidelity as a core product requirement. Provide a supported, openly licensed font system that maps common Windows and macOS PowerPoint fonts and Keynote theme fonts to carefully evaluated open alternatives, including suitable Google Fonts. Aim for pixel-level visual fidelity and exact layout preservation wherever achievable. Distinguish metric compatibility, glyph appearance, shaping behavior and raster equivalence; never describe a substitute as pixel perfect based only on matching widths or bounding boxes.

Continue the existing work in docs/font-fidelity.md and docs/plans/font-roadmap.md. Validate Carlito/Calibri, Caladea/Cambria, Arimo/Arial, Tinos/Times New Roman, Cousine/Courier New and Gelasio/Georgia against actual reference fonts. Evaluate Akasia for Aptos without assuming its compatibility claims are proven. Audit actual PowerPoint and Keynote defaults and theme fonts across supported application and OS versions. Build an explicit compatibility matrix, treating Light, Display, Narrow, Mono, weight and italic variants separately.

Test exact font versions and hashes, glyph coverage, advances, kerning, ligatures, shaping, line breaks, baselines, ascent/descent, paragraph spacing, clipping and complete slide appearance. Extend coverage to multilingual text, mixed scripts, fallback, bidirectional text, symbols and math. Classify each mapping as verified within a documented scope, approximate with measured differences, or unsupported. Record tolerances and reference environments; do not promise universal pixel identity across operating systems and rasterizers.

Ship reproducible, versioned font packs with verified provenance, redistribution and embedding permissions, license notices, hashes and clear installation instructions. Essential bundled fonts must work offline without runtime downloads. Make requested fonts, resolved fonts, style substitutions and missing glyphs visible in APIs, CLI diagnostics and the editor. Complete theme-font resolution and investigate permitted font import and native PPTX embedding, with an easy installation path where embedding is unavailable. Verify behavior on machines without the original proprietary fonts.

Evaluate existing open fonts and engine fixes before starting new font development. Where important compatibility gaps remain, consider narrowly scoped open font adaptation or original development using independently created or appropriately licensed outlines, reproducible sources and conformance tests. Never redistribute proprietary reference fonts or copy their outlines without permission.

Establish repeatable layout and font quality coverage using representative and previously unseen content, multiple dimensions, languages, font families, nested structures and density levels. Include malformed inputs, irreducible overflow and valid documents that still produce poor layouts. Measure readability and visual coherence separately from regression stability. Claim reliable unattended layout only within a documented scope supported by end-to-end evidence.

Audit Dependabot PRs across the repositories, test upgrades, address security updates, and reduce notification noise through sensible grouping, scheduling and review configuration. Do not suppress security alerts or blindly merge major upgrades.

Verify and finish an easy, supported npx-style installation flow for all six OPF agent skills, informed by current official approaches. Support safe installation and updates without overwriting unrelated configuration. Remain provider-neutral, document actual commands on the website and repository, and suggest them in relevant CLI output.

Audit and upgrade openpresentation.org, pptx.gallery and Data-Advantage/pptx-dev (pptx.dev) to the verified published package set. Accurately update the public website changelog, deploy the sites, verify exact deployed dependencies, bundles and font assets, and establish repeatable E2E coverage for authoring/import, layout and repair, preview, editing/undo, export and reimport. Public experiences must demonstrate the same open tools users can install.

Use real Microsoft PowerPoint on this Windows computer to test exported files, native editability, save/reopen behavior, font substitution, embedding or installation, reimport and raster comparisons. Compare proprietary reference fonts with their open substitutes as well as comparing browser output with native PowerPoint. Establish equivalent native macOS PowerPoint and Keynote checks when those environments are available; record missing platform evidence as an explicit gap.

Clearly distinguish schema validation, browser behavior, rendering regressions, measured visual quality, font compatibility and native export fidelity. Successful serialization, matching widths or editable text does not establish pixel equivalence or lossless arbitrary PowerPoint round-tripping.

Work in reviewable milestones and keep the portable GitHub handoff, release status, compatibility matrices and evidence current. Pushes, PR updates, merges, tags, npm publication and public deployment updates are authorized.

The intended outcome is that developers, humans and AI agents choose OpenPresentation and OPF for creating and maintaining presentation decks because the tools are open, understandable, dependable, typographically portable and capable of producing polished results without requiring a proprietary service.

## Accepted addition — September 10, 2026

Provide selectable, searchable text and vector drawing in PDF export, using the same accepted layout, pagination and resolved fonts as preview. Make this the default after verification; retain raster PDF as an explicit compatibility mode. Embed permitted font subsets with correct Unicode mappings, preserve content and reading order, and report targeted raster fallbacks for unsupported effects. Keep the workflow open, local and provider-neutral. Selectable text alone does not establish tagged accessibility or PDF conformance. The [PDF export roadmap](pdf-export.md) defines the implementation milestones and release gates; the current published PDF exporter remains image-only.

Support Mermaid diagram authoring through a new `diagram` content type, and general SVG import/render/export through the existing `image` content type, using open, local tools. A diagram rendered as SVG remains a diagram; an imported SVG image does not automatically acquire semantic nodes and connections. Preserve original source, diagram relationships, stable IDs and human edits. Add intuitive preview, source/canvas editing, automatic arrangement and undo, with shared geometry for SVG, vector PDF and editable native PowerPoint export where supported. Distinguish a semantic diagram, editable drawing primitives, an embedded vector graphic and a raster fallback; report unsupported syntax/features rather than silently losing content. The [Mermaid and SVG roadmap](diagrams-svg.md) defines staged coverage, source synchronization, import boundaries and end-to-end evidence requirements.

Target Mermaid's full documented diagram catalog, with an explicit per-family support matrix and staged implementation. Initial flowchart/sequence work must not narrow that objective. Preserve each family's semantics and separately verify parsing, rendering, editing, vector PDF, native PPTX and reimport.

Sequence Mermaid/diagram and general SVG implementation after the font reliability work is working and accepted, including its outstanding layout, rendering and native verification gates. Keep these capabilities on the roadmap now without diverting the active implementation effort from fonts.

## Accepted runtime simplification — September 10, 2026

Standardize on Node 24 and retire Node 20 support and duplicated Node 20 testing. Schedule this as the next bounded maintenance milestone after current in-flight checks, before the next coordinated package release. Node 20 has reached end-of-life; Node 24 is the chosen LTS runtime. See the [official Node.js release schedule](https://github.com/nodejs/Release#release-schedule).

- Audit core/CLI, renderer, editor, PPTX, the three sites, local tooling and Windows coordination for runtime declarations and Node 20/24 matrices.
- Align package engine requirements, development setup, CI, packaging, clean-install verification and site build settings on Node 24. Document the new runtime requirement in the next releases and migration instructions; users of Node 20 or 22 must upgrade for those releases.
- Verify the coordinated candidate packages and essential offline authoring/import → layout/preview → edit/undo → export/reimport workflows on Node 24, then remove Node 20 jobs, duplicate workflow runs and active release gates. Routine development and future release verification should use one Node major.
- Retain browser, operating-system and native PowerPoint checks where they cover distinct behavior. Removing a Node version does not close existing native compatibility failures or justify relaxed visual/source-preservation checks.
- Preserve historical Node 20 evidence and already published artifacts. Update active roadmaps, handoffs and reproduction instructions so old dual-runtime requirements do not keep triggering new duplicate runs.

Completion means the active ecosystem build/test/release path uses Node 24, fresh installs and public-site builds pass under that runtime, and Node 20 is no longer an active compatibility promise or acceptance gate. This roadmap addition authorizes the planned migration; it does not claim that runtime configuration has already changed.