Mathjax: जटिल पाठ लेआउट, विशेष रूप से TeX इनपुट के साथ [था: MathJax जटिल पाठ लेआउट का समर्थन नहीं करता है।]

ध्यान दें कि यदि आप अपने कॉन्फ़िगरेशन के HTML-CSS और SVG अनुभागों में mtextFontInherit से true पर सेट करते हैं, तो MathJax \text{} को एक के रूप में संसाधित करेगा एकल <span> , और इसलिए जैसा आप अनुरोध करते हैं वैसा ही करना चाहिए। आप सही कह रहे हैं कि जब mtextFontInherit false हो तो MathJax बेहतर कर सकता है। प्रत्येक को एक अलग <span> में डालने के बजाय इसे "अज्ञात" वर्णों को एक संग्रह में समूहित करना चाहिए।

पुनश्च, मैंने विकिमीडिया बगजिला पर रिपोर्ट देखी और इसे ठीक करने के लिए चीजों की सूची में जोड़ने की योजना बना रहा था। इस मुद्दे को यहां ट्रैक करने के लिए इसे देखने के लिए धन्यवाद।

mtextFontInherit टिप के लिए धन्यवाद। मैं वैसे भी इसे सक्षम करने जा रहा था, लेकिन ऐसा करने का यह एक और कारण है।

आरटीएल के लिए कुछ समर्थन v2.3 में जोड़ा गया था, लेकिन एक इकाई के रूप में माने जाने वाले बहु-वर्ण अनुक्रमों का मुद्दा बना हुआ है। \text{} के लिए, इन वर्णों को पहले से ही एक <span> में समूहीकृत किया जाना चाहिए, ताकि इसे संभालने का यह एक तरीका हो, हालांकि यह बहुत सुविधाजनक नहीं है।

आदर्श रूप से, MathJax प्रत्येक अनुक्रम को रखेगा जो एक समूह को एक एकल <mi> या <mo> में बनाता है, जैसा कि यह अब एकल लैटिन अक्षरों के लिए करता है। मैंने इसे कुछ हद तक देखा है, और इसे संभालने में कुछ कठिनाइयां हैं। पात्रों को उनके पूर्ववर्ती पात्रों के साथ समूहीकृत करना संभव है, लेकिन यह मेरे लिए स्पष्ट नहीं है कि कुछ पात्र कैसे काम करते हैं। उदाहरण के लिए, ऐसा लगता है कि विरामा (U+0D4D) न केवल इसके बाईं ओर के चरित्र को जोड़ता है, बल्कि दाईं ओर भी, हालांकि मैं इसे गलत समझ सकता हूं। ऐसा भी लगता है कि इनमें से कुछ समूहों को अक्षरों के संयोजन से नहीं, बल्कि फोंट के भीतर लिगचर द्वारा नियंत्रित किया जाता है। दुर्भाग्य से, MathJax के पास फोंट से संयुक्ताक्षर जानकारी तक पहुंच नहीं है। हालांकि मैथजैक्स की फॉन्ट टेबल में लिगचर डेटा जोड़ना संभव होगा, यह एक महत्वपूर्ण मात्रा में डेटा हो सकता है, जिसमें से बहुत कम किसी एक पेज द्वारा उपयोग किया जाएगा।

मैं वास्तव में उन भाषाओं से परिचित नहीं हूं जो इन सुविधाओं का उपयोग यह जानने के लिए करती हैं कि मैं जो कोशिश कर रहा हूं वह पर्याप्त होगा या नहीं। मैं सोच रहा हूं कि क्या विभिन्न भाषाओं से कुछ उदाहरण प्राप्त करना संभव है जो परिस्थितियों की सीमा को दिखाते हैं जिन्हें समायोजित करने की आवश्यकता है।

एक दृष्टिकोण यह हो सकता है कि प्रत्येक भाषा की स्क्रिप्ट के लिए आवश्यक डेटा को एक व्यक्तिगत एक्सटेंशन में रखा जाए, जो उन पृष्ठों के लिए लोड हो जाए, जिन्हें इसकी आवश्यकता है (या तो स्पष्ट रूप से MathJax कॉन्फ़िगरेशन में, या \require{} के माध्यम से पृष्ठ पर गणित के भीतर)। क्या आपको लगता है कि यह स्वीकार्य होगा?

