RTL 經文引用在模組中列印順序錯誤

Question

在為阿拉伯文字系統語言列印模組時，我注意到經文引用的列印順序不正確。以下是我的模組 SFM 檔案中的內容：

\s God creates the world
\r ($(GEN 1:1-27))
\ref GEN 1:1-27

以下是我從 PTXprint 2.3.45 獲得的輸出結果：

（直譯為：“1:1-27 創世記”——章節/節數部分的列印方式與從左到右（LTR）語言相同。）

但從右到左（RTL）閱讀時，順序應該是：書名、空格、章節號、冒號、起始節數、連字號、結束節數。

現在我仔細查看，發現平行經文標題中也有同樣的錯誤。

機器翻譯自 English 顯示原文

Answer 1

這裡可能有相當多的地方出錯：

1. 文件是否確實設定為 RTL，還是 \s 標籤的內容就是模組中寫的那樣？我們確實有實現所謂“系列雙語”（切換出版物相關部分的語言設定）的可能性，但這不是自動的。
2. ($(GEN...)) 引用可能生成了不正確的中間輸出。測試方法：您能否查看 final USFM 標籤頁，看看在那裡顯示的是正確還是錯誤？
3. 可能提供了一些 Unicode 方向切換字節，導致某些混亂。測試方法：您能否手動輸入（不要複製貼上）一個數字範圍到額外的 \r 標籤中，看看是否有效？
4. 我想，出於某種原因，\r 標籤可能忘記了文件是 RTL 的。測試方法：您能否在格式顯示正確的其他行中輸入一個範圍？

機器翻譯自 English 顯示原文

Answer 2

感謝您如此迅速地處理這個問題。

1. 這是一份完全 RTL 的文件。我不記得是否必須告訴 PTXprint 這一點，還是它從 Paratext 獲得了這個資訊。

2. 您能告訴我該怎麼做嗎？我在 PTXprint 中看不到那個標籤頁。

3. 第 3 和第 4 點。當我將經文引用輸入 \s 或 \r 時，它們都以同樣的方式錯誤顯示。但其他方面似乎處於 RTL 模式。其他單詞的顯示順序是正確的 RTL 順序。

\s ببب پیدایش ۱:۱-۲۷ ییی
\r ($(GEN 1:1-27))
\r پیدایش ۱:۱-۲۷
\r قیرست سکند
\ref GEN 1:1-27

機器翻譯自 English 顯示原文

Answer 3

image898×411 30.3 KB

機器翻譯自 English 顯示原文

Comments

啊，在那裡。

是的，它設定為從右到左（Right-to-Left），並採用 RTL 裝訂方式。

機器翻譯自 English 顯示原文

Answer 4

所以嗯……至少它是一致的！
非常奇怪！

機器翻譯自 English 顯示原文

Answer 5

從右到左（RTL）的文字顯示起來很怪。數字實際上是按從左到右（LTR）格式顯示的。所以如果你去掉了冒號和連字號，那串數字的正確顯示方式應該是：
也就是「1127」，從左到右閱讀

如果我將你上面 \s 中的文字貼到 Word 中，我會得到以下結果（這正是你在 PTXprint 中看到的）：

但是，如果我把它貼到 LibreOffice Writer 中，我會得到以下結果：

（這是你希望得到的結果）

在這種情況下，我認為 Word 其實更正確。數字是 LTR 的，而冒號和連字號在雙向性（bidirectionality）上屬於「中性」（請參閱 Bidirectional text - Wikipedia）。這意味著它們不會強制文字的方向，而是取決於周圍的上下文。由於它們處於 LTR 字符（即數字）的上下文中，它們應該保持 LTR 方向，因此整串數字和標點符號應該以 LTR 方向顯示在行上，正如 PTXprint 所做的那樣。

所以從這個角度看，PTXprint 產生的結果在理論上是正確的（根據雙向文字演算法）。但這實際上不是你想要的。我們是從右到左閱讀文字的，我們希望不同的片段（由標點符號分隔）按 RTL 順序一個接一個地出現，就像上面 LO Writer 的輸出所示。（我其實不知道為什麼 LO Writer 的輸出是那樣。它似乎沒有遵循 Unicode 雙向演算法……）

但我可以在 Word 中通過添加稱為「從右到左標記」（Right-to-left marks）的特殊標記來獲得這種行為。它們是 Unicode 碼位 U+200F（請參閱 Right-to-left mark - Wikipedia）。你可以在標點符號後插入這些標記，以強制該標點符號的 RTL 文字方向。要在 Word 中這樣做，請將插入點放在冒號後面（我建議使用方向鍵找到該位置），輸入「200F」，然後按 Alt+X（按住 Alt 鍵並輕按 X 鍵）。你的第一章現在應該會跳到你的數字和標點符號串的右側。在連字號後面做同樣的操作，你的字符串就會看起來和上面 LO Writer 的輸出一樣。

