Problem
Hi, I’m the creator of [asciidoc-kmp](https://github.com/markup-poets/asciidoc-kmp), a Kotlin Multiplatform AsciiDoc parser.
I’d like to ask whether there is interest in cooperation around bringing AsciiDoc input support to HyperFrames using asciidoc-kmp as the parser.
Potential advantages:
-
Structured docs-to-video workflows — AsciiDoc provides sections, attributes, images, video macros, code blocks, and other document semantics that could map naturally to HyperFrames compositions.
-
Multiplatform parser — asciidoc-kmp is designed to run across JVM, native platforms, and WebAssembly without relying on Ruby.
-
Clean separation — HyperFrames could remain HTML-first, with AsciiDoc acting only as an optional source format that compiles into normal HyperFrames HTML.
Would there be interest in discussing such an integration or collaboration?
Proposed solution
How should it work?
AsciiDoc should be an optional source format that compiles into normal HyperFrames HTML.
composition.adoc
↓
asciidoc-kmp
↓
AsciiDoc ASG
↓
HyperFrames adapter
↓
index.html
↓
existing HyperFrames pipeline
Example:
= Product Update
[hyperframes-composition, id="intro", duration=8]
== Introduction
[hyperframes-track, start=0, duration=8]
video::assets/background.mp4[]
[hyperframes-track, start=1, duration=5]
A faster build pipeline with a new parser architecture.
asciidoc-kmp would only parse the AsciiDoc. A small HyperFrames-specific adapter would interpret attributes such as hyperframes-composition and hyperframes-track and generate standard HyperFrames HTML.
This keeps HyperFrames HTML as the canonical format and avoids changes to the existing parser, renderer, or runtime.
Alternatives considered
No response
Additional context
No response
Problem
Hi, I’m the creator of
[asciidoc-kmp](https://github.com/markup-poets/asciidoc-kmp), a Kotlin Multiplatform AsciiDoc parser.I’d like to ask whether there is interest in cooperation around bringing AsciiDoc input support to HyperFrames using
asciidoc-kmpas the parser.Potential advantages:
Structured docs-to-video workflows — AsciiDoc provides sections, attributes, images, video macros, code blocks, and other document semantics that could map naturally to HyperFrames compositions.
Multiplatform parser —
asciidoc-kmpis designed to run across JVM, native platforms, and WebAssembly without relying on Ruby.Clean separation — HyperFrames could remain HTML-first, with AsciiDoc acting only as an optional source format that compiles into normal HyperFrames HTML.
Would there be interest in discussing such an integration or collaboration?
Proposed solution
How should it work?
AsciiDoc should be an optional source format that compiles into normal HyperFrames HTML.
Example:
asciidoc-kmpwould only parse the AsciiDoc. A small HyperFrames-specific adapter would interpret attributes such ashyperframes-compositionandhyperframes-trackand generate standard HyperFrames HTML.This keeps HyperFrames HTML as the canonical format and avoids changes to the existing parser, renderer, or runtime.
Alternatives considered
No response
Additional context
No response