Skip to main content

OGraf Package Structure

An OGraf graphic is delivered as a self-contained package. It’s designed so that you can create a graphic once and use it across different tools without touching code.

Why this structure?​

An OGraf package is designed to be flexible and future‑proof. A single package can be controlled by various playout systems, and rendered in multiple environments. Because it follows an open specification, mixed vendor setups remain interoperable. All required files are included, making the package portable and reliable across systems. And since it is based on standard web technologies such as HTML, CSS, JavaScript, and Web Components, it stays compatible with today’s and tomorrow’s workflows.

What’s inside​

  • manifest.ograf.json – The package’s description: name, version, what can be controlled, and which file is the entry point.
  • Main module – The graphic itself, implemented as a Web Component that renders the visual.
  • Assets (optional) – Images, fonts, and other media used by the graphic. Referenced with relative paths.

Manifest​

The manifest.ograf.json is the heart of every OGraf package.
It tells tools and controllers how the graphic can be used, without the user having to look at the code.
Among other things, it specifies:

  • Basic information – Name of the graphic, version number, description, and author.
  • Fields that can be edited – e.g. text fields, numbers, checkboxes. These are the controls operators see in their playout software.
  • Main file reference – Which file contains the actual graphic.
  • Playback capabilities – Whether the graphic supports real-time playout (on air) or non-real-time (e.g. rendering for later use).

In simple terms: the manifest is like the instruction sheet of the graphic.
It ensures that any compatible controller knows what fields exist, how they can be changed, and how the graphic should behave.

Main Module​

The “main module” (graphic.mjs) is the actual graphic. It contains the design, layout and animations, built on web standards.

info

The entry file name may vary (e.g., graphic.mjs, index.mjs). The manifest tells tools which file to load.

Assets​

Assets are all the extra files a graphic may need, such as images, logos, or custom fonts.
They are stored inside the package so the graphic is self-contained and works reliably, even if it is moved to a different system.

For example:

  • a team logo for a scoreboard,
  • a background image for a fullscreen graphic,
  • or a font file to ensure consistent typography on every system.

By keeping these files inside the package, OGraf ensures that nothing is missing when the graphic is opened elsewhere.

Typical folder layout​

my-ograf-graphic/
├─ manifest.ograf.json
├─ graphic.mjs          # main module (Web Component)
└─ assets/
   ├─ images/
   └─ fonts/

How tools use the package​

  • Editor – Creates/edits the package content (visuals, fields, assets).
  • Controller – Reads the fields defined in the manifest and exposes them to the operator (e.g., text, scores, toggles).
  • Renderer – Runs the Web Component and shows the result on air or in a preview.
  • Server (optional) – Hosts/distributes packages and can provide APIs for import/export and scheduling.

Vendor-specific extensions​

While OGraf defines a common core schema, some tools may add vendor-specific fields to the manifest.
These extensions can unlock special features in a particular editor, controller, or renderer.

However, they are not guaranteed to work across all tools.
If a package relies heavily on vendor-specific fields, portability may be reduced.

tip

For developers or readers who want to dive deeper into the technical details, the full specification is available here:
👉 OGraf Specification