Markdown++ output.
The migration on-ramp out of binary and proprietary formats. Convert FrameMaker, Microsoft Word, DITA XML,
AsciiDoc, and other source types into valid .md files that read in any Markdown tool — while preserving
the structural intent your documentation depends on.
What Markdown++ output delivers.
Markdown++ is ePublisher's output format for teams who want to change their authoring format without
changing their publishing tool. A Markdown++ build emits a directory tree of valid .md files plus
referenced assets — your documentation, in an open and portable format, ready to live in a Git repository, a
documentation static-site generator, or any other Markdown ecosystem.
The output extends CommonMark with invisible Markdown++ extensions: HTML-comment directives for styles, conditions, and includes; inline tokens for variables; and link-reference patterns for cross-document references. The extensions are additive — they unlock professional publishing capabilities in tools that understand them, and they sit invisibly in tools that do not.
Every file opens cleanly in GitHub, VS Code, JetBrains IDEs, Obsidian, MkDocs, Docusaurus, Jekyll, Hugo, or any other CommonMark-compliant viewer with no plugin required.
Notes become <!--style:Note--> directives, conditional content becomes <!--condition:--> blocks, FrameMaker variables become $variable; tokens, cross-references become link-reference definitions with stable alias IDs.
<!--include:--> directives compose multi-file publications the same way DITA topics do, without the XML overhead.
Referenced images and embedded files travel alongside the .md files in a clean folder layout that fits naturally into a Git repository.
Once content is in Markdown++, the same ePublisher project can republish it as Reverb 2.0, PDF, ePUB, Eclipse Help, or any other supported format.
Where Markdown++ output fits.
Markdown++ is the right output when the goal is to move off a binary or proprietary source format and
onto
open, plain-text .md files — without giving up the publishing pipeline you already run.
Decades of FrameMaker book sets, Word manuals, or DITA topics get converted to Markdown++ once. From that point forward, authors edit plain-text .md files in a code editor; ePublisher continues to publish all the downstream formats — Reverb 2.0, PDF, CHM, Eclipse Help — from the same source. Legacy structure (variables, conditions, anchor IDs, cross-references) survives the move; the proprietary tooling does not have to.
A product team with some content in Word, some in DITA, some in AsciiDoc, and some in proprietary Markdown supersets can converge on Markdown++ as the new common source. Features that pure CommonMark lacks — variables, conditional content, content reuse, structured cross-references — are present as invisible extensions, so the consolidated source is interoperable with the wider Markdown ecosystem rather than locked into another vendor's dialect.
Markdown++ source produces measurably higher-quality input for AI retrieval workflows than binary or XML source. The Knowledge Base archive that Reverb 2.0 emits inherits the structural intent of Markdown++ extensions, which means RAG pipelines and Reverb AI chat get a direct retrieval-quality lift from migrating source first. Markdown++ output is the on-ramp; the AI-ready pipeline is the destination.
Plain-text .md files diff cleanly in Git. Pull-request reviews show the actual content change, not an opaque binary diff. Branch-based authoring, CI/CD-driven publishing, and golden-output regression testing become standard tools rather than special integrations — and documentation changes ship through the engineering organization's existing review process alongside the code they describe.
Migration tooling built in.
Markdown++ output is more than a format setting — it is a migration playbook. ePublisher ships with 13 automated cleanup capabilities that improve output fidelity during the conversion: consecutive code-fence merging, indent-style alignment, sub-step indentation, missing-inline-style restoration, escaped path handling, curly-quote replacement, and more. The cleanup runs against the generated output — the migration pattern is documented and repeatable, not a bespoke services engagement.
Round-trip validation is part of the pattern. ePublisher can publish Markdown++ from any of its supported input formats, then republish that Markdown++ source through the same publishing pipeline. Migration teams use the round-trip to validate that the converted source produces the same downstream output as the original — a test the customer can run themselves before committing to the migration.
The migration playbook is also available to AI agents. The webworks-agent-skills repository contains skills that teach Claude Code and other agents how to operate ePublisher migration workflows — turning what was historically a hand-driven services engagement into a process a customer's own team, or an agent on their behalf, can execute.
Markdown++ output vs. other ePublisher outputs.
Markdown++ output is one of several formats ePublisher generates from the same source project — but it sits at a different layer than the others. The other outputs are destinations for readers; Markdown++ is a new source format for authors.
Migrating to a new authoring format.
Right when the goal is to move source out of FrameMaker, Word, DITA, or another binary format and into
plain-text .md files. The conversion is a one-time event; once content is in Markdown++, authors work
in a code editor going forward and ePublisher continues to publish every other format.
A customer-facing portal.
Markdown++ source pairs naturally with Reverb 2.0: the Knowledge Base archive that Reverb 2.0 emits is measurably higher quality when its source is Markdown++ rather than binary or XML.
Finished deliverables.
PDF, ePUB, Eclipse Help, and the legacy help formats are reader-facing destinations. Markdown++ output is not a replacement for them — it is the source format that feeds them.
What makes ePublisher's Markdown++ output stand out.
Markdown++ as an output is unique to ePublisher
Other publishing tools either treat Markdown as a one-way input — you can author in Markdown, but you cannot export your content back to Markdown if it came from elsewhere — or treat it as a lossy intermediate format. ePublisher generates Markdown++ as a first-class output that preserves structural intent through the conversion, so the migration target is a usable, portable source format on day one.
Open standard, MIT-licensed, no vendor lock-in
Markdown++ is published as a specification under an MIT license at quadralay/markdown-plus-plus. The output ePublisher emits is not a private dialect; it conforms to the same publicly documented Markdown++ specification any other Markdown++-aware tool can consume. Customers who adopt the format own their content in a documented, vendor-neutral form. If they later choose to leave ePublisher, the source files do not become opaque artifacts.
Every Markdown++ file is a valid CommonMark document
The migration target works in every Markdown tool the team already uses. GitHub renders it for code review, VS Code previews it, MkDocs publishes it, Pandoc processes it. The ++ extensions activate when an author or build tool understands them and stay invisible everywhere else — so the team's existing tooling does not have to change in lockstep with the migration.
Migration carries structural intent, not just words
Notes, procedures, conditional text, variables, and cross-references are not flattened into prose during conversion. They become Markdown++ extensions with stable identifiers, so the converted source reads like documentation — not like a one-time export — and continues to publish through ePublisher with the same fidelity as the original.
Markdown++ source unlocks the AI-readiness story
Customers who migrate to Markdown++ source position themselves for the next wave of WebWorks capabilities — Reverb AI chat and any future agent-driven publishing pipeline. The migration to Markdown++ is the on-ramp; the AI-ready pipeline is what it makes possible.
Authoring once, publishing to any format.
Markdown++ output is part of the same ePublisher pipeline that produces every other format. The same source project that emits a Markdown++ migration target can also produce Reverb 2.0 for a customer-facing portal, Dynamic HTML for embedded in-product help, PDF for printable user guides, ePUB for e-readers, Eclipse Help for IDE-embedded help, and legacy formats like HTML Help, Oracle Help, Sun JavaHelp, and WebWorks Help — all in a single publishing run.
For a deeper look at Markdown++ as an authoring format and open standard, see the Markdown++ product page.
Ready to move your documentation off a proprietary format?
See how Markdown++ output fits your migration plan, your team's authoring preferences, and your AI roadmap. Walk through your source set with us, or start a free 14-day ePublisher trial.