2 ポイント 投稿者 GN⁺ 2026-04-29 | 1件のコメント | WhatsAppで共有
  • Markdownベースの文書作成にLaTeXレベルの組版機能を組み合わせ、論文から書籍・プレゼンテーション・静的サイト・ナレッジベースまでを1つのツールで構成可能
  • ボイラープレートを減らした構文の中に、著者、余白、要約、画像、引用文といった要素を直接書き込めるため、本文とレイアウトを一緒に記述できる
  • 1行の .doctype 設定paged, plain, docs, slides の文書タイプを切り替えられ、インタラクティブなプレゼンテーションにも対応
  • 高速コンパイルとライブプレビューを提供し、Turing complete なスクリプティングにより、関数や引数の再利用を通じて反復的なレイアウト作業を減らせる
  • 無料で オープンソース として提供され、コンパイラは継続的に進化しており、自由ソフトウェアとして維持されている

2.0.0 リリースの変更点 : 2026年4月23日にリリース

  • HTML出力が完全オフライン方式に変更され、CDN・Google Fonts 依存によって発生していたスタイル崩れや機能欠落が大幅に減少
  • 新しい 権限システム が追加され、コンパイル中に文書がアクセスできる範囲を --allow, --deny で制御できるようになり、権限がなければ即座にエラーを出すため安全性が向上
  • デフォルトの出力ディレクトリが ./output から ./quarkdown-output に変更され、従来のデフォルトパスに依存していたワークフローは調整が必要
  • --preview 使用時のデフォルト出力名が、もはや .docname ベースではなく preview-<mainfile>-<hash> 形式に変更され、プレビューの安定性が向上
  • 並列レンダリング が導入され、大きな文書で兄弟要素を同時に処理できるようになり、レンダリング性能が改善
  • プロジェクトルートの public/ ディレクトリ を HTML成果物のルートへそのままコピーできるため、robots.txt, CNAME, 共通の静的アセットの配布が容易に
  • 新しい .htmloptions 関数で baseurl を設定すると、各ページに canonical link を挿入し、sitemap.xml も生成できるため、検索エンジンへの親和性が向上
  • HTMLコンパイル時にリンクと画像で @ ルートパス記号 をサポートし、サブドキュメントのどこからでも共通アセットを一貫して参照可能に
  • 新しい .image primitive function が追加され、サイズ・キャプション・固定相対パス使用の有無まで細かく制御でき、public/ アセット活用とも相性が良い
  • すべての参照可能要素に対する相互参照リンク をサポートし、図、表、コードブロック、数式、ユーザー定義の番号付きブロックにもクリックで移動可能に
  • Injection 標準ライブラリモジュール名が Html に変更され、既存文書や参照コードの修正が必要
  • ダークテーマのライブプレビューで発生していた白いフラッシュや Quarkdoc wiki リンク の問題も修正され、使用感が改善