但現在棘手的部分是如何在 PTXprint 的文字中插入這些 RTL 標記。我還沒有測試過，但我認為你可能可以使用 Changes.txt（在「進階」選項卡上）來創建規則，以在正確的位置插入 RTL 標記。試試這些規則（未測試）：
'(\d):(\d)' > '\1:\u200f\2'
'(\d)-(\d)' > '\1-\u200f\2'

但還有一個有趣的問題。我注意到你使用的是東部阿拉伯-印度數字，它們從 U+06F0 開始。（請參閱 https://www.unicode.org/charts/PDF/U0600.pdf.）我主要使用的是普通的阿拉伯-印度數字，它們從 U+0660 開始。我認為 \d 數字指定應該對這些數字也有效，但如果不起作用，你可能需要使用類似 [\u06F1-\u06F9] 的東西來代替 \d。

總之，這給你一些可以嘗試的東西。我們都會很想知道你是否取得了進展！

Jeff

機器翻譯自 English 顯示原文

Comments

我應該指出，這種操作不是普通 PTXprint 用戶必須進行的。如果這確實是 RTL 文字的全球性問題，我們應該找到一種方法讓 PTXprint 在“內部”修復這個問題，這樣用戶就不需要採取極端措施來獲得所需的輸出。

機器翻譯自 English 顯示原文

Answer 6

嗯，為了讓目標更清晰，這裡有一張已出版的波斯語（Farsi）翻譯截圖，其中包含平行經文指示符。第一個是馬太福音 6:25-33 的引用，視覺順序為：33-25:6 馬太福音

shot3096×1292 254 KB

你說得完全正確，數字確實是從左到右（LTR）書寫的，但當有分隔符等元素時，一串數字就像一個單詞。然後所有單詞都會按照從右到左（RTL）的順序排列。

Microsoft Word 讓人困惑。如果我輸入經文引用，它會正確顯示（事實上，無論我將段落設定為 RTL 還是 LTR 都是如此）。但如果我從這個瀏覽器視窗複製並貼上，它就會顯示錯誤（同樣，無論段落是 RTL 還是 LTR）。真是「所見即所得」（WYSIAYG），我想。

以下是我可以在 Word 或其他圖形介面中重現錯誤結果的一些方法：

• 在引用的開頭放置一個從左到右標記（U+200E）。
• 如果我移除書名，章/節部分就會錯誤排列。

這讓我覺得章/節部分是以 LTR 模式排列的。

這裡有一些進一步的測試。當我把經文引用放在經文文本中時，它們會顯示錯誤。我無法完全解釋這一點，除非 XeLaTeX 根本沒有被告知這是一個 RTL 環境。

\id PHM
\h سسسس
\c 1
\cl
\s1 سسسس
\p \v 1 پیدایش ۱:۱-۲۸
\s1 سسسس
\p \v 2  ۱:۱-۲۸

接下來是 XeLaTeX……

如果我使用 fontspec 和 bidi，無論環境是 LTR 還是 RTL，輸出都是錯誤的：

\documentclass{book}
\usepackage{fontspec,bidi}
\setmainfont[Script=Arabic]{Times New Roman}
\begin{document}
\setRTL
۱:۱-۲۷

پیدایش ۱:۱-۲۷

\setLTR
۱:۱-۲۷

پیدایش ۱:۱-۲۷
\end{document}

相反地，如果我使用 xepersian，我無法讓它顯示錯誤。在以下四種情況中，章/節部分都能正確排列：

\documentclass{book}
\usepackage{xepersian}
\usepackage[fontsize=16pt]{fontsize}
\settextfont{Times New Roman}
\begin{document}
۱:۱-۲۷

پیدایش ۱:۱-۲۷

\beginL
۱:۱-۲۷
\endL

\beginL
پیدایش ۱:۱-۲۷
\endL
\end{document}

我就說到這裡。看起來 xepersian 修復了 fontspec 和 bidi 的一個缺陷，但我不知道那是什麼。

機器翻譯自 English 顯示原文

Answer 7

