軟體PDF 閱讀原理：為什麼註解標記
這個設計的實務意義非常大：它讓「唯讀」與「可註解」可以並存，也讓數位簽章的驗證邏輯有了依據——簽章簽的是當時的位元組範圍，後續的增量更新可以被獨立辨識出來。
也正因如此，你會看到某些 PDF 越註解越大、開啟越來越慢，因為它累積了十幾層增量更新。此時用「另存新檔」讓軟體做一次線性化重寫（rewrite / optimize），把多層修訂合併成單一結構，檔案就會瘦回來。這是評測閱讀器時一個很實用的觀察點：好的軟體會在存檔時主動提示「壓縮並最佳化」。
二、PDF 閱讀軟體的渲染管線：從位元流到螢幕像素
理解結構之後，我們來看軟體「畫」出頁面的過程。這個過程通常稱為渲染管線（rendering pipeline），大致可以拆成五個階段，而註解是在最後階段才被疊上去的。
2.1 解析、解碼、字型對應與文字定位
第一階段是解析與解碼。閱讀器先讀 xref，建立物件索引，然後針對每一頁取出內容流。內容流通常是 FlateDecode（zlib）壓縮的，也可能是 LZW、ASCII85、RunLength 等。解壓後得到的是一連串內容流運算子（content stream operators），例如：
BT /F1 12 Tf ... ET：開始文字物件、設定字型與大小、結束。Td、TD、Tm：設定文字位置與文字矩陣。Tj、TJ：輸出字串，TJ 陣列裡的數字是字距微調。re、f、S：畫矩形、填色、描邊。Do：繪製 XObject（圖片或表單）。
第二階段是字型處理。這是 PDF 渲染最麻煩的部分。頁面裡用的字型可能是 Type1、TrueType、Type3 或 CID 字型，可能完整嵌入，也可能只嵌入子集（subset）。閱讀器必須建立「字元碼 → 字符（glyph）」的對應，通常靠字型裡的 ToUnicode CMap。這也是為什麼有些 PDF 的複製貼上會變成亂碼、有些搜尋功能失效——不是閱讀器笨，是那份 PDF 的字型對應表本來就殘缺。
第三階段是幾何運算。PDF 用 CTM（Current Transformation Matrix）處理縮放、旋轉、平移。你放大到 400%，閱讀器其實是把 CTM 乘上一個縮放矩陣。向量內容可以重新光柵化，所以放大不失真；但如果頁面裡塞的是 72 dpi 的點陣圖，放大一樣會糊。這點在評測「高解析渲染」時常被混為一談，其實兩者原因完全不同。
第四階段是顯示列表與光柵化。現代閱讀器通常不會邊解析邊畫，而是先建立一份顯示列表（display list），把頁面切成可快取的圖塊（tile），再依目前視窗與縮放比例光柵化成畫面。這也是為什麼快速滾動時會看到白塊——圖塊還沒算完。像 pdf.js 這類純 JavaScript 實作，甚至會用 Web Worker 把解析丟到背景執行緒，主執行緒只負責把結果貼到 canvas。
2.2 註解圖層與內容層的分離設計
關鍵來了。在 PDF 的規範裡，頁面內容（page content）與註解（annotations）是兩個獨立的結構。內容流負責「這頁長什麼樣子」，註解則是一個個獨立物件，掛在頁面的 /Annots 陣列上，各自有位置、外觀、內容。
這代表渲染順序是固定的：閱讀器先畫完頁面內容，再把註解疊上去。註解永遠在內容之上，不會被文字蓋住。這個「圖層式」設計帶來幾個很重要的後果：
/Annots 陣列移除一個參照，內容流完全不動。/AP 字典，裡面放預先繪製好的 XObject 當作「長相」。/AP，閱讀器就必須自己按規範生成外觀——這正是跨軟體顯示不一致的頭號原因。反過來說，如果你把註解「展平」（flatten），就是把它們的外觀直接畫進內容流、再從 /Annots 移除。展平後的 PDF 在任何軟體、任何印表機上看起來都一模一樣，但代價是註解清單、可編輯性、可回覆性全部消失，只剩下視覺痕跡。
三、為什麼「註解標記」在技術上如此特別
理解了圖層分離，就能進一步拆解註解為什麼是 PDF 裡最複雜、也最容易被實作偷工減料的一塊。
3.1 註解是「附加物件」，而不是「修改內文」
這是與「直接在 Word 上畫重點」最根本的差異。在 Word 裡，螢光筆本質上是字元屬性，改動會影響文件流。在 PDF 裡，一則螢光筆註解是一個獨立物件，它記錄的是「一個矩形區域」加上「顏色」加上「這段標記對應的文字內容（可選）」。
換句話說，PDF 的註解並不知道它畫在哪些字上面。它只知道座標。這帶來一個很有意思的技術現象：當你在高亮註解上雙擊想編輯時，閱讀器得反過來做「反查」——用註解的矩形範圍去跟文字層比對，找出被覆蓋的字元。這件事說來簡單，做起來很考驗實作功力，因為它涉及字元的邊界框（bounding box）計算、文字矩陣反推、還有連字與字距的處理。
這也是為什麼你會發現：有些軟體的高亮範圍精準到字，有些軟體的螢光筆卻老是歪一角；有些軟體能正確抽出被高亮的文字做摘要，有些抽出來是亂的。差別不在「會不會畫畫」，而在「有沒有認真做文字反查」。
更關鍵的是，這種設計讓 PDF 註解不會破壞原文件的可信度。一份合約用 PDF 傳遞、在上面加註意見，原始條文的位元組毫無變動，這對法律、審計、公部門流程來說是必要條件。
3.2 註解字典與外觀流：一則螢光筆的完整解剖
我們把一則典型的文字標記註解拆開來看。它的字典大致會包含：
/Type /Annot：宣告這是註解物件。
/Subtype /Highlight：註解種類。常見的還有 /Text（便利貼）、/Underline、/StrikeOut、/Squiggly、/Square、/Circle、/Line、/Ink（手繪）、/FreeText、/Stamp、/Link、/Widget。/Rect：註解在頁面上的矩形範圍。
/QuadPoints：標記類註解專用，記錄被標記文字的每一行四邊形座標，所以跨行高亮可以呈階梯狀。/C：顏色陣列，例如 [1 1 0] 是黃色。
/CA：不透明度，0 到 1。
/Contents：註解的文字內容（你在便利貼裡打的字）。
/T：作者名稱。
/M：修改時間。
/Popup：關聯的彈出視窗註解。
/AP：外觀流字典，至少要有 /N（一般狀態）。
/F：旗標位元，控制是否列印（Print）、是否唯讀（ReadOnly）、是否鎖定（Locked）等。/F 旗標常被忽略，但它解釋了兩個超常見的疑問。第一，「為什麼我的註解印不出來？」——因為註解可能沒設 Print 位元，或者印表機對話框裡的「列印註解」選項沒勾。第二，「為什麼這則註解我刪不掉？」——因為它被標記為 Locked，通常是表單欄位或審閱流程刻意鎖定的。
而 /AP 外觀流，正是跨軟體一致性的核心。規範建議（在某些情況下要求）產生註解時一併寫入外觀流，這樣別的閱讀器不必「猜」它該長什麼樣，直接照著畫就好。可惜現實中不少輕量級工具、線上 PDF 編輯器、甚至部分手機 App，寫入註解時只寫了幾何與顏色，卻沒帶 /AP。於是換個軟體打開，同一則註解就變了樣，甚至完全看不見。
3.3 標記類註解 vs. 表單欄位 vs. 數位簽章
這三者在 PDF 裡都掛在 /Annots 底下，所以常常被混為一談，但它們的用途與規則差異很大：
類型
代表 Subtype
用途
技術特性
文字標記註解
Highlight、Underline、StrikeOut
閱讀標重點、審閱意見
靠 QuadPoints 描述範圍，不影響內容流
便利貼與繪圖
Text、Ink、Stamp、FreeText
補充說明、批核、蓋章
常需要 Popup 與 AP，圖形類資料量大
表單欄位
Widget
填空、勾選、簽名欄
與 AcroForm 結構連動，可被鎖定或設為唯讀
數位簽章
Widget / Sig
驗證文件完整性與簽署者身分
簽章覆蓋位元組範圍，後續修改可能導致失效
簽章這一列特別值得說明。PDF 的簽章機制有所謂的 DocMDP（Document Modification Detection and Prevention）權限設定，常見的三個層級是：不允許任何修改、允許填表與簽章、允許標記註解。也就是說，如果一份文件被設為「不允許任何修改」，你在上面加一則螢光筆，驗證時就會被判為「文件已被修改」，簽章失效。這不是軟體的錯，而是文件作者刻意設定的保護。評測閱讀器時，能不能清楚提示「此文件已簽署，新增註解將影響簽章有效性」，就是專業度的分水嶺。
四、主流閱讀軟體對註解的處理差異
接下來進入軟體評測的部分。以下不是要排出「誰最好」，而是要看不同類型的實作路線，在註解這件事上各自做了什麼取捨。
4.1 商業旗艦：功能完整的代價
Adobe Acrobat 是 PDF 規範的原始制定者，對註解的支援最完整：所有標準 Subtype 都支援、外觀流寫入最確實、註解清單可依作者與類型篩選、支援註解回覆串（Reply）與狀態標記（Status），也支援將註解匯出成獨立檔案再匯入合併。它的「註解摘要」功能可以把所有批註整理成一份含頁碼與原句的清單，對審閱流程幫助很大。
Foxit PDF Editor 長期被視為輕量替代方案，註解功能相當齊全，尤其在大量註解文件的滾動流暢度與記憶體占用上，實測通常優於 Acrobat。它對 /AP 的寫入也相當確實，跨軟體相容性表現穩定。
PDF-XChange Editor 在 Windows 使用者社群裡口碑很好，註解工具列的密度與自訂性極高，支援自建工具樣式、鍵盤快捷、快速鍵盤標記流程。它對索引與增量更新的處理也相當透明，會明確顯示「已儲存為增量更新」或提示重寫。
4.2 開源與輕量：相容性的壓力測試
pdf.js（Mozilla 開源專案，也是 Firefox 內建 PDF 檢視器的核心）走的是完全不同的路線：純 JavaScript、Canvas 渲染。它的註解層是以 DOM 疊在 canvas 之上，文字選取與高亮比對做得很用心，對沒有 /AP 的註解也能依規範生成外觀。不過它對「編輯既有註解」的支援相對保守，主要以檢視與新增標記為主。
SumatraPDF 以極輕量著稱，註解支援集中在最常用的標記類型，優點是啟動快、對老舊機器友善。它在處理增量更新堆疊很多的檔案時，開啟速度仍是前段班。
macOS 預覽程式（Preview）是一個很有意思的案例。它的註解體驗極其順手，標記工具列設計直覺，但它寫入的部分註解在換到 Windows 軟體時，偶爾會出現外觀或位置偏差。這種「單一生態圈內體驗極佳、跨平台相容性稍弱」的取捨，是許多原生應用的共同特徵。
4.3 評測時該看的五個指標
如果你要自己評測一款 PDF 軟體的註解能力，建議用同一份測試檔跑這五項：
文字反查能力。用「註解摘要」匯出，檢查被標記的原句是否正確抽出。
簽章衝突提示。對一份已簽章文件新增註解，看軟體有沒有明確警告。
五、註解標記的實務價值：為什麼使用者真的需要它
技術講完，回到使用者角度。註解標記之所以不是「可有可無的小功能」，是因為它在幾個場景裡幾乎是不可替代的：
5.1 學習與研究：把文件變成自己的筆記本
讀論文、讀技術規格、讀判決書，最有效的閱讀方式從來不是「讀完」，而是「邊讀邊留下痕跡」。螢光筆標出關鍵句、便利貼寫下疑問、手繪圈出圖表重點、再用註解摘要匯出一份大綱——這整套流程之所以可行，正是因為註解是獨立物件，可以隨時增刪、篩選、匯出，而不會破壞原文。
對學生與研究者而言，還有一個更實際的好處：註解可以只存在自己的副本裡。同一份 PDF 教材，每個人畫的重點不同，互不干擾。
5.2 團隊協作：不必互相覆蓋的審閱流程
傳統「把 Word 檔寄來寄去、每個人改一版」的流程，最大的問題是版本混亂與互相覆蓋。PDF 註解則提供了另一條路：一份文件、多人各自加上署名（/T）與時間（/M）的批註、再用顏色區分角色、最後由彙整者一次檢視所有意見。
這也是為什麼註解清單的「可篩選性」是評測重點。一份 200 頁的合約被三個人審過，如果軟體只能把所有註解攤成一長串，那跟沒有工具差不多；能依作者、類型、頁碼、狀態（已解決／待處理）篩選，才是真正支援協作。
5.3 專業流程：法律、出版、工程與無障礙
在法律與合約流程裡，PDF 註解是「不改動正本、但留下完整意見軌跡」的工具。在出版流程裡，編輯用註解標錯字、設計師用註解標版面問題，註解就是一種輕量的工單。在工程圖說裡，雲形標註（Cloud）加上說明是標準做法。
還有一個較少被提到的面向：無障礙（Accessibility）。PDF 的「替代文字」（Alt text）與標記結構（Tagged PDF）是讓螢幕閱讀器能讀懂文件的關鍵，而註解本身也可以帶內容描述。一份沒有標記結構的 PDF，對視障使用者幾乎等於空白；這也是為什麼 PDF/UA 規範對結構與註解都有明確要求。
六、風險與限制：註解不是萬能
講了這麼多優點，也得說清楚限制，否則很容易踩坑。
/AP 的註解，在不同軟體間可能外觀不一致甚至消失。跨組織交換文件時，建議先做一次往返測試。/Producer、/Creator 等文件資訊欄位）。對外釋出文件前，務必執行「移除中繼資料」與「清除註解」。理解了這些限制，你就能判斷「為什麼我的註解不見了」屬於哪一種情況：是外觀流沒寫、是權限被鎖、是註解被展平、還是根本被存檔規範過濾掉了。這四種原因的處理方式完全不同。
七、選用建議：依需求挑對工具，而不是挑最有名的
最後給一份實務導向的建議。如果你主要做深度審閱與協作，需要完整的註解類型、回覆串、狀態管理與摘要匯出，商業旗艦級工具仍然是首選，因為它們對外觀流與規範細節的遵循最完整。如果你重視開啟速度與大量標記的流暢度，輕量級與部分商業替代方案在記憶體管理上往往更討喜。如果需求是跨平台、免安裝、可嵌入網頁，開源渲染引擎為基礎的解決方案彈性最大。若是行動裝置上的隨手標記，則要特別注意它是否會寫入完整外觀流，以免回到桌面端時格式走鐘。
不論用哪一套，有兩個習慣值得建立：第一，重要文件在大量註解後，定期「另存新檔並最佳化」，避免增量更新無限堆疊；第二，對外釋出前，一定檢查註解與中繼資料是否該清除。這兩件事花的時間不多，卻能省下很多後續麻煩。
結語：註解標記，是 PDF 設計哲學的縮影
回頭看，「為什麼註解標記」這個問題的答案，其實不在功能清單裡，而在 PDF 的設計哲學裡。這個格式從一開始就選擇了「描述頁面」而不是「記錄編輯」，選擇了「內容與註解分離」而不是「所見即所得的字元屬性」。正是這個選擇，讓 PDF 能在三十年間成為文件交換的共通語言——原文永遠不被動搖，而意見可以一層層疊上去。
所以下次當你在某句話上畫下一條螢光筆時，不妨想想背後發生的事：一個新的註解物件被建立、一組四邊形座標被計算、一份外觀流被寫入、一張交叉參照表被追加。你看見的只是黃色的一條線，但那條線之所以能穿越不同軟體、不同裝置、不同年份，靠的是一整套嚴謹到近乎固執的規範設計。
而對軟體開發者與評測者而言，註解正是最好的試金石。一個閱讀器可以把頁面渲染得又快又漂亮，卻在註解的 /AP、QuadPoints、增量更新這些細節上偷懶。這些地方一般使用者看不到，但一旦跨軟體、跨平台、跨版本，差異就會全部現形。看懂了註解，你大概也就看懂了一款 PDF 軟體到底用不用心。