शायद हमारे WMF भाषा इंजीनियरिंग के @ amire80 यहाँ थोड़ी मदद करने में सक्षम हैं ...

@hartman क्या आपको लगता है कि आप कुछ समय के लिए @ amire80 प्रहार कर सकते हैं? हमें इसमें सुधार करना अच्छा लगेगा, खासकर यदि विकिपीडिया एसवीजी आउटपुट को अधिक व्यापक रूप से रोल आउट करना चाहता है।

मैं बिल्कुल यहाँ हूँ :)

मैं आपकी कैसे मदद कर सकता हूँ?

परिक्षण? - खुशी से, बस मुझे बताओ कि वास्तव में क्या परीक्षण करना है।

गैर-लैटिन लिपियों के फ़ार्मुलों में काम करने के उदाहरण? - इसका उपयोग हिब्रू पाठ्यपुस्तकों में नहीं किया जाता है, लेकिन इसका उपयोग अरबी और फारसी की पाठ्यपुस्तकों में किया जाता है। हो सकता है कि @ebraminio यहां झंकार कर सके।

और कुछ?

@amire80 द्वारा रुकने के लिए धन्यवाद :-)

मैं आपकी कैसे मदद कर सकता हूँ?

मुझे आशा है कि हम गैर-लैटिन लिपियों में संयुक्त वर्णों के संचालन में सुधार कर सकते हैं। यह बार-बार डब्लूएमएफ बगजिला/फैब्रिकेटर पर आया है। डेविड को https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717 से उद्धृत करने के लिए:

आदर्श रूप से, मैथजैक्स प्रत्येक अनुक्रम को एक समूह में एक समूह में रखता हैया, जैसा कि अब एकल लैटिन अक्षरों के लिए होता है। मैंने इसे कुछ हद तक देखा है, और इसे संभालने में कुछ कठिनाइयां हैं। पात्रों को उनके पूर्ववर्ती पात्रों के साथ समूहीकृत करना संभव है, लेकिन यह मेरे लिए स्पष्ट नहीं है कि कुछ पात्र कैसे काम करते हैं। उदाहरण के लिए, ऐसा लगता है कि विरामा (U+0D4D) न केवल इसके बाईं ओर के चरित्र को जोड़ता है, बल्कि दाईं ओर भी, हालांकि मैं इसे गलत समझ सकता हूं। ऐसा भी लगता है कि इनमें से कुछ समूहों को अक्षरों के संयोजन से नहीं, बल्कि फोंट के भीतर लिगचर द्वारा नियंत्रित किया जाता है। दुर्भाग्य से, MathJax के पास फोंट से संयुक्ताक्षर जानकारी तक पहुंच नहीं है। हालांकि मैथजैक्स की फॉन्ट टेबल में लिगचर डेटा जोड़ना संभव होगा, यह एक महत्वपूर्ण मात्रा में डेटा हो सकता है, जिसमें से बहुत कम किसी एक पेज द्वारा उपयोग किया जाएगा।

मैं वास्तव में उन भाषाओं से परिचित नहीं हूं जो इन सुविधाओं का उपयोग यह जानने के लिए करती हैं कि मैं जो कोशिश कर रहा हूं वह पर्याप्त होगा या नहीं। मैं सोच रहा हूं कि क्या विभिन्न भाषाओं से कुछ उदाहरण प्राप्त करना संभव है जो परिस्थितियों की सीमा को दिखाते हैं जिन्हें समायोजित करने की आवश्यकता है।

तो हमारा सवाल होगा: क्या किसी के पास विशेषज्ञता है जो वे हमारे साथ साझा कर सकते हैं? @hartman आपको इंगित करने के लिए बहुत दयालु था ;-)

(शायद हमें इसे एक अलग मुद्दे में विभाजित करना चाहिए।)

विरामा का (बहुत) मूल विचार यह है कि व्यंजन + विरामा + व्यंजन के अनुक्रम में तीन यूनिकोड वर्ण हैं, जो एक ग्लिफ़ के स्थान पर कब्जा करते हुए दिखाई देते हैं (लेकिन यह कहीं अधिक जटिल हो सकता है)।

