# PDF 公式轉 Markdown：分別檢查運算式與渲染器

將 PDF 公式轉成 Markdown 時，如何檢查公式輸出、行內與區塊數學、公式編號，以及編輯器的支援情況。

把含有公式的 PDF 轉成 Markdown 之後，文字表示法和實際渲染出來的公式都要檢查。運算式可能被辨識錯，也可能是文字正確、但目標編輯器不知道怎麼顯示。這是兩個不同的問題。

先別急著改符號，先確認自己遇到的是哪一種問題。把原始 PDF 開在旁邊當作對照。

## 先確認每個公式以什麼形式呈現

用純文字編輯器開啟下載下來的 Markdown，找出一條行內運算式和一個獨立顯示的公式，看看結果用的是數學標記、一般文字，還是連出去的圖片。直接看檔案裡實際有什麼，不要預設每次轉換都會用同一套寫法。

連出去的圖片能保留公式的外觀，但不是可編輯的數學內容。標記語法或許可以編輯，前提是你看得懂語法，而且拿它跟原稿比對過。純文字則可能漏掉原本靠上下位置或版面安排表達的關係。

PDF Craft 會在[PDF 轉 Markdown 的流程](https://pdfcraft.ai/zh-Hant/pdf-craft/pdf-to-markdown/)中辨識公式。但這不代表每個運算式都正確、可編輯，或每個 Markdown 編輯器都支援。

## 行內數學與獨立公式要分開處理

行內標記是句子的一部分。檢查標點、單位和後面的字有沒有留在運算式外面。分隔符號放得太晚，原本的普通文字就會被當成數學式渲染。

獨立顯示的公式自成一個區塊。多行對齊、分數、矩陣、分段函數和續行，都要跟 PDF 對照。有時候只是換行位置跑掉，所有符號都還在，但哪些項該放在一起已經變了。

如果編輯器支援以錢字號包住數學式，手寫的範例大概長這樣：

```markdown
行內公式範例：$y = ax + b$。

$$
y = ax + b
$$
```

這只是語法示意，不是保證 PDF Craft 會匯出成這樣。[CommonMark](https://spec.commonmark.org/) 並沒有定義通用的數學擴充語法。你的目標環境可能要求不同的分隔符號，也可能直接把語法原樣顯示出來。

## 符號與公式編號要分開核對

下標、次方、希臘字母、正負號、括號和運算子的上下限，逐一跟原稿比對。不要只因為書中其他地方用了比較眼熟的符號，就把這裡的變數換掉。

公式編號和正文中對它的引用也要檢查。PDF 右緣印出的編號，可能不小心被併進運算式，或跑到別的公式旁邊。「使用式 (7)」必須仍然指向原本那個關係。

定義公式的那句話也要讀。假設條件、單位或邊界條件漏掉，就算公式本身抄對了，意思也可能被誤解。[公式 OCR 檢查指南](https://pdfcraft.ai/zh-Hant/blog/math-formulas-scanned-pdf/)有更詳細的來源影像辨識說明；這裡要確認的是，公式轉成 Markdown 後，在閱讀時仍能正確顯示。

## 在實際存放筆記的編輯器裡測試

在打算使用的應用程式裡開啟一份副本，把渲染結果和原始 Markdown 並排比對。如果文字正確、畫面上卻少了某個符號，先確認渲染器支不支援，再決定要不要動公式本身。

舉例來說，Obsidian 在[進階格式](https://obsidian.md/help/advanced-syntax)文件中說明了它的數學語法。那是外部編輯器自己的功能，不是 PDF Craft 的整合功能。換一套筆記軟體，同一份原始碼可能渲染出不同結果。

不要只測最簡單的一行。挑一個分數、一個帶下標的變數、一個有編號的公式，以及工作中會用到的多行運算式一起測。如果渲染器無法穩定呈現某種結構，在改用其他表示法之前，先保留來源圖片或原頁參考。

## 修正時留下依據

原始 PDF、未經修改的匯出檔和修正後的工作檔都要留著。記錄來源頁碼、公式編號、發現的問題，以及確認過的修正內容。還沒解決的運算式先標記起來，不要讓 AI 助理憑記憶補上一個看起來合理的版本。

要用某個運算式計算或引用之前，先照你工作所需的標準請人核對。Markdown 檔渲染得再漂亮，也不等於數學驗證。

把檔案併入[研究筆記](https://pdfcraft.ai/zh-Hant/blog/pdf-to-markdown-for-research/)時，公式要連同來源位置一起帶過去。日後讀到的人應該能追回原本的關係，而不是只看到某個編輯器剛好顯示正確的版本。