具有兩種文字方向的逐字對照

Question

我正在嘗試格式化一個逐字對照（interlinear）專案。底本文字是希臘文，並附有烏爾都語（Urdu）的釋義。整體版面方向將為從左到右，而烏爾都語釋義則預設在希臘文單詞下方以完整的從右到左方向顯示。部分烏爾都語釋義中包含空格。

我已經成功建立了一個基本的版面。烏爾都語（阿拉伯文字）文字如預期般從右到左流動。然而，我找不到任何方法可以強制所有釋義中的文字流動均為從右到左。當出現空格時，版面似乎會暫時恢復為從左到右。空格後的烏爾都語文字又恢復為從右到左。結果是在一個整體從左到右的版面中，出現了兩或三個從右到左的烏爾都語字串。

我想知道是否可以用某種方式強制 gloss|rb 樣式的方向性，但我沒有在該樣式的字型設定中找到此選項。

然後我想到，也許可以在 changes.txt 中，在所有空格（或可能需要此處理的任何其他字元）之前加入從右到左標記（U+200F），例如：

in "\|.*?\\rb\*": " " > "\u200f "

這沒有任何效果。

我知道上述表達式在正確的位置應用了變更——因為如果我輸出「_」（底線）來取代空格，那麼烏爾都語文字的版面就是正確的（除了底線本身！）。我嘗試使用其他間隔字元，但它們也會恢復為從左到右（這並不令人意外）。

上述字串應該像這樣流動（使用底線作為空格）

有沒有人嘗試過這個並能提供建議嗎？

Jeff

機器翻譯自 English 顯示原文

Answer 1

嗨 Jeff，

我自己還沒需要做過這種處理，但想到了一些其他可以嘗試的事情……

你嘗試過所有的替代間隔字元嗎，包括不換行空格？別忘了「窄不換行空格」（NARROW NO-BREAK SPACE, U+202F）。

你嘗試過用零寬非連接字元（zero-width non-joiner, U+200C）取代空格嗎？它可能不會給你完全想要的結果，但可能更接近你想要的，或者是解決方案的一部分。

我處理過許多涉及 RTL（從右到左）標記的工作，即便如此，當我嘗試應用它們時，有時還是會驚訝於它們沒有出現在正確的位置。（也許是我真的沒有完全理解這些規則……） 所以我建議嘗試其他所有組合 - 在你上面的變更中，將 \u200f 放在空格之後，放在空格的前後，或者在 \rb 之後、欄位結束之前插入一個。也許其中一種組合能達到你想要的效果。（如果它產生了期望的結果，你不需要理解它！）

祝好運……

機器翻譯自 English 顯示原文

Answer 2

這可能是處理這個問題的不當方式，但當我們處理類似你描述的情況時，我建議使用一個不在阿拉伯語正字法中、但在 Unicode 中定義為 RTL（從右到左）的字元，而不是嘗試解決方向宣告字元（directional announcement glyphs）的正確序列。

也就是說，在每個釋義中的阿拉伯語單詞之間，不要使用空格 \u0020，而是使用一個寬度相似但在 Unicode 中定義為 RTL 的字元……例如希伯來語的 Pasiq \u05c0。這使得問題變成如何隱藏希伯來語標點，這可以透過將其塗成透明色來解決。

然而，在我提到的那個案例中，原因與阿拉伯語文字中的數字有關，我們在轉換過程中因為某些字型問題將它們標記為「義大利語」。這個「數字用的義大利語」是一個與我們使用的字型相關的全域設定，並非專門針對阿拉伯語排版。這種語言設定的變更導致了鄰近空格和標點的問題。在那種情況下，最終的解決方案是將數字重新分類為另一種語言（但據我記憶，仍然不是阿拉伯語。） 但這是為了建議，確保文字中的語言設定正確，可能會影響字元的排列，而無需訴諸像我建議的那樣更奇特的修復方法。也就是說，編排器似乎將空格解釋為 LTR（從左到右），這意味著它認為它們是希臘文，而不是阿拉伯文。 如果你確保用於釋義文字的字元樣式將所有字元定義為阿拉伯語，那可能就是你唯一需要做的。

機器翻譯自 English 顯示原文

Answer 3

我的第一個想法與 Jeff 的建議之一一致——我猜測 U+200F 標記需要緊跟在單詞之前，也就是在空格之後，而不是之前。

我假設 \rb 部分中的文字方向只是由主要語言的整體文字方向設定的，而要覆蓋這一點需要開發團隊重新編程。

最後一個建議是嘗試使用類似底線字元的東西，但將其樣式設為與背景相同的顏色。所以也許可以像這樣：
in "\|.*?\\rb\*": " " > "\\sc _\\sc\*"
然後將小型大寫（Small Caps）樣式設為該顏色。基本上可以是任何你沒有在其他地方使用的字元樣式。

機器翻譯自 English 顯示原文

Answer 4

感謝大家提供這些想法。