अधिक सामान्यतः, मुझे MathJax की वर्तमान स्थिति को समझना अच्छा लगेगा। वर्तमान प्रतिपादन का परीक्षण करने के लिए मुझे क्या करना चाहिए? मेरा खुद का उदाहरण स्थापित करें? या क्या कोई ऑनलाइन उदाहरण है जहां वर्तमान संस्करण का परीक्षण किया जा सकता है?

व्यंजन + विरामा + व्यंजन में तीन यूनिकोड वर्ण हैं, जो एक ग्लिफ़ के स्थान पर कब्जा करते हुए दिखाई देते हैं

सही। गणितीय लेआउट में संयुक्त वर्ण काफी सामान्य हैं इसलिए हम सामान्य रूप से स्थिति को समझते हैं।

(लेकिन यह कहीं अधिक जटिल हो सकता है)।

यही हमारी समस्या है। हमारे पास अधिकांश प्राकृतिक भाषा, गैर-लैटिन लिपियों के लिए विशिष्टताओं का अभाव है।

या क्या कोई ऑनलाइन उदाहरण है जहां वर्तमान संस्करण का परीक्षण किया जा सकता है?

आप इसे मीडियाविकि पर (गणित विस्तार के MathML/SVG मोड का उपयोग करके), ब्राउज़र में ( यह नमूना या यह कोडपेन ) कर सकते हैं या MathJax की स्थानीय प्रति का उपयोग कर सकते हैं - जो भी आपको पसंद हो।

एक बुनियादी उदाहरण: ത്ര को ത്ര में बदल दिया जाएगा और चूंकि हमारे पास इस प्रकार के संयुक्त वर्णों की पहचान करने के लिए कोई रूटीन नहीं है, इसलिए TeX इनपुट इसे आंतरिक रूप से MathML में परिवर्तित करता है

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mrow class="MJX-TeXAtom-ORD">
    <mo>&#xD24;</mo>
  </mrow>
  <mrow class="MJX-TeXAtom-ORD">
    <mo>&#xD4D;</mo>
  </mrow>
  <mrow class="MJX-TeXAtom-ORD">
    <mo>&#xD30;</mo>
  </mrow>
</math>

जो मैथजैक्स आउटपुट बदले में तीन स्पैन (एचटीएमएल आउटपुट में) या तीन जी (एसवीजी आउटपुट में) में विभाजित हो जाएगा - और निश्चित रूप से यह संयुक्त चरित्र के प्रतिपादन को तोड़ देता है।

(मैंने अभी देखा है कि फ़ायरफ़ॉक्स कभी-कभी HTML आउटपुट में स्पैन को जोड़ता है, उदाहरण के लिए, ത്ര लेकिन കു_ശ में सबस्क्रिप्ट नहीं। क्रोम अधिक "सुसंगत" है जिसमें कुछ भी संयुक्त नहीं है)

तो हमारे लिए समस्या यह है: क्या डेटा का एक संक्षिप्त सेट (या कुछ कुशल अनुमानी) है जिसका उपयोग हम उन सभी प्रासंगिक परिस्थितियों की पहचान करने के लिए कर सकते हैं जहां हमें MathML में एक मील/मो तत्व में पुन: संयोजन करने की आवश्यकता है? एक बार हमारे पास यह हो जाने के बाद, प्रतिपादन भी काम करेगा।

तो हमारे लिए समस्या यह है: क्या डेटा का एक संक्षिप्त सेट (या कुछ कुशल अनुमानी) है जिसका उपयोग हम उन सभी प्रासंगिक परिस्थितियों की पहचान करने के लिए कर सकते हैं जहां हमें MathML में एक मील/मो तत्व में पुन: संयोजन करने की आवश्यकता है?

लंबी टिप्पणी के लिए क्षमा करें, इश्यू ट्रैकर पर थोड़ी ऑफ साइट चर्चा वापस लाना।

यूनिकोड यूसीडी डेटाबेस बनाना कितना संभव/महंगा होगा?
प्रत्येक चरित्र के लिए मैथजैक्स के लिए उपलब्ध वर्ग का संयोजन? मूल रूप से (या
कम से कम एक अच्छे पहले सन्निकटन के रूप में) गैर शून्य वाला कोई भी चरित्र
संयोजन वर्ग (यूनिकोडडेटा.टीएक्सटी में फ़ील्ड 4) के साथ रहने की जरूरत है
एक से पहले, और इसके अतिरिक्त यदि यह कक्षा 9 (विरमा) है तो निम्नलिखित
चरित्र को भी साथ रखने की जरूरत है।

