標準 OCR 引擎建立在一個基本假設之上：文字在頁面上從左到右水平運行。此假設適用於英語、西班牙語、法語、德語和大多數歐洲語言。對於傳統列中垂直設定的日文文字、字元從上到下堆疊的中文符號以及文字從右到左排列的阿拉伯語和希伯來語文檔，它完全失敗。在這些文件上執行標準 OCR 會產生輸出，其中字元被單獨識別，但以錯誤的順序組裝，導致結果無用。
透過最新一代人工智慧驅動的識別系統，OCR PDF引擎處理非標準文字方向的能力顯著提高。這些引擎在嘗試識別之前檢測文字方向，識別閱讀方向，並重建邏輯閱讀順序，而不管視覺佈局如何。對於具有混合文字方向的文檔，例如包含水平英語引文的日語文章，引擎會在頁面中間切換模式。
OCR 引擎如何偵測和處理文字方向
現代 OCR 引擎從佈局分析步驟開始，該步驟識別文字區域、確定其方向並按閱讀方向對它們進行分類。對於水平文本，引擎會偵測基線並沿其對字元進行分組。對於垂直文本，引擎會偵測垂直軸並將字元分組到列中。對於從右到左的文本，引擎會識別主導字元集並反轉預設的從左到右的單字順序。
文字方向檢測依賴多個訊號。特定 Unicode 字元範圍的存在表示可能的語言及其典型的文字方向。偵測到的字元的空間排列，無論它們形成水平線還是垂直列，都提供了佈局證據。字元邊界框的長寬比提供了第三個訊號：拉丁字元通常寬度大於高度，而 CJK 字元大致呈正方形，阿拉伯字元以顯示閱讀方向的方式水平連接。
最可靠的 OCR 引擎結合了所有三種訊號類型。包含阿拉伯文字（意味著從右到左閱讀）和拉丁文字（意味著從左到右閱讀）的文檔需要引擎獨立分析每個文本區域。正確配置的多語言文件提取 PDF 資料管道包括每個區域的方向檢測，而不是將單一方向應用於整個頁面。
每個書寫系統都需要根本不同的 OCR 配置。
日文、中文和韓文豎排文本的 OCR 設置
日文豎排文字稱為“tategaki”，是現代使用中最常見的垂直排書寫系統。它出現在小說、報紙、傳統文獻和正式信件中。在豎排日語中，字元是從上到下讀取的，列在頁面上從右到左排列。嵌入在垂直日文文字中的數字和拉丁文字可以在垂直流內水平旋轉或設定。
若要 OCR 豎排日文文本，請選擇明確支援 tategaki 的識別引擎。通用 OCR 引擎可能會正確檢測字符，但會以從左到右的水平順序輸出它們，從而產生垃圾。日文專用 OCR 引擎可以理解基於列的閱讀順序並輸出可以自然閱讀的文字。 Tesseract 是開源 OCR 引擎，在版本 5 中添加了改進的垂直日語支持，現在有幾個商業引擎提供了它。
對於出現在傳統出版物、書法和一些正式文件中的中文豎排文本，識別挑戰類似，但字符集更大。簡體中文使用大約 7,000 個常用字符，而繁體中文使用超過 13,000 個常用字符。 OCR 引擎不僅必須偵測垂直佈局，還必須區分視覺上相似但僅筆畫細節不同的字元。
韓文豎排文本在現代文獻中很少見，但出現在歷史文本和一些傳統出版物中。韓文字母 Hangul 將各個字母組合成音節塊，在垂直書寫中，這些塊從上到下堆疊。處理韓文直排文字的 OCR 引擎必須辨識音節區塊結構以及每個區塊內的各個字母組件。
阿拉伯語、希伯來語和波斯語從右到左文本的 OCR 設置
阿拉伯語 OCR 提出了超出文字方向的獨特挑戰。阿拉伯語是一種草書文字，其中大多數字母與其相鄰字母相連，字母形狀根據其在單字中的位置而變化：首字母、中間字母、結尾或孤立字母。 OCR 引擎必須識別這些上下文形式並將它們對應到正確的抽像字元。字母之間的缺失連接或錯誤連接會產生草書特有的識別錯誤。
選擇希伯來語 OCR 時，腳本不是草書，而是包含元音點（稱為 niqqud），在字母上方、下方或內部顯示為點和破折號。這些元音標記很小，通常在掃描影像中為 2 到 4 個像素，並且在二值化過程中很容易遺失。未明確處理 niqqud 的 OCR 引擎將正確識別輔音，但會丟棄元音標記，生成人類讀者可以理解的文本，但技術上不完整。
波斯語和烏爾都語使用帶有附加字符的阿拉伯文字的擴展版本。僅接受阿拉伯語訓練的 OCR 引擎將錯過這些附加字元或將它們誤識別為類似的阿拉伯字母。為這些語言選擇 OCR 引擎時，請驗證它是否專門列出了對文件使用的確切語言和腳本變體的支持，而不僅僅是一般的阿拉伯腳本。
處理混合方向的文檔
許多現實世界的文檔在同一頁上混合了多個文字方向。日文技術論文可能有垂直的日文正文、水平的英文圖形標題和遵循自己的版面規則的數學方程式。阿拉伯語商業信函可能會在從右到左的正文上方以從左到右的格式包含英文公司名稱和地址區塊。
對於混合方向的文檔，OCR 預處理步驟至關重要。必須將文件分割為文字區域，並且在開始識別之前必須針對文字方向對每個區域進行獨立分類。對於複雜佈局，手動區域選擇通常比自動分割產生更好的結果。在每個文字區域周圍繪製邊界框，並為每個框指定正確的語言和方向。
OCR 後，透過檢查跨越方向邊界的文字來驗證輸出。混合方向 OCR 中的一個常見錯誤是兩個文字區域之間的邊界錯誤，導致從左到右區域的最後一個單字被附加到從右到左區域的開頭，反之亦然。抽查這些邊界區域可以發現佈局分割錯誤，否則會產生混亂的輸出。
非標準文字方向的 OCR 後處理
OCR 完成後，識別的文字可能需要重新排序以產生自然的閱讀順序。某些 OCR 引擎會依照辨識的順序輸出垂直日文文本，每列從上到下，從左到右逐列。這個順序與原來的閱讀順序不符，原來的閱讀順序是從右到左逐列。對列重新排序的後處理步驟會產生正確的讀取順序。
對於掃描的 PDF內容包含雙向文字、阿拉伯語和嵌入英文術語的文檔，Unicode 雙向演算法指定如何決定顯示順序。 OCR 輸出應包含 Unicode 雙向控製字元或遵循演算法，以便文字在貼上到支援雙向文字的應用程式時正確顯示。
WukongPDF 透過瀏覽器對掃描的 PDF 提供 OCR 處理，並提供語言選擇選項，包括對主要從右到左和垂直書寫系統的支援。在處理完整文件之前在範例頁面上測試 OCR 可讓您驗證文字方向是否已正確處理。
對於同一頁面上同時包含垂直和水平文字的文件（例如日本雜誌佈局，其中主要文章是垂直的，但標題和側邊欄是水平的），手動分區可產生最準確的 OCR 結果。為垂直和水平區域繪製單獨的識別區域，為每個區域分配正確的文字方向，並在分區文件上執行 OCR。花在分區的額外時間會提高辨識準確性。
處理具有非標準文字佈局的歷史文件時，請做好 OCR 準確性低於現代印刷文件的準備。歷史字體、不均勻的印刷、褪色的老化紙張以及非標準字符變體都會降低識別信心。對於學術或檔案工作，請將 OCR 輸出視為手動轉錄的起點，而不是成品。
某些 OCR 引擎支援培訓模式，您可以在其中提供文件中使用的特定字體或手寫風格的範例。在幾個代表性的頁面上訓練引擎可以提高整個文件的識別準確性。這種方法對於以不常見字體列印的文檔或來自同一出版商的文檔集合特別有用，其中多卷的版式是一致的。
從右到左的文件完成 OCR 後，透過從輸出複製幾個句子並將其貼上到支援雙向文字的應用程式（例如 Microsoft Word 或 Google Docs）中來驗證文字方向是否正確。如果文字以相反的順序顯示，則 OCR 引擎未正確套用從右到左的方向，並且需要使用更正的方向設定重新處理輸出。
為非標準文字方向設定正確的 OCR 參數所投入的時間會立即在辨識準確性方面得到回報。在 OCR 效果不佳後需要 30 分鐘手動更正的文件在正確配置 OCR 後可能只需要 5 分鐘清理。
| 書寫系統 | 方向 | OCR 引擎要求 | 主要挑戰 |
|---|---|---|---|
| 日文（立垣） | 從上到下、從右到左的列 | 具有明確 tategaki 支援的引擎 | 垂直流中的混合水平英語 |
| 中文（繁體） | 垂直列，從右到左 | 大字元集（13,000+） | 視覺上相似的角色 |
| 阿拉伯 | 從右到左，草書連接 | 具有位置形式的阿拉伯文字引擎 | 上下文字母形狀；變音符號 |
| 希伯來文 | 從右到左，帶 niquud | 具有元音支援的希伯來語腳本引擎 | 二值化中丟失的小元音標記 |
| 波斯語/烏爾都語 | 從右到左，擴展阿拉伯語 | 特定語言引擎 | 阿拉伯語集之外的其他字符 |