OCR PDF引擎是圍繞著從左到右的文本流建構的。當您向它們提供以從右到左的腳本（例如阿拉伯語、希伯來語、波斯語或烏爾都語）編寫的文檔時，引擎必須檢測腳本方向，以正確的視覺和邏輯順序識別字符，並輸出以目標語言自然閱讀的文本。如果其中一個步驟出錯，就會產生技術上可識別但功能上無法使用的文字：單字向後拼字、句子從末尾開始以及數字出現在周圍文字的錯誤一側。
針對從右到左語言的正確 OCR 需要選擇明確支援目標腳本的 OCR 引擎，使用正確的語言參數對其進行配置，並透過雙向文字感知工具驗證輸出。對於從左到右的語言，該過程並不比 OCR 困難，但許多用戶跳過的配置步驟（告訴引擎需要哪種語言）對於從右到左的腳本來說不是可選的。保留預設設定（通常是英文）的引擎將從阿拉伯語或希伯來語文件中產生無意義的輸出。
WukongPDF 的掃描 PDF OCR 工具支援多種語言，包括從右到左的腳本。在執行 OCR 之前選擇正確的語言是提取可用文字和生成字元雜訊之間的差異。
為什麼從右到左 OCR 在沒有明確配置的情況下會失敗
OCR 引擎分析形狀並將其對應到指定語言字元集中的字元。當引擎需要英語時，它會將形狀解釋為拉丁字母。 B 的阿拉伯字母在許多字體中看起來與拉丁字母 B 有點相似，但 Ayn 的阿拉伯字母沒有對應的拉丁字母。英語模式的引擎遇到 Ayn 時會輸出隨機標點符號或完全跳過該字元。在整個文件中，這種逐字的錯誤辨識會產生與原始文字沒有任何關係的輸出。
即使選擇了正確的腳本，文字方向也會帶來第二層複雜性。預設情況下，OCR 引擎從左到右處理影像，從左邊緣到右邊緣跨越每行像素。從右到左的文檔應該從右到左處理，以便引擎按照寫入的順序讀取字元。如果引擎不反轉從右到左腳本的處理方向，則識別的字元在每個單字中將按相反順序排列。設定語言參數後，某些引擎會自動處理方向反轉。其他則需要明確的文字方向標誌。
為從右到左的 OCR 配置 Tesseract
Tesseract 是開源 OCR 引擎，透過特定語言的資料檔案支援阿拉伯語、希伯來語、波斯語、烏爾都語和其他幾種從右到左的腳本。安裝目標腳本的語言資料。在 Linux 上，該軟體包通常命名為 tesseract-ocr-ara（阿拉伯語）或 tesseract-ocr-heb（希伯來語）。在 Windows 上，從 Tesseract GitHub 儲存庫下載經過訓練的資料檔案並將其放置在 tessdata 目錄中。
運行 Tesseract，並將語言標誌設定為正確的腳本：tesseract input.pdf 輸出 -l ara 表示阿拉伯語，-l heb 表示希伯來語，或 -l ara+eng 表示阿拉伯語-英語雙語文檔。當語言參數指定從右到左的腳本時，Tesseract 會自動處理文字方向。辨識的文字輸出保留正確的閱讀順序。要進行驗證，請開啟輸出文字檔案並確認單字以預期方向讀取並且句子從右向左排列。
對於具有混合腳本的文檔，例如包含英語技術術語的阿拉伯語研究論文，請指定用加號分隔的兩種語言：-l ara+eng。 Tesseract 以每個單字為基礎在語言模型之間切換，將阿拉伯語模型應用於阿拉伯語腳本單詞，將英語模型應用於拉丁語腳本單字。每個單字的切換並不完美，特別是對於可能屬於任一腳本的短單字，但它足以處理大多數混合腳本文件。
使用 Google Cloud Vision 進行自動偵測
Google Cloud Vision 的 OCR 功能包括自動語言偵測，當您不確定確切的語言或文件包含多種從右到左的語言時，這對於從右到左的腳本特別有用。 API 接受文件圖像並傳回辨識的文本，其中包含每個單字的邊界框、每個文本區塊偵測到的語言以及文字方向。對於從右到左的腳本，傳回的文字已經是正確的閱讀順序。
Cloud Vision 的阿拉伯語和希伯來語識別品質通常高於 Tesseract，因為底層模型是在更大、更多樣化的資料集上進行訓練的。代價是文檔圖像必須上傳到 Google 的伺服器進行處理，這對於敏感或機密文件來說可能是不可接受的。對於公開文件或批准雲端處理的內部文檔，Cloud Vision 提供最準確的從右到左 OCR，無需購買專門的桌面 OCR 軟體。
| 語言 | OCR引擎支援 | 準確度註 |
|---|---|---|
| 阿拉伯 | Tesseract、Google雲端視覺、ABBYY | 變音符號可能會被刪除，連字處理有所不同 |
| 希伯來文 | Tesseract、Google雲端視覺、ABBYY | Nikud 元音點在 OCR 過程中經常丟失 |
| 波斯語/烏爾都語 | Tesseract、谷歌雲視覺 | Nastaliq 腳本變體挑戰大多數引擎 |
驗證從右到左文本的 OCR 輸出
OCR 後，在支援雙向文字渲染的文字編輯器中開啟識別的文本，例如啟用了雙向插件的 Notepad++ 或安裝了 RTL 語言套件的 Visual Studio Code。如果實現了 Unicode 雙向演算法，假設從左到右文本的標準文本編輯器可以正確顯示從右到左的文本，但行尾的標點符號以及文本中數字的相對順序是常見的故障點。具有明確雙向支援的文字編輯器以母語人士期望閱讀的方式顯示文字。
根據原始掃描文件在三個層級對輸出進行抽查：單字，特別是包含變音符號或連字的單字；完整的句子，確認詞序在目標語言中自然地讀起來；以及數字和日期，確認它們出現在周圍文字的正確一側。每個單字都被正確識別但每個句子中的單字順序相反的文檔與根本沒有單字被識別的文檔一樣無法用於翻譯或搜尋。
當設定正確的語言參數時，從右到左語言的 OCR 是一個已解決的技術問題。最重要的一步是告訴引擎需要什麼腳本。該決定的下游一切，從識別準確性到閱讀順序再到混合腳本處理，都取決於正確的語言配置。配置語言參數並開啟雙向文字編輯器進行驗證後，從右到左的語言文件的 OCR 不需要比任何其他語言的 OCR 花費更多的時間或精力。
從右到左語言文本的 OCR 後翻譯
準確地辨識文字後，翻譯從右到左的語言內容需要一個能夠正確處理雙向文字的翻譯引擎。 Google Translate 和 DeepL 都支援阿拉伯語、希伯來語和波斯語。將辨識出的文字貼到翻譯介面中，並確認原始語言被正確辨識。翻譯引擎偵測腳本方向並將其保留在輸出中。對於翻譯將由母語人士審查的文檔，將原始識別文本和翻譯文本並排導出到兩個列表中，以便進行有效比較。
從右到左語言的機器翻譯通常不如從左到右歐洲語言之間的翻譯準確，因為許多從右到左語言對的訓練資料較小。對於重要文檔，請先讓母語人士審查翻譯，然後再對其內容採取行動。 OCR 步驟可產生準確的來源文字。翻譯步驟增加了一層解釋。將 OCR 輸出視為文件內容的基本事實，將機器翻譯視為其含義的指南，並進行驗證。
批次從右到左語言 PDF
當您有一個從右到左語言的 PDF 到 OCR 的資料夾時，Tesseract 的命令列介面接受批次輸入。單一 shell 指令可以處理每個 PDF： for f in *.pdf;做 tesseract $f ${f%.pdf} -l ara;完成。該命令循環遍歷所有 PDF，使用阿拉伯語模型運行 OCR，並使用匹配的基本檔案名稱將識別的文字與每個 PDF 一起保存。
對於混合語言批次，請在 OCR 之前使用語言檢測步驟。帶有 langdetect 庫的 Python 腳本對文字的第一頁進行採樣以預測語言。根據預測，腳本選擇適當的 Tesseract 語言參數並執行 OCR。自動語言偵測消除了在批次處理之前按語言對 PDF 進行手動排序的情況。從右到左語言的批次 OCR 將繁瑣的每個文檔過程轉換為單一命令，無論輸入資料夾中有多少文檔，該命令都可以在幾分鐘內完成。
從右到左語言的 OCR 並不是需要特殊工具的特殊情況。它需要與從左到右 OCR 相同的工具，並配置正確的語言參數。許多使用者跳過的配置步驟是因為他們認為 OCR 預設值可以工作，這是可用的提取文字和完整字元雜訊之間的全部差異。設定語言標誌，運行 OCR，在雙向文字編輯器中驗證輸出，整個過程就完成了。從右到左腳本的 OCR 獎勵那些花時間正確配置語言參數並驗證雙向文本編輯器中的輸出的用戶，從文檔中生成準確、可用的文本，否則任何不閱讀源語言的人都無法訪問這些文本。