शायद यह भी ध्यान देने योग्य है कि टेक्स, यहां तक ​​​​कि यूनिकोड टेक्स जैसे xetex
या luatex लगभग निश्चित रूप से _not_ के बिना यह अधिकार प्राप्त करने जा रहे हैं
मार्कअप
यानी आपको \text{abc} या \mathit{abc} या कुछ अन्य की आवश्यकता होगी
वर्णों की एक स्ट्रिंग को टेक्स्ट के रूप में टाइप करने के लिए बाध्य करने के लिए आदेश a
चीजों को विभाजित करने की TeX की सामान्य आदत के बजाय एकल फ़ॉन्ट
चरित्र द्वारा चरित्र। भले ही कंस्ट्रक्शन _looks_ सिंगल की तरह हो
लेखक के लिए चरित्र।

क्लासिक टेक्स में यह कोई समस्या नहीं है क्योंकि फोंट में केवल 256 वर्ण हो सकते हैं
और जबकि कंपोज्ड कैरेक्टर्स को विभिन्न मैक्रो रीमैपिंग ट्रिक्स के साथ सपोर्ट किया जा सकता है
आधार का अनुसरण करने वाले पात्रों की रचना करना मूल रूप से सरल के लिए भी सहायक नहीं है
तीव्र की तरह उच्चारण रचना।

यूनिकोड टेक्स वेरिएंट जैसे xetex और luatex में समर्थन थोड़ा परिवर्तनशील लगता है। पाठ में, xetex
चीजों को हार्फ़बज़ लाइब्रेरी को सौंप देता है इसलिए यह बहुत अच्छा करता है। luatex इसे आंतरिक रूप से संभालता है और वर्तमान में virama के साथ कम अच्छा करता है। गणित में दोनों को कुछ भी उपयोगी करने के लिए एक opentype MATH तालिका के साथ एक फ़ॉन्ट की आवश्यकता होती है और मुझे ऐसा कोई फ़ॉन्ट नहीं मिला जिसमें विरामा हो।

निम्नलिखित लेटेक्स दस्तावेज़ पाठ में कार्तिक और गणित में लैटिन आधुनिक गणित का उपयोग कर रहा है, आप ध्यान देंगे कि
यहां तक ​​कि यूरोपीय उच्चारण भी आमतौर पर गणित में विफल हो जाते हैं, लेकिन यदि आप कुछ मार्कअप \mbox यहां या mi या mtext समान रूप से MathML में जोड़ते हैं तो विरामा उदाहरण भी काम करता है।

छवि शीर्ष पर xetex और नीचे luatex दिखाती है।

तो जब \text{..} या \mbox{...} जैसे वर्ण स्ट्रिंग के आस-पास कुछ की आवश्यकता नहीं है, यह वांछनीय होगा, यह आपके यूनिकोड समर्थन को टीएक्स वर्तमान में प्राप्त करने के आगे एक लंबा रास्ता तय करेगा
तो यह इस बात पर थोड़ा निर्भर करता है कि "टेक्स-जैसे सिंटैक्स" का विनिर्देश क्या है, टीएक्स क्या कर सकता है, क्या इसे धक्का देना उचित है?

\documentclass{article}

\usepackage{fontspec}
\usepackage{unicode-math}
\setmainfont{kartika.ttf}


\begin{document}

U+0d24 U+0d4d U+0d30 outputs e.g., ത്ര but 

abc $abc \mbox{ത്ര} $  U+0063

abç $abç \mbox{ത്ര} $ U+00e7

abç $abç \mbox{ത്ര} $  U+0063 U+0327

\end{document}

मुझे वास्तव में यकीन नहीं है कि क्या मैं समझता हूं कि चर्चा किस बारे में है, लेकिन अगर विचार यह पहचानना है कि वर्णों का कौन सा अनुक्रम एक इकाई का गठन करता है, तो यूनिकोड ग्रैफेम क्लस्टरिंग को आवश्यक जानकारी प्रदान करनी चाहिए।