是的 - 我確實嘗試了其他間隔字元，它們確實產生了不同大小的空格，但方向仍然會翻轉。我嘗試在空格的一側或兩側（以及為了嘗試一切——在任何字串之前）添加 RTL 標記。

Jeff - 我確實嘗試了零寬非連接字元，它運作正常！（但沒有留下空格）。我想我可以啟用該字元，然後將其定義為一定量的膠合（glue，即空格）？我的 TeX 知識非常生疏，我不確定該怎麼辦。我嘗試了：

\catcode`\‌=\active
\def‌{\bgroup\hskip 0.25em\egroup}

（在 \catcode `\ 和 \def 之後有一個 200c）

這可以運作 - 但它給出的結果與空格相同（這並不令人驚訝，因為它現在就是一定量的空格）。

我也嘗試了：

\catcode`\‌=\active
\def‌{\bgroup\beginR\hskip 0.25em\egroup}

這是一個不同的結果，但仍然不正確——我知道我現在是在盲目摸索。

Malachi - 我嘗試了你的建議，但結果是 TeX 錯誤，我不會貼在這裡。我想問題在於它將 USFM 標記插入到了 \rb ...|...\rb* 的屬性部分中。

既然我無法在那裡添加標記，我想嘗試將一個從右到左的字元著色來取代空格（Michael 的建議），但我真的不知道自己在做什麼。我嘗試了以下代碼，用 Paseq 取代空格：

\catcode`\׀=\active
\def׀{\bgroup\color{white}׀\egroup}

但我收到關於 ! Argument of \color has an extra } 的抱怨。

我不知道如何使用\color，或者它是否甚至可以這樣使用，或者是語法問題。我知道我現在是在黑暗中摸索。

如果不著色，Paseq 本身其實運作得很好！我希望有一個具有從右到左屬性的空格字元。

感謝回覆和想法。

Jeff

機器翻譯自 English 顯示原文

Answer 5

之前，我暗示我們在專注於語言作為解決方案之前，正在尋求一個「方向宣告」解決方案，以確保逗號出現在數字緊鄰時（特別是在節範圍中）正確單詞的「後面」。

LTR 和 RTL 覆蓋字元（override glyphs）是用來強制編排器以某種方式解釋後續字元的。 但它們會影響你使用它們的任何地方的顯示（或者可能不影響……），所以理解它們在文字流中的位置變得非常有趣。最終，在 InDesign CS6 中，當有幾個複雜的編排外掛程式在運作，以及一個具有已知 OpenType「功能」並導致方向性問題的字型時，它們仍然沒有做到標籤上所說的那樣。

但如果你有能力向 PTX print 的正則表達式輸入 unicode " \u 字元，或者使用 html 實體 &…; 術語而不是實際字元，unicode 方向覆蓋字元可能會起作用。即使你處理的是字元本身，它們在這種情況下也可能有效，但再次強調，這些字元幾乎在任何出現的地方都會打亂後續字元的顯示順序，因此解釋你實際看到的是很棘手的，並且很快就會導致使用十六進位編輯器分析來恢復你的文件和理智。

fileformat.info

RIGHT-TO-LEFT OVERRIDE (U+202E)

Get the complete details on Unicode character U+202E on FileFormat.Info

fileformat.info

LEFT-TO-RIGHT OVERRIDE (U+202D)

Get the complete details on Unicode character U+202D on FileFormat.Info

機器翻譯自 English 顯示原文

Answer 6

看來我們需要一點幫助。我已經在逐字對照處理代碼中添加了開始和結束掛鉤（hooks）的支持。因此，在理論上（未經測試），你應該能夠添加一行像：

\sethook{start}{gloss|rb}{\beginR}

然後一切就都好了。

我剛剛提交了這個變更，所以它應該包含在下一個版本 2.2.46 或更高版本中。至於我們是否需要為此提供一些 GUI（圖形用戶界面），這取決於社區的請求。這又是另一個核取方塊（checkbutton）。我們想要「又一個核取方塊」嗎？

機器翻譯自 English 顯示原文

Comments

感謝添加幫助，Martin！

我今天下午安裝了 2.2.46，並在 ptxprint-mods.tex 中添加了 \sethook{start}{gloss|rb}{\beginR}。不幸的是 - 似乎沒有效果。輸出與之前相同 - 包括嘗試在空格前添加 U+200F 或 U+202D。

機器翻譯自 English 顯示原文

---

jklassen:

\sethook{start}{gloss|rb}{\beginR}

我剛在更新到 2.2.50 後再次嘗試了這個，現在烏爾都語釋義中的正確 RTL 渲染已經可以運作了。太棒了！

機器翻譯自 English 顯示原文

---

我需要這個按鈕！我的支持者找到了這個支援討論串，這解決了問題。我想這對於任何製作帶有阿拉伯文字釋義的聖經文字逐字對照的人來說可能都是需要的。

機器翻譯自 English 顯示原文