https://github.com/cosmiciron/vmprint-transmuters
A collection of specialized source-to-AST transmuters for the VMPrint ecosystem. Converts Markdown (and future formats) into VMPrint's native DocumentInput representation. 🚀 Official part of the VMPrint project: https://github.com/cosmiciron/vmprint
https://github.com/cosmiciron/vmprint-transmuters
document-conversion layout-engine pdf-generation puppeteer typesetting typst vmprint
Last synced: about 24 hours ago
JSON representation
A collection of specialized source-to-AST transmuters for the VMPrint ecosystem. Converts Markdown (and future formats) into VMPrint's native DocumentInput representation. 🚀 Official part of the VMPrint project: https://github.com/cosmiciron/vmprint
- Host: GitHub
- URL: https://github.com/cosmiciron/vmprint-transmuters
- Owner: cosmiciron
- License: apache-2.0
- Created: 2026-03-25T02:25:29.000Z (3 months ago)
- Default Branch: main
- Last Pushed: 2026-04-17T03:01:33.000Z (2 months ago)
- Last Synced: 2026-04-17T05:09:03.287Z (2 months ago)
- Topics: document-conversion, layout-engine, pdf-generation, puppeteer, typesetting, typst, vmprint
- Language: TypeScript
- Homepage: https://cosmiciron.github.io/vmprint/
- Size: 170 KB
- Stars: 1
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# ⚠️ Repository Moved to Monorepo
This repository is now deprecated and is no longer maintained here. All development, issues, and pull requests have been moved to the primary monorepo:
👉 **[vmprint](https://github.com/cosmiciron/vmprint)**
Please update your bookmarks and direct any contributions or issues there. Thank you!
---
# VMPrint Transmuters
> 🚀 **Part of the [VMPrint Ecosystem](https://github.com/cosmiciron/vmprint)**
A transmuter converts a source format into VMPrint's native intermediate representation — `DocumentInput` — without touching the layout engine.
## Why transmuters exist
The VMPrint engine speaks exactly one language: `DocumentInput` JSON. This is intentional. The engine has no knowledge of Markdown, DOCX, LaTeX, or any other authoring format. That separation keeps the layout core deterministic and format-agnostic.
Transmuters are the bridge. Each one takes a human-authored source and produces a `DocumentInput` object the engine can ingest directly. They are deliberately kept thin:
- **No file access.** No `fs`, no I/O. Input and output are plain in-memory values.
- **No engine dependency.** Transmuters do not import `@vmprint/engine`. Types are declared locally and kept structurally compatible.
- **Embeddable anywhere.** Browser, Node.js, edge worker, build plugin — the same package works in all of them.
## Naming convention
Directories follow `{source}-{target}` where both sides use short format identifiers:
| Identifier | Meaning |
|---|---|
| `mkd` | Markdown (CommonMark + GFM extensions) |
So `mkd-mkd` is the Markdown → `DocumentInput` transmuter. The second `mkd` here refers not to a different Markdown dialect but to the vmprint IR whose semantic elements (`heading-1`, `paragraph`, `blockquote`, …) mirror the block-level vocabulary of Markdown — it is the natural structural target for markdown source.
## Transmuters in this repo
| Directory | Package | Source |
|---|---|---|
| `markdown-core/` | `@vmprint/markdown-core` | Shared Markdown → `DocumentInput` compiler core |
| `mkd-mkd/` | `@vmprint/mkd-mkd` | Markdown → `DocumentInput` |
| `mkd-academic/` | `@vmprint/mkd-academic` | Markdown → `DocumentInput` (academic defaults) |
| `mkd-literature/` | `@vmprint/mkd-literature` | Markdown → `DocumentInput` (literature defaults) |
| `mkd-manuscript/` | `@vmprint/mkd-manuscript` | Markdown → `DocumentInput` (manuscript defaults) |
| `mkd-screenplay/` | `@vmprint/mkd-screenplay` | Markdown → `DocumentInput` (screenplay defaults) |
## Relationship to draft2final
`draft2final` is now a thin, transmuter-first orchestrator. It selects a transmuter, loads user-editable config defaults, resolves optional themes, and then renders either PDF or AST JSON output.
Transmuters remain the lower-level primitives: `source text` in, `DocumentInput` AST out. They are where source-format semantics and default conventions live. This keeps heavy regression coverage at the transmuter level while the CLI stays lightweight.
## Local dev loop
For rapid local testing of a transmuter plus theme/config YAML, use the workspace dev CLI:
```bash
npm run dev:transmute -- sample.md --as mkd-mkd --theme ./theme.yaml --out ./sample.pdf
```
Or point directly at a transmuter source module:
```bash
npm run dev:transmute -- sample.md --transmuter ./mkd-mkd/src/index.ts --out ./sample.json
```
## Adding a new transmuter
Shared transmuter contract types live in [`@vmprint/contracts`](https://www.npmjs.com/package/@vmprint/contracts).
A transmuter should satisfy the shared `Transmuter` contract and may also export a convenience function:
```typescript
interface Transmuter {
transmute(source: Input, options?: Options): Output;
}
```
It should have no runtime dependency on `@vmprint/engine` and no file-system access. Themes and config are passed as strings or plain objects by the caller.