RTL श्लोक संदर्भ गलत क्रम में छपे (Modules में)

Question

जब मैंने अरबी लिपि आधारित भाषा के लिए एक मॉड्यूल छपाया, तो मुझे लगा कि श्लोक संदर्भ गलत ढंग से छप रहे हैं। यहाँ मेरे मॉड्यूल SFM फ़ाइल से प्रविष्टि है:

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

यहाँ वह आउटपुट है जो मुझे PTXprint 2.3.45 से मिला:

(अनुवाद: “1:1-27 Genesis” — अध्याय/श्लोक का भाग ठीक उसी तरह छपा है जैसे LTR भाषा में होता है।)

लेकिन दाएं से बाएं की ओर, यह होना चाहिए: पुस्तक का नाम, खाली जगह, अध्याय संख्या, कोलन, प्रारंभिक श्लोक, हाइफ़न, अंतिम श्लोक

अब जब मैं इसकी तलाश कर रहा हूँ, तो मुझे समान त्रुटि समानांतर पदों (parallel passage) के शीर्षकों में भी दिखाई देती है।

English से मशीन-अनुवादित मूल दिखाएं

Answer 1

There are quite a few possibilities of where things are going wrong here:

1. Is the document actually set RTL, or is the \s actually what the module says? We do have the possibility to do what I call a “series diglot” (switching all the language settings for relevant parts of the publication) but it’s not automatic.
2. The ($(GEN...)) reference might be generating incorrect intermediate output. To Test: Could you have a look at the final USFM tab and see if it looks right or wrong there?
3. There might be some unicode direction switching bytes getting supplied which are confusing something. To Test: Could you type (not copy and paste) a number range into an extra \r and see if that works?
4. I suppose it’s possible that for some reason \r might be forgetting that the document is RTL. To Test: could you type a range into some other line where things are formatting correctly?

Answer 2

इतनी जल्दी इस पर पहुंचने के लिए धन्यवाद।

1. यह एक पूरी तरह से RTL दस्तावेज़ है। मुझे याद नहीं है कि क्या मुझे PTXprint को यह बताना पड़ा था, या क्या यह Paratext से मिला था।

2. क्या आप मुझे बता सकते हैं कि यह कैसे किया जाए? मुझे PTXprint में वह टैब नहीं दिख रहा है।

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 text is weird. Numbers are actually displayed in LTR format. So if you got rid of the colon and the hyphen, the correct display of that string of numbers would be:
i.e. “1127”, reading left-to-right

If I paste the text from your \s above into Word, I get the following (exactly what you are seeing in PTXprint):

However, if I paste it into LibreOffice Writer, I get the following:

(what you were hoping to get)

In this case, I think Word is actually more correct. The numbers are LTR, and the colon and the hyphen are “Neutral” in their bidirectionality (see Bidirectional text - Wikipedia). That means that they don’t force a direction on the text, but take it from the surrounding context. And since they are in the context of LTR characters (the numbers), they should keep the LTR direction, and that whole string of numbers and punctuation should be presented on the line in an LTR direction, as PTXprint is doing.

So from that perspective what PTXprint is producing is theoretically correct (from the bidirectional text algorithm). But that’s actually not what you want. We are reading our text RTL, and we want the different chunks (separated by punctuation) to appear one after the other from RTL, like shown in the LO Writer output above. (I don’t actually know why the LO Writer output is like that. It doesn’t seem like it is following the Unicode bidi algorithm…)

But I can get that behavior in Word by adding special marks called Right-to-left marks. They are Unicode codepoint U+200F (see Right-to-left mark - Wikipedia). You can insert these marks after a punctuation to force an RTL text direction for that punctuation. To do that in Word, put the insertion put after the colon (I would recommend using the arrow keys to find that spot), type “200F” and type Alt+X (hold down the Alt key and tap the X key). Your chapter one should now jump to the right of your string of numbers and punctuation. Do the same after the hyphen, and your string will look the same as the LO Writer output above.