हाँ - जो @khaledhosny कहते हैं वह मुझे सही लगता है, हालाँकि मैं इसके साथ हर अनुभवी नहीं हूँ। हो सकता है कि @santhoshtr अधिक विवरण में योगदान दे सके।

संतोष, मुझे लगता है कि @pkra ने ऊपर तीन टिप्पणियां लिखी हैं जो समस्या को सबसे अच्छी तरह बताती हैं।

3 मार्च 2015 को 12:05 बजे, खालिद होस्नी नोटिफिकेशन @github.com ने लिखा:

मुझे सच में यकीन नहीं है कि मैं समझता हूं कि चर्चा किस बारे में है, लेकिन अगर
विचार यह पहचानना है कि वर्णों का कौन सा क्रम एकल का गठन करता है
यूनिट, फिर यूनिकोड ग्रैफेम क्लस्टरिंग
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries चाहिए
आवश्यक जानकारी प्रदान करें..

हां, लेकिन मुझे लगता है कि सवाल यह है कि जावास्क्रिप्ट के लिए यह कितनी दूर है
ऐसा करने के लिए पुस्तकालय
हाथ से अगर अंतर्निहित मंच यूनिकोड गुण नहीं बनाता है
उपलब्ध
और अगर यह टेक्स सिंटैक्स का अनुकरण कर रहा है तो टेक्स कितनी दूर जाएगा? आप उतना ही जानते हैं
किसी के रूप में टेक्स समर्थन के बारे में। xetex to . में यह कहाँ तक उचित होगा?
ऐसे क्लस्टर को _math_ में कुछ भी समझदार करने के लिए टेक्स्ट से बचने के बिना करें
\text{..} या कुछ ऐसे कमांड के साथ, जिसे आप असाइन नहीं कर सकते हैं a
\mathclass ऐसे क्लस्टर में?

मुझे ग्रैफेम्स के लिए कॉफीस्क्रिप्ट कार्यान्वयन मिला।
https://github.com/devongovett/grapheme-breaker

उपयोगी हो सकता है।

सभी उपयोगी टिप्पणियों के लिए धन्यवाद। संक्षेप में,

• xetex/luatex इस मुद्दे में अनुरोधित तरीके से इनपुट को हैंडल नहीं करता है, यानी बिना अतिरिक्त मार्कअप जैसे \text
• यह स्पष्ट नहीं है (कम से कम मेरे लिए) अगर इसे इस तरह से संभालने की योजना है
• एक समाधान सरल दृष्टिकोण से शुरू हो सकता है डेविड सी उल्लिखित या संभावित रूप से ग्रैफेम-ब्रेकर पर निर्माण कर सकता है (धन्यवाद @hartman!)

उसमें जोड़ने के लिए,

• दूसरी ओर, LaTeXML और pandoc के साथ एक त्वरित परीक्षण इंगित करता है कि वे यहाँ अनुरोध किए गए वर्णों को संभालते हैं, अर्थात, xetex/luatex की तरह नहीं।

तो मुझे ऐसा लगता है कि एक समाधान कोर टीएक्स इनपुट में नहीं हो सकता है लेकिन इसे एक विस्तार की आवश्यकता है। यह कोई समस्या नहीं है, निश्चित रूप से, क्योंकि यह शायद वैसे भी एक विस्तार समाप्त हो गया होता।

MediaWiki/WMF समुदायों से सुनना अच्छा होगा यदि वे वास्तव में यहां टीएक्स-इंजन से चित्रित करना चाहते हैं।

फिर से अधिक प्रतिक्रिया प्राप्त करना अच्छा होगा।

• टीएक्स लोगों पर, गणित मोड में वर्णों को अतिरिक्त मार्कअप के बिना xetex/luatex/etc की भविष्य की दिशा में संभाल रहा है?
• MediaWiki/WMF पर लोग: क्या गैर-मानक TeX व्यवहार वास्तव में संबंधित समुदायों द्वारा वांछित है?

अधिक प्रतिक्रिया के बिना, मुझे लगता है कि हमें इस पर ध्यान देना चाहिए / इसे 2.6 मील के पत्थर से बाहर निकालना चाहिए।