1件のコメント

 
GN⁺ 2026-04-29
Hacker Newsの意見
  • 正直、印象的ではあるけれど、自分にとってMarkdownの核心は極端なまでの単純さにある
    GUIがなくても編集できるし、ターミナルのVIMで書いていても結果がだいたいどうなるか見当がつくし、生の.mdファイル自体もそのまま読みやすい
    でもそこに機能をどんどん積み始めると、見慣れないコマンドを何度も調べることになり、結局は覚えられず、レンダリングなしでは見た目にも自信が持てなくなって、WYSIWYGエディタが欲しくなる
    QWERTYキーボードにキリル文字、デーヴァナーガリー、中国語、アラビア語のキーまで全部載せようという発想に近く見えて、そうなると結局またhunt and peckに戻る感じがする

    • 自分にとってMarkdownの大きな利点のひとつは、半分WYSIWYGであること
      基本文法が、もともと人々がテキストで書式を真似していたやり方を再利用しているので、入力自体がそのままだいたい読みやすい
      Markdownの書き方を正確に知らなくても、たいてい読むのに困らないし、表は表に見えるし、段落はただの段落に見える
      ときどき文法を調べ直すことはあるけれど、それは別に構わない。能動語彙より受動語彙のほうが大きいのは自然なことだ
      だから自分は入力された原文の可読性で判断するほうだが、ここで示されているものの多くは、その基準ではあまり大きな得失があるように見えない
      ただ、数式フォーマットの例は見ておらず、自分がLaTeXを使う数少ない場面もたいていMarkdownでは書けない数式が理由なので、その部分が実際どう見えるのかは気になる
    • その主張はかなり説得力がある
      それでもQuarkdownは、LaTeXを直接打つよりは明らかに上位互換に見えるし、WordのようなGUIエディタよりも結果の予測しやすさやLLM補助編集との相性も良さそうだ
    • 変な新コマンドを覚える必要もなく、洗練されたUI/UXまで備えた、もっと超能力的なQuarkdownを作ればいい
      名前はMicrosoft Wordでいいだろう
    • 自分も小さなMarkdown rendererを作っているが、名前を付けるだけでも難しく、完成しても人に使ってもらうのはもっと難しい
      最近は普通の"plain markdown"エディタだけでは目立ちにくく、HNのトップページまで行くには結局、一般的なMarkdownを超える機能性と完成度が必要なのだと思う
      一種の自然選択のように感じる
    • Obsidian.mdは基本的なMarkdown向けのWYSIWYGエディタとして本当に素晴らしい
  • こうしたツールやマークアップ言語を一度に比較した資料があるといい
    MySTPandocQuarkdownQuartoTypstを並べて見てみたい
    QuartoとPandocはPandoc Markdownを使っていて、https://www.zettlr.com/も同様だ
    一方でQuarkdownとTypstはLaTeXやHTML+Javascript寄りのプログラマブルなマークアップ言語という感じなので、まだ誰が本当のLaTeXの後継になるのかは決まっていないように見える

    • ほとんど全部実際に使ったことがあり、今後も使うつもりだが、ざっくり言えばこう分類できる
      Markdownは.txtに少しだけ文法的な糖衣をかけたもので、PDFやHTMLにエクスポートできる
      Quartoはコードブロックを実行したいMarkdownで、
      Typstは現代風に作り直したLaTeXで、ごちゃごちゃした部分が90%減った代わりに機能も10%くらい抜けている感じだ
      学界はもともと新しいものを嫌うので、Typstを使っても歓迎されない可能性が高い
      Pandocは結局のところPDFやHTMLのような各種フォーマットへエクスポートするためのツールだ
      たいてい必要な道具がどちら側かはすぐ分かるし、asciidocのようなものもあるが、markdown/quarto/typstの組み合わせでカバーできない領域が何かと考えると、それほど多くはない
      せいぜい残るのはWYSIWYGエディタくらいだ
    • 比較リストにはdjotも入れる価値がある
      Markdownのよく設計された、かなり徹底したsupersetに見える
      https://djot.net/
    • Typstは本当に好きになりたかった
      LaTeXをもう使わずに済むなら最高だったが、実際のプロジェクトで使ってみるとコーナーケースが多すぎて、結局またLaTeXに戻った
      LaTeXにあって欠けている部分もあるし、Pandocとの変換性が弱いのも大きかった
      最後の10%が埋まってくれることを本当に願っている
    • そういう比較のことなら、すでにある
      https://github.com/iamgio/quarkdown#comparison
    • Pandocは他のツールとはレイヤーが違う
      中間のJSONフォーマットに対して任意のフィルタを掛けられるので、望む変換は事実上なんでも実装できるし、各種フォーマットをそのJSONに、またはその逆に変換してくれる
      だから自分はPandocベースのシステムを好んでいて、標準ツールでできないことも簡単なinline filterで解決できることが多い
  • 物理ソフトウェア標準モデルによれば、QuarkdownはAtomで編集するとQuarkupになり、Neutron MailはProton Mailに替えなければならない
    ただし、左手でタイピングしながらElectronアプリを作り、anti-Neutrinos AI blogpostまで書いてはじめて動作する

  • 短く評するなら、これは実質的にLaTeXスタイルのマクロを入れたMarkdownに近い
    ただしここではそれを関数と呼んでいて、おそらく副作用のある関数が少なくともひとつはあるからだろう。新しい関数を定義するその関数のことだ
    「すべてが関数」という文法的な純粋さは気に入っているが、構造とスタイリングをHTML/CSS風に自然に混ぜているのは少し微妙だ。もっとも、その境界自体ももともと曖昧ではあった
    それでもかなりクールだし、Markdownを大きく変えようとする試みに懐疑的な反応が多いのも理解できる
    関数を使いすぎると原文の可読性が落ちるという批判ももっともで、ときにはチューリング不完全性が利点になることもある
    しかしMarkdownに関数を加える設計として見るなら、これはかなりクリーンなデザインの部類だと思う

  • 自分はQuarkdownの作者であり、プロジェクトリードだ
    最初は大学の研究プロジェクトとして始まったが、2年後にこんな姿になるとは想像もしていなかった
    関心を持ってくれてありがとう。コメントにはできるだけ返信していくつもりだ

    • v3で太字記法を「直す」つもりがあるのか気になる
      自分はずっと、**bold***italic*よりも*bold*_italic_のほうが理にかなっていると思ってきた
      Markdownの余分なアスタリスク1個は設計としていまひとつだし、特にスマホやタブレットでMarkdownを書くときにはかなり不便だ
    • テキストフォーマットに関数を入れるという発想はかなり新鮮に感じる
      GUI文書でもマクロは普通あまり使わないものだし、Quarkdownはもともと複雑で反復的な文書のために設計されたのか気になる
      質問を受け付けてくれてありがとう
    • https://iamgio.eu/2025-12-10-accidentally-in-silicon-valley/を読んだが、うまく進んでいるようでうれしい
  • ドキュメントをざっと見た限り、評価モデルがこの作業に向いているのか少し心配だ
    テキストレイアウトでは、ある部分を調整すると別の部分の配置が崩れて再度レイアウトパスを回す必要があることが多く、不動点に達するまで反復する構造が必要になる
    Typstにはそのためのcontextという概念があるが https://typst.app/docs/reference/context/、Quarkdownでは似たものを見かけなかった。見落としているだけかもしれない
    自分は本の作業でpandoc/md/LaTeXの組み合わせからTypstに乗り換え、かなり満足している
    モダンな言語でプログラミングしている感覚が心地よく、速度もpandoc+LaTeXよりずっと速い
    https://functionalprogrammingstrategies.com/

  • AsciiDocの側から見ると、Quarkdownの文法設計はクリーンに見えるし、とくにユーザー定義関数が良い
    ただ、この種のものでもっと難しいのは、ソース言語そのものより出力パイプラインだと感じる
    相互参照、admonition、条件付きコンテンツ、関数ベースの再利用のようなMarkdown拡張は、設計次第で十分扱える
    本当の壁はその先で、たとえばPDF/UAに準拠したtagged PDF、環境が違っても揺れないdeterministic build、多言語ドキュメントサイトにおけるhreflangやcross-document linking、500ページの本でも耐えるincremental rebuildといったものだ
    とくにEUでは、2025年6月28日にEuropean Accessibility Actが施行された後、PDF/UAの重要性がさらに高まった
    4つのdoctype、とくにpagedをどう進めていくつもりなのか気になる

  • 比較表にはMySTも入るべきだ
    https://mystmd.org/
    こちらが今後の新しいMarkdown標準になる可能性もありそうだ

    • あるいはTypstも入れる価値がある
      Markdown拡張ではないが、目標やユースケースがかなり近い
    • MyST + Sphinxの組み合わせはとても良い
      ただ、強力なLSPサポートが惜しく、少なくとも自分はhelixでうまく動かせなかった
      自分のブログもpydata-sphinx-themeとmystで作っている
    • そのあたりは詳しくない
      よければPRで表を直接更新してほしい
  • 自分のアプリでは少し違うアプローチを取った
    可読性と大きなMermaidダイアグラムを扱いやすくすることに集中し、最近では地図のようにたどれる全画面モードも追加した
    https://mdview.io/s/97af684b

  • 自分はSSGを使うとき、入力はできるだけクリーンなMarkdownのままにして、書式の詳細はCSSに寄せるほうを好む
    たとえば.abstractのようなものをわざわざ書かなくても、CSS側で最初の段落をabstractとして扱えばいい
    それに対してこのプロジェクトは、より豊かな自己完結型ドキュメントを作る方向に見える
    CSSはないが、あらかじめ定義されたスタイリングオプションが多く、そのせいで初期のHTMLを思い出す
    HTML 1には色もほとんど書式もなくMarkdownに近かったが、HTML 3あたりになるといろいろ入り始めたので、その流れに似ているように見える