WindowsでMarkdownをPDFにオフライン変換する方法
Windows 11でMarkdownをローカルにPDFへ変換し、見出し、コード、表、Unicode、ローカル画像、生成された全ページを確認する方法。
この記事の内容
Markdownは、文書を編集している途中に扱いやすい形式です。元データはプレーンテキストなので、差分を確認しやすく、専用エディターがなくても読めます。一方、相手に渡す段階では、ページ構成が固定され、同じように開いたり印刷したりできるPDFのほうが適していることがあります。
Windows 11のLocalFluxを使うと、.mdファイルを変換サイトへアップロードせず、別のPDFとして保存できます。このガイドの検証では、見出し、リスト、引用、表、コードブロック、Unicode文字、文書内リンク、ローカルのLocalFluxロゴを含むMarkdownから、3ページのA4 PDFを作成しました。元のMarkdownは変更されていません。
適している用途: メモ、README形式の配布資料、技術手順、会議の要約、自然な改ページを許容できるレポート。
把握しておく制限: この変換経路では、外部Webリンク、Web画像、生のHTMLが拒否されます。また、Markdown自体は印刷余白、ヘッダー、フッター、強制改ページを定義しないため、精密なページレイアウトソフトの代わりにはなりません。
最短手順
- Markdownとローカル画像を、移動しない作業フォルダーに置きます。
- LocalFluxを開き、
.mdファイルを追加します。 - Convertを選択したまま、出力にPDFを指定します。
- キューにMarkdown → PDFと表示されていることを確認します。
- Convert 1 fileを選択します。
- 新しい
_converted.pdfを開き、すべてのページを確認します。 - 見出し、表、コード、画像、リンク、日本語などの文字を確認します。
- 編集用の原本として
.mdを残します。
Microsoft StoreでLocalFluxを入手するか、作業前に現在対応している変換経路を確認してください。
MarkdownからPDFへの変換で変わるもの
CommonMarkは、Markdownを構造化文書のためのプレーンテキスト形式として定義しています。記号を使って見出し、強調、リスト、引用、コード、リンク、画像を表現します。これに対しPDFは、ページ、配置済みテキスト、画像、フォント、リンク注釈など、完成した表示結果を記録する形式です。
したがって、変換は拡張子の変更ではありません。LocalFluxはMarkdown構造を解析し、ローカルで文書表現を準備して、同梱の文書ランタイムから新しいPDFを書き出します。PDFは配布用コピーであり、Markdownが編集可能な原本として残ります。
この違いから、次の2点が重要になります。
- 問題がなくても、PDFは
.mdより大幅に大きくなる場合があります。 - 変換完了は確認作業の開始点です。改ページやフォント置換は、生成されたページを見なければ判断できません。
実際の文書を代表するMarkdownを用意する
本番の文書に表、コード、画像、多言語テキストがあるなら、1行だけのメモでワークフローを検証してはいけません。レンダリング時に変化しやすい要素を含む、代表的なサンプルを使います。
この記事のテストファイルには、次の内容を入れました。
- ATX形式の見出しと通常の段落
- 太字、斜体、インラインコード
- 番号付きリストと箇条書き
- 引用と水平線
- Markdownの表
- PowerShellのフェンス付きコードブロック
- 文書内フラグメントリンク
café、résumé、naïve、日本語- ローカルの
file:///URIで参照する、リポジトリ由来のLocalFluxロゴ
テスト用Markdownはこの記事のために作成し、ロゴはLocalFluxリポジトリの素材から派生させました。顧客データは含まれません。ロゴはローカルファイルURIから読み込まれ、変換中にWeb画像を取得しません。
検証した画像指定は次のとおりです。
これは、明示的なローカルURIが検証対象の1.0.8で動作したことを示します。元ファイルや画像を移動した場合はURIを更新し、もう一度変換してください。文書処理の途中で中間ファイルが別フォルダーに置かれると、相対画像パスが解決できないことがあります。
検証に使ったMarkdown入力、ローカルロゴ、生成PDFをダウンロードできます。
手順1：Markdownファイルを追加する
LocalFluxを開き、.mdをウィンドウへドラッグするか、Add filesを選択します。Convertを選択したまま出力をPDFにし、開始前にキューの行を確認します。
キューにはMarkdown → PDFと表示されています。公開画像に個人のWindowsプロファイルを出さないよう、作業パスにはC:\tmpを使用しました。
別の経路が表示されている場合は、変換前に出力形式を修正します。複数ファイルを処理するときは、同じ出力形式と同程度の確認が必要な文書をまとめてください。短いメモと長い技術資料はどちらもMarkdownですが、改ページのリスクは異なります。
手順2：新しいPDFへ変換する
Convert 1 fileを選択します。LocalFluxは既定で元ファイルと同じ場所に出力し、ファイル名へ_convertedを追加します。今回の結果は次のとおりです。
- 入力:
localflux-markdown-guide.md - 出力:
localflux-markdown-guide_converted.pdf - 元ファイル: 3,713バイト
- 出力ファイル: 194,305バイト
- 変換前後の元ファイルSHA-256: 同一
アプリには3.6 KB → 189.8 KB, larger than originalと表示されました。これは警告ではなく、結果の説明です。プレーンテキストは表示情報をほとんど持ちません。PDFにはロゴのほか、文字や記号を再現するためArial、Times New Roman、Consolas、OpenSymbol、NSimSunのフォントサブセットが埋め込まれました。
MarkdownからPDFへの変換は、圧縮作業ではありません。目的は元ファイルより小さくすることではなく、渡せる固定文書を作ることです。
手順3：PDFの全ページを確認する
普段使うPDFリーダーで出力を開き、読みやすい倍率で確認します。Microsoft EdgeにもPDF表示と印刷プレビューがありますが、重要なのはアプリに依存しない習慣です。1ページ目だけでなく、すべてのページを見てください。
1ページ目では、タイトル階層、ローカルロゴ、太字、引用、インラインコード、リストが保持されています。
次の問題がないか確認します。
- 表の列やコード行が切れていないか
- 画像が消えたり、文字が四角に置き換わったりしていないか
- 意図しない空白ページがないか
- ページ末尾に見出しだけが残っていないか
- リスト番号が途中で再開していないか
- リンクの表示と移動先が一致しているか
- 最終ページにあふれや欠落がないか
3枚のA4ページを画像としてレンダリングし、確認しました。テキスト、ロゴ、表、コードブロックの切れや、空白ページはありませんでした。
保存したPDFはqpdf --checkの構造検査にも合格しました。テキスト抽出では、テストしたアクセント付き文字と日本語をすべて取得できました。文書内のVerification notesリンクは、PDF内の目的位置を指すリンク注釈になりました。構造検査とテキスト抽出は視覚確認を補いますが、代わりにはなりません。
LocalFlux 1.0.8での実測結果
| 項目 | 確認結果 |
|---|---|
| 元ファイル | 3,713バイトのUTF-8 Markdown |
| 出力 | 194,305バイトのPDF 1.7 |
| ページ数 | 3 |
| ページサイズ | 全ページA4、595.304 × 841.890ポイント |
| PDFタイトル | localflux-markdown-guide |
| Producer | LibreOffice 26.2.4.2 (X86_64) |
| 画像 | 各ページに1個の画像リソース |
| 文書内リンク | 2ページ目に1個のリンク注釈 |
| フォント | データを埋め込んだ7個のTrueTypeサブセット |
| 構造検査 | 合格、構文エラーとストリームエラーなし |
| 元ファイル保持 | Markdownとロゴのハッシュは変化なし |
これらは、管理された1個のテストファイルと保存済みx64パッケージについての値です。すべてのMarkdownに同じ結果を約束するものではありません。ページ数やサイズは、文章量、画像サイズ、表、コード行、フォント、Unicode文字によって変わります。
どのMarkdown書式を試すべきか
この変換はCommonMark系のパーサーと拡張Markdown機能を使用します。今回のテストでは、通常の見出し、強調、リスト、引用、フェンス付きコード、表、画像、文書内リンク、Unicodeテキストが正しく出力されました。
Markdownの実装によって、拡張機能や曖昧な記法の解釈は異なります。CommonMarkはその差を減らすための仕様で、Markdigは.NET向けの拡張可能な処理系です。タスクリスト、脚注、独自属性、図、数式、アプリ固有の命令に依存する文書では、フォルダー全体を変換する前に、その記法を含む実ファイルで試してください。
予測しやすい原稿にするには、次を意識します。
- 表、リスト、引用、コードフェンスの前後に空行を入れる
- 縦向きページに収まる幅の表にする
- 不要に長いコード行を避ける
- 色だけで重要な情報を伝えない
- 意味のある代替テキストを書く
- 英語以外の名前や言語がある場合は、代表的なUnicode文字を含める
改ページ、余白、ヘッダー、フッター
Markdownが表すのは文書構造であり、物理的なページ設計ではありません。A4とLetter、印刷余白、ランニングヘッダー、ページ番号、共通の強制改ページ命令は定義していません。
検証したLocalFluxの経路は、印刷レイアウトエディターではなく直接変換です。このサンプルは自然に3枚のA4へ分かれましたが、任意の余白、ヘッダー、フッター、正確な改ページ位置を指定する機能はありません。生のHTMLも拒否されるため、回避策にはなりません。
通常のページフローを許容できる文書でこの方法を使ってください。契約書、書籍、ブランド提案書、規制対象フォームなど、配置を正確に決める必要があるものは、ページ設計ができるツールで仕上げてから書き出します。
外部リンクとWeb画像が拒否される理由
この経路は、ローカル変換の境界を明確にしています。[example](https://example.com)のようなリンクやWeb画像URLがあると、検証したバージョンは外部リソースを取得せずに停止し、修正方法を表示します。
英語の原文メッセージは「Markdown containing remote web links or images isn’t supported. Remove the remote web references and try again.」です。
生のHTMLを含むテストでは、**「Markdown containing raw HTML isn’t supported. Remove the HTML tags and try again.」**と表示されました。拒否された2個のファイルからPDFは作成されていません。
一般のWebリンクは変換前に削除するか、別の表現に書き換える必要があります。一方、[Verification notes](#verification-notes)という文書内リンクはPDF内に残り、正しく動作しました。この制限には再現性の利点もあります。結果が外部サーバーの稼働状況や、後から変更されるWeb画像に左右されません。
フォントとUnicodeは実際の字形を確認する
変換が完了しても、想定したフォントがすべてのPCにあるとは限りません。代替フォントによって折り返し位置が変わったり、必要な字形がなかったりする可能性があります。
今回のPDFには7個のTrueTypeサブセットが埋め込まれ、café、résumé、naïve、日本語が表示されました。テキスト抽出でも同じ文字列を取得できました。ただし、数式、絵文字、右から左へ書く言語、まれなCJK文字を含む文書には、それぞれのテストが必要です。
書体が重要な場合は、元のプレビューとPDFページを比較し、特殊文字を拡大して、表やコード付近の折り返しも確認します。ブランド指定フォントを正確に使う必要がある場合は、埋め込みとライセンスを適切に管理できる制作ワークフローを使用してください。
Markdownを安全に一括変換する
互換性のある複数のMarkdownをLocalFluxのキューへ追加できます。ただし、キュー全体の成功表示は、各PDFの内容を承認したことにはなりません。まず長く代表的なファイルを1個変換し、その後に各出力を確認します。
- 各Markdownとローカル素材を安定した場所に置きます。
- 外部参照と生のHTMLを削除します。
- 精密なレイアウトが必要な文書を、自然な流れを許容する文書から分けます。
- フォルダー全体の前に、条件の厳しいファイルを1個試します。
- 各PDFを開くか、少なくとも全ページをレンダリングして確認します。
- 修正用に元のMarkdownを残します。
- 再現可能な記録が必要なら、重要な原稿をハッシュ化またはバージョン管理します。
よくある質問
WindowsでアップロードせずにMarkdownをPDFへ変換できますか？
はい。今回のLocalFlux検証はWindows 11 x64環境でローカルに実行し、元ファイルと同じ場所へPDFを作成しました。変換作業にアップロード手順はありません。
元のMarkdownは上書きされますか？
いいえ。LocalFluxはlocalflux-markdown-guide_converted.pdfを新しく作成し、元のMarkdownのハッシュは変わりませんでした。
PDFにロゴを入れられますか？
はい。ただし今回確認したのは、ローカルPNGをfile:///C:/.../localflux-logo.pngで明示したケースです。画像を同じ場所に保ち、ファイルを移動したら再テストしてください。
PDF内でWebリンクは使えますか？
検証対象の経路は、http://とhttps://の外部リンクを拒否します。サンプルの文書内フラグメントリンクは、PDFリンク注釈として機能しました。
HTMLで強制改ページできますか？
できません。生のHTMLは拒否され、この直接変換には強制改ページの設定がありません。正確な改ページが必要ならレイアウトツールを使います。
PDFがMarkdownより大きいのはなぜですか？
Markdownは小さなプレーンテキストです。PDFにはページ座標、フォントデータ、画像など、固定表示に必要なリソースが入ります。今回のように出力が大きくなるのは正常です。
公開用の検証資料をダウンロードする
サンプルは記事用に作成し、ロゴはリポジトリで管理されています。技術資料は、文章、測定値、ハッシュを1つのレビュー済み証拠に結び付けるため、英語版を正式記録としています。
原本を残し、配布用コピーを確認する
信頼できるMarkdownからPDFへの作業では、役割の異なる2つのファイルができます。Markdownは編集とレビューのための原本です。PDFは配布、印刷、保管のための固定コピーです。
依存素材をローカルに置き、実際の文書を代表する原稿を使い、新しいファイルへ変換して、全ページを確認してください。ファイル名や緑色の完了表示ではなく、この最終確認によって、変換結果が安心して渡せる文書になります。
LocalFluxでMarkdownをローカルにPDFへ変換するか、対応形式を確認してください。