मुझे यहां इस मुद्दे को समझने दें, लोग $x+y=<complex character>$ जैसी चीजें करना चाहते हैं जहां <complex character> संभवतः एक बहु-कोड बिंदु ग्रैफेम है, और <complex character> को गणित पहचानकर्ता के रूप में माना जाता है, ठीक है ? यदि ऐसा है, तो मुझे लगता है कि यह एक उचित अपेक्षा है और यदि वर्तमान यूनिकोड टीएक्स इंजन इसे सही तरीके से संभाल नहीं पाते हैं (वे शायद नहीं करते हैं) तो यह संभवतः एक बग या गायब विशेषता है, डिज़ाइन द्वारा कुछ नहीं।

या यह है कि लोग $<complex text string>$ जैसी चीजें करना चाहते हैं, जहां <complex text string> एक बहु-वर्ण टेक्स्ट स्ट्रिंग है जिसे संभवतः जटिल टेक्स्ट लेआउट की आवश्यकता होती है, और उचित टेक्स्ट लेआउट (बीड़ी, आकार देना इत्यादि) प्राप्त करें। ? मुझे नहीं लगता कि यह एक उचित अपेक्षा है और यह इंगित करने के लिए यहां किसी प्रकार के मार्कअप की आवश्यकता है कि यह एक नियमित टेक्स्ट स्ट्रिंग है जिसे इस तरह माना जाना चाहिए।

धन्यवाद, @khaledhosny!

[...] लोग $x+y= . जैसी चीज़ें करना चाहते हैं$ कहाँसंभवतः एक बहु-कोड बिंदु ग्रैफेम है, और हैगणित पहचानकर्ता के रूप में माना जाता है, है ना?

हां, मैं भी इसे ऐसे ही समझता हूं। (यह कहना थोड़ा मुश्किल है क्योंकि यह मूल रूप से विकिपीडिया की ओर से एक अनुरोध है)।

मुझे लगता है कि यह एक उचित अपेक्षा है

धन्यवाद!

यदि वर्तमान यूनिकोड टीएक्स इंजन इसे सही ढंग से संभाल नहीं पाते हैं (वे शायद नहीं करते हैं) तो यह संभवतः एक बग या गायब विशेषता है, डिज़ाइन द्वारा कुछ नहीं।

उसके लिए भी धन्यवाद। "वे शायद नहीं करते" भाग मुझे थोड़ा चिंतित करता है लेकिन अगर आप और @davidcarlisle सहमत हैं कि यह यूनिकोड टीएक्स इंजनों में वांछित व्यवहार है, तो यह हमारे लिए पर्याप्त है, मुझे लगता है।

अभी भी उम्मीद है कि मीडियाविकि/डब्लूएमएफ/विकिपीडिया पक्ष इसमें शामिल होगा।

F2F के अनुसार, हम इसे v2.6 माइलस्टोन (यानी, आगामी रिलीज़) से हटा रहे हैं।

यह स्पष्ट नहीं है कि सही दृष्टिकोण क्या है, विशेष रूप से, TeX/LaTeX (या बल्कि XeTeX/LuaTeX) के साथ संगतता के संदर्भ में। यह भी स्पष्ट नहीं है कि WMF और विकिपीडिया समुदाय वास्तव में यहाँ क्या चाहते हैं।

स्पष्ट होने के लिए, हम इस मुद्दे को बंद नहीं कर रहे हैं और हम अभी भी यह पता लगाने में रुचि रखते हैं कि टीएक्स इनपुट में जटिल लेआउट कैसे काम कर सकता है।

भविष्य से विस्फोट: ग्रेफेम https://github.com/tc39/proposal-intl-segmenter द्वारा स्ट्रिंग्स को विभाजित करने की अनुमति देने के लिए (अन्य बातों के अलावा) एक TC39 प्रस्ताव "यूनिकोड सेगमेंटेशन" है। रिपॉजिटरी में एक पॉलीफ़िल का लिंक शामिल है (और स्पष्ट रूप से एक गैर-मानक क्रोम फ़ेउट्रे भी है)।

ठंडा। धन्यवाद, @pkra।

कोई दिक्कत नहीं है। पॉलीफिल दुर्भाग्य से बेकार है - यह केवल Enligsh को कवर करता है। लेकिन जो लोग इसे आज़माना चाहते हैं, उनके लिए क्रोम बिल्ड-इन उपयोगी हो सकता है।