But now the tricky part is getting those RTL marks inserted in the text for PTXprint. I haven’t tested this, but I think you might be able to use Changes.txt (on the Advanced tab) to create rules that will insert the RTL marks in the proper places. Try these rules (untested):
'(\d):(\d)' > '\1:\u200f\2'
'(\d)-(\d)' > '\1-\u200f\2'

But there is one more interesting issue. I notice that you are using the Eastern Arabic-Indic digits, which start at U+06F0. (See https://www.unicode.org/charts/PDF/U0600.pdf.) I’ve mostly used the plain Arabic-Indic digits, which start at U+0660. I think the \d digit designation should work for those digits as well, but if it doesn’t, you might need to use something like this: [\u06F1-\u06F9] in place of \d.

Anyway, that gives you something to try. And we’ll all be interested to know if you make progress!

Jeff

Comments

और मुझे यह भी संकेत देना चाहिए कि इस प्रकार की मैन्युपुलेशन वह नहीं है जो औसत PTXprint उपयोगकर्ता को करना चाहिए। यदि यह वास्तव में RTL टेक्स्ट के लिए एक वैश्विक समस्या है, तो हमें PTXprint के लिए एक तरीका खोजना चाहिए जो इसे “under the hood” ठीक करे, ताकि उपयोगकर्ता को वांछित आउटपुट प्राप्त करने के लिए अत्यंत उपायों का सहारा लेने की आवश्यकता न हो।

English से मशीन-अनुवादित मूल दिखाएं

Answer 6

चलिए, ताकि लक्ष्य स्पष्ट हो, यहाँ एक प्रकाशित फ़ारसी अनुवाद की तस्वीर है जिसमें समानांतर पाठ संकेतक (parallel passage indicator) है। पहला संदर्भ मत्ती 6:25-33 का है, और दृश्य क्रम है: 33-25:6 Matthew

shot3096×1292 254 KB

आप बिल्कुल सही कह रहे हैं कि अंक LTR (बाएं से दाएं) में लिखे जाते हैं, लेकिन जब आपके पास विभाजक (delimiters) आदि होते हैं, तो यह ऐसा होता है जैसे अंकों की एक श्रृंखला एक शब्द हो। फिर सभी शब्दों को RTL (दाएं से बाएं) क्रम में व्यवस्थित किया जाता है।

Microsoft Word रहस्यमयी है। यदि मैं श्लोक संदर्भ टाइप करता हूँ, तो यह सही आता है (वास्तव में, चाहे मैंने अनुच्छेद को RTL या LTR में सेट किया हो)। यदि मैं इस ब्राउज़र विंडो से कॉपी और पेस्ट करता हूँ, तो यह गलत आता है (फिर भी, चाहे अनुच्छेद RTL और LTR हो)। WYSIAYG, मुझे लगता है।

यहाँ कुछ चीज़ें हैं जो मैं गलत परिणाम को दोहराने के लिए कर सकता हूँ (Word या अन्य GUI में):

• संदर्भ की शुरुआत में एक LEFT-TO-RIGHT मार्कर (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 एल्गोरिदम का पालन करता है, हालांकि यह आपको वह नहीं देता जो आप चाहते हैं। bidi एल्गोरिदम कहता है कि कॉलन और हाइफन न्यूट्रल (तटस्थ) वर्ण हैं, और वे आस-पास के वर्णों के प्रवाह के साथ चलेंगे। जब वे LTR वर्णों की एक श्रृंखला (जैसे अंक) में होते हैं, तो वे LTR में जारी रहते हैं, जिससे आपको वह परिणाम मिलता है जो आप देख रहे हैं। xepersian पैकेज प्रतीत होता है कि उन विराम चिह्नों के bidi गुणों को बदल देता है, जिससे आपको वह मिलता है जो आप चाहते हैं। दिलचस्प बात यह है कि Word में, यदि आप कॉलन और हाइफन के बाद एक स्पेस डालते हैं, तो यह संदर्भ को उसी तरह उलट देता है जिस तरह आप चाहते हैं (लेकिन अतिरिक्त स्पेस के साथ)। यह वास्तव में बहुत अजीब है क्योंकि स्पेस भी bidi एल्गोरिदम में Neutral के रूप में सूचीबद्ध हैं (ऊपर दिए गए लिंक देखें)। मुझे विश्वास है कि कई RTL लिपि परियोजनाओं ने Paratext में इस तकनीक का उपयोग किया है ताकि संदर्भ “सही” दिशा में मुड़ें। लेकिन RTL मार्क के जोड़ से वही काम होता है बिना स्पेस जोड़े।

क्या आप शायद उन नियमों को Changes.txt फ़ाइल में डालकर देख सकते हैं कि यह क्या करता है?

ध्यान दें कि आपके मॉड्यूल में आप अपने संदर्भ सामान्य (अरबी!) अंकों में दर्ज कर रहे हैं। क्या आपके Paratext प्रोजेक्ट में ऐसे कोई संदर्भ हैं जो पहले से ही अरबी-शैली (हिंदी!) अंकों में दर्ज किए गए हैं? यदि हां, तो वे Paratext में कैसे दिखाई देते हैं? मुझे विश्वास है कि Paratext स्वतः ही एक RTL प्रोजेक्ट में ऐसे संदर्भों में एक RTL मार्क U+200F सम्मिलित करता है, ताकि वे सही दिखें। मैं मानता हूँ कि PTXprint भी एक समान काम कर सकता है। (हालांकि, ध्यान दें कि Paratext प्रतीत होता है कि RTL मार्क को कॉलन से पहले सम्मिलित करता है, जो कि मुझे लगता है कि एक वैध विकल्प भी है।)

English से मशीन-अनुवादित मूल दिखाएं

Answer 8

हाँ, यदि मैं उन कमांड्स को changes फ़ाइल में डालता हूँ, तो श्लोक सही आते हैं। उस सुधार के लिए धन्यवाद।

यदि आप केवल अध्याय/श्लोक के हिस्से (۱:۱-۲۷) को देखें, तो यह bidi एल्गोरिदम के अनुसार काम कर रहा है। लेकिन उस एल्गोरिदम के अनुसार, आपको उम्मीद होगी कि पुस्तक के नाम (जो RTL वर्णों से बना है) की उपस्थिति इसे RTL मोड में बदल दे (پیدایش ۱:۱-۲۷)। (इस टेक्स्ट एडिटर में और प्रीव्यू विंडो में, जहाँ मैं यह टाइप कर रहा हूँ, वही होता है।) इसलिए मैं कल्पना कर रहा हूँ कि अध्याय/श्लोक का हिस्सा अपने ही \hbox या कुछ ऐसे में है, और किसी कारण से यह नहीं जानता कि यह एक RTL दस्तावेज़ में है।

(मैं इसे बहुत दूर नहीं ले जाना चाहता, लेकिन यदि दस्तावेज़ वैश्विक रूप से RTL में सेट नहीं है, तो अन्य समस्याएं भी छिपी हो सकती हैं। मुझे यह नोटिस होता है कि फुटनोट मार्कर शब्दों के गलत पक्ष पर दिखाई देता है, उदाहरण के लिए। वे शब्द के दाएं पक्ष पर दिखाई देते हैं, बाएं पक्ष पर नहीं। मुझे निश्चित रूप से नहीं पता, लेकिन यह एक LTR/RTL मुद्दा लगता है।)

मैंने अरबी-इंडिक अंकों के साथ प्रयास नहीं किया है। हालांकि, मैंने कभी ऐसी स्थिति का सामना नहीं किया है जहाँ कुछ अरबी-इंडिक अंकों के साथ काम करता हो लेकिन पूर्वी अरबी-इंडिक अंकों के साथ न करे।

English से मशीन-अनुवादित मूल दिखाएं

Comments

चलिए, यह अच्छा है कि आपके पास अभी के लिए एक वर्क-अराउंड है। मैं @mjpenny के साथ इस पर चर्चा करने की कोशिश करूंगा कि देखूं कि क्या PTXprint में कुछ किया जाना चाहिए।

यदि आप bidi एल्गोरिदम को फिर से देखें (Bidirectional text - Wikipedia), तो ध्यान दें कि अंक “Weak” (कमजोर) अनुभाग में पाए जाते हैं। मैंने माना था कि वे “Strong” (मजबूत) वर्ण हैं, और वे मध्यवर्ती “Neutral” (तटस्थ) वर्णों की दिशा को परिभाषित करेंगे। लेकिन अब मैं समझता हूँ कि आप क्या कह रहे हैं, कि पुस्तक का नाम (“Strong” RTL वर्णों में) डालना “Weak” अंकों को “Neutral” वर्णों की दिशा को परिभाषित करने के लिए ओवरराइल कर देता है।

English से मशीन-अनुवादित मूल दिखाएं

Answer 9

नमस्ते,

मुझे पक्का नहीं है कि क्या मैं इस थ्रेड में कोई ऐसी जानकारी जोड़ रहा हूँ जो पहले से ही ज्ञात नहीं है। मैंने कई RTL परियोजनाओं के टाइपसेटिंग में भाग लिया है। मैं बस यह जोड़ना चाहता हूँ कि मुझे Paratext के RTL पाठों और संदर्भों के साथ कैसे इंटरैक्ट करने के बारे में पता है।

जब Paratext में एक RTL प्रोजेक्ट संपादित किया जाता है, तो Paratext उन स्ट्रिंग्स की पहचान करता है जो एक पवित्र ग्रंथ संदर्भ के प्रारूप का पालन करती हैं, या एक अंकीय सीमा – यानी #:#, #.#, #:#-#, #:#,# जैसे पैटर्न। जैसे ही ये खुले अध्याय में पहचाने जाते हैं जिसे संपादित किया जा रहा है, Paratext विराम चिह्नों के पहले U+200F सम्मिलित करता है, जिससे वे पूर्ववर्ती संख्या के बाएं पक्ष पर दिखाई दें (जो अन्यथा संख्या(ओं) द्वारा प्रारंभित LTR दिशा को ओवरराइड कर देता है)।

तो, इसके बजाय:

आप यह देखते हैं:

यदि आप Paratext में संदर्भ तार्किक क्रम में दर्ज करते हैं, तो आप उन्हें दर्ज करने पर पूरा करते समय यह दृश्य अपडेट देखेंगे।

तो, उन परियोजनाओं में जिनका संपादन Paratext में किया गया था, ये 200F वर्ण पहले से ही वहां हो सकते हैं। आप अपने changes.txt अभिव्यक्तियों में इसका ध्यान रखना चाह सकते हैं। मुझे विश्वास है कि यह सच है कि Paratext केवल उन अध्यायों के लिए 200F का यह सम्मिलन करता है जिन्हें संपादक में खोला गया है (यानी यह पूरे प्रोजेक्ट के माध्यम से नहीं जाता और यह काम नहीं करता)।

इसे Paratext में इसलिए किया गया था ताकि कोई भी डाउनस्ट्रीम प्रकाशक या प्रकाशन टूल पाठ को सीधे रेंडर कर सके – विशेष रूप से कुछ डिजिटल ऐप पथों के लिए महत्वपूर्ण जहाँ प्रकाशन पथ अनिवार्य रूप से changes.txt जैसे हस्तक्षेप की अनुमति नहीं देता।

यदि यह यहां किसी भी तरह से मदद करता है, तो मैं अपना समझदारी साझा कर रहा हूँ।

जेफ

English से मशीन-अनुवादित मूल दिखाएं