我對其的解讀是，您從 PTXprint 看到的輸出遵循 Unicode 雙向（bidi）演算法，儘管它並未給出您想要的結果。雙向演算法規定冒號和連字號是中性字元，會隨周圍字元的流向而定。當它們處於左到右（LTR）字元字串（例如數字）中時，會繼續保持左到右的方向，從而產生您所看到的結果。顯然，xepersian 套件會改變這些標點符號的雙向特性，從而給出您想要的結果。有趣的是，在 Word 中，如果您在冒號和連字號後面加一個空格，它就會將參考編號翻轉為您希望看到的樣子（但會多出一個空格）。這其實相當奇怪，因為空格在雙向演算法中也被列為中性字元（請參閱上方的連結）。我相信許多右到左（RTL）書寫系統專案都曾在 Paratext 中使用此技術，以使參考編號朝「正確」的方向翻轉。但加入 RTL 標記也能達到同樣的效果，且無需添加空格。

您能否嘗試將這些規則放入 Changes.txt 檔案中，看看會產生什麼效果？

請注意，在您的模組中，您使用的是常規（阿拉伯數字！）數字來輸入參考編號。您的 Paratext 專案中是否有任何參考編號已經使用阿拉伯風格（印地語！）數字輸入？如果有，它們在 Paratext 中是如何顯示的？我相信 Paratext 會在 RTL 專案中自動在這些類型的參考編號中插入 RTL 標記 U+200F，以嘗試使其正確顯示。我假設 PTXprint 也能執行類似的操作。（不過請注意，Paratext 似乎在冒號之前插入 RTL 標記，我認為這也是一個有效的選項。）

機器翻譯自 English 顯示原文

Answer 8

是的，如果我把那些命令放入 changes 檔案中，經文確實會正確輸出。感謝你提供這個修復方法。

如果你只看章/節部分（۱:۱-۲۷），它是根據雙向演算法運作的。但根據該演算法，你應該預期書名（由 RTL 字符組成）的存在會將其切換到 RTL 模式（پیدایش ۱:۱-۲۷）。（在我輸入這段文字時，在這個文字編輯器和預覽視窗中，確實發生了這種情況。）所以我猜想章/節部分是在某個獨立的 \hbox 或類似結構中，由於某種原因，它沒有意識到自己處於一個 RTL 文件中。

（我不想把話題扯得太遠，但如果文件沒有全局設定為 RTL，可能還潛伏著其他問題。例如，我注意到腳註標記出現在單詞的錯誤一側。它們出現在單詞的右側，而不是左側。我不確定，但這看起來像是 LTR/RTL 的問題。）

我沒有嘗試過使用阿拉伯-印度數字。不過，我從未遇到過某種情況，即某樣東西在阿拉伯-印度數字下有效，但在東阿拉伯-印度數字下無效。

機器翻譯自 English 顯示原文

Comments

嗯，很高興你目前有一個變通方法。我會嘗試與 @mjpenny 討論這個問題，看看是否應該在 PTXprint 中採取某些措施。

如果你再次查看雙向演算法（雙向文字 - Wikipedia），請注意數字位於「弱」（Weak）部分。我原本以為它們是「強」（Strong）字符，會定義中間「中立」（Neutral）字符的方向。但我現在理解你的意思了，即放入書名（由「強」RTL 字符組成）會覆蓋「弱」數字，從而定義「中立」字符的方向。

機器翻譯自 English 顯示原文

Answer 9

你好，

我不確定我是否為這個討論串添加了任何尚未被知曉的信息。我一直參與許多 RTL 項目的排版工作。我想簡單補充一下我所知道的 Paratext 如何與 RTL 文本和引用互動。

當在 Paratext 中編輯 RTL 專案時，Paratext 會識別符合經文引用格式或數字範圍格式的字符串——即類似 #:#、#.#、#:#-#、#:#,# 等模式。當這些模式在當前正在編輯的章節中被識別時，Paratext 會在標點符號之前插入 U+200F，使它們顯示在前一個數字的左側（覆蓋否則由數字啟動的 LTR 方向）。

因此，而不是這樣：

你會看到這樣：

如果你在 Paratext 中按邏輯順序輸入引用，當你完成輸入時，你會看到這種視覺更新發生。

因此，在 Paratext 中編輯過的專案中，這些 200F 字符可能已經存在。你可能需要在使用的任何 changes.txt 表達式中考慮這一點。我相信 Paratext 確實只對在編輯器中打開過的章節執行此 200F 插入操作（即它不會遍歷整個專案來執行此操作）。

在 Paratext 中這樣做的原因，是為了讓任何下游出版商或出版工具都能直接渲染文本——這對於某些數位應用程式路徑特別重要，因為這些出版路徑不一定允許像 changes.txt 這樣的干預。

分享我所理解的內容，希望對這裡有所幫助。

Jeff

機器翻譯自 English 顯示原文