LibassTypesetter

libass as the engine's SubtitleTypesetter: a container header or a whole script goes in, one event per packet follows, and every render answers positioned premultiplied RGBA images in the output surface's own pixels.

The same pixels on every platform, because the conversion lives in one C header the three bindings include: Kotlin/Native reaches it through cinterop, Android and the desktop JVM through a JNI adapter, the web through an emscripten export table. This class is the Kotlin half they share: it forwards calls to the LibassEngine of its platform and unpacks the one buffer a render returns.

Fonts: Apple and Windows builds find system fonts on their own (CoreText, DirectWrite). Android and Linux have no font provider in this chain, so the first font or track that arrives loads a bounded set of the system's font files first (see KiteLibass.fontDirectories), and then whatever the container attached and the application configured. libass takes its default family, the one a style naming a missing font falls back to, from the first font it is given, so there it is the platform's Latin sans face, Roboto on Android. The web has no system fonts to read: the first font the application or the file brings is the default family, and a page that wants East Asian text in typeset subtitles hands the typesetter a font that has it. Fonts embedded in the script's own [Fonts] section are read by libass itself.

Every member is called from the engine's raster lane and never concurrently, as the interface promises; the constructor is the one call that happens elsewhere, and it does no I/O.