「Markdown → 画像」変換写过ことがある人なら、たぶんこの罠にはまったことがあるはずです。
TEXT
Markdown → HTML → 浏览器 → 截图
すると、次のような問題によく直面します。
- chromium は重い（デプロイも面倒）
- ページ分割が不安定（実行のたびに結果が変わることもある）
- 一括レンダリングの性能が悪い
- サーバーレス環境では扱いにくい 最近この一連の流れに少し飽きてきたので、自分で作りました。 marknative ---
コアアイデア（既存のアプローチとはまったく違う）
HTMLもDOMもブラウザも使いません。
代わりに：
TEXT
Markdown → AST → 自定义文档模型 → layout → 分页 → canvas 绘制
簡単に言うと：
「ブラウザのレイアウト処理」を、Markdown 専用に最小限の形で自作する、という考え方です。
---
何ができる？
1. PNG / SVG を直接出力
TypeScript
import { renderMarkdown } from 'marknative'
const pages = await renderMarkdown('# Hello')
await Bun.write('page-1.png', pages[0].data)
以下は不要です。
- puppeteer
- headless chrome
- スクリーンショット ---
2. 標準でページ分割に対応（しかも安定）
デフォルト設定は次のとおりです。
- 1080 × 1440
- カードに近い縦横比 しかも、ページ分割は決定的です。
- 同じ Markdown なら
- どんな環境でも
- レンダリング結果は一貫します --- ### 3. コンテンツの一括生成に向いている たとえば：
- 小红书向けカード
- 技術記事用のビジュアル
- AIが自動生成するコンテンツ画像 puppeteer と比べると：
- 起動が速い
- 使用メモリが少ない
- スケールアウトしやすい --- ## この方向性には価値がある
本質的に、この種の要望は結局こういうものです。
「構造化テキスト → 制御可能なレイアウト → 画像出力」 一方、ブラウザは：
- 汎用性が高すぎる（Webページ向けに設計されている）
- 制御しにくい（CSS + レイアウトが複雑すぎる）
- コストが高すぎる Markdown を扱う場面では：
- 構造が固定されている
- 制約できる
- 専用レイアウトエンジンに非常に適している --- ## 技術ポイント（面白いものをいくつかざっと紹介）
micromark+mdastで解析- block / inline のレイアウトを自作
skia-canvasで直接描画- layout と render を完全に分離 そのため理論上は、次のような拡張が可能です。
- renderer（SVG / PDF / WebGL）を差し替える
- カスタムテーマシステムを作る
- ビジュアルエディタを作る（将来的に） --- ## プロジェクトリポジトリ
👉 https://github.com/liyown/marknative