Skip to main content

FontSpec

class FontSpec

What one font role is actually set to (#20287 / #20288 decisions 1, 14, 15).

The OVP reuses its mixed font selector, so a playout stores each role the way Channels does: an Id field and a name field.

skin_fontHeadingId = "11748"  skin_fontHeading = "Lato-Bold.ttf"  --> Clip("11748")
skin_fontHeadingId = "00742"  skin_fontHeading = "Lato-Bold.ttf"  --> Clip("742")
skin_fontHeadingId = "-1"     skin_fontHeading = "Verdana"        --> Named("Verdana")
skin_fontHeadingId = "-1"     skin_fontHeading = ""               --> None
skin_fontHeadingId = "0"      skin_fontHeading = "Verdana"        --> None

The reading rule, per role:

  • positive Id: an uploaded font clip; download, validate and cache it ([Clip]).
  • negative Id: a font picked from the OVP's built-in name lists, and the name field carries the choice ([Named]). The number itself is a placeholder the OVP needed because the selector wants an id - never interpret it beyond "negative"; it does not identify anything.
  • Id "", "0", "-0", null or not an integer: cleared ([None]), and the name field is ignored. The OVP is supposed to blank the name field on a clear but readers must not rely on it: a stale name is legitimate there, and the Id field is the only thing that decides.

Nothing is ever downloaded for a [Named] font: the platform asks the OS for a font by that name and falls back to the built-in Lato when the device does not have it. The shared module only classifies.

The absent-vs-cleared rule for partial bb_playout_changed payloads is not here - it needs the raw payload keys, which a parsed model cannot see. It lives in the SDKs and keys on the Id field. See Playout.effectiveSkinFont.

Functions​

from​

fun from(id: String?, name: String?) : FontSpec

Classifies one role's raw Id and name fields. See the class KDoc for the rule; in short: positive Id wins as a [Clip], negative Id takes the trimmed [name] as a [Named] font, everything else - including numeric zero and anything unparsable - is [None].