Mathjax: تخطيط النص المعقد ، لا سيما مع إدخال TeX [كان: MathJax لا يدعم تخطيط النص المعقد.]

لاحظ أنه إذا قمت بتعيين mtextFontInherit على true في أقسام HTML-CSS و SVG من التكوين الخاص بك ، فإن MathJax سيعالج \text{} باعتباره واحد <span> ، ولذا يجب أن يتم ذلك كما طلبت. أنت محق في أن MathJax يمكن أن يكون أفضل عندما يكون mtextFontInherit هو false . يجب أن تجمع الأحرف "غير المعروفة" في مجموعة واحدة ، بدلاً من وضع كل منها في <span> منفصلة.

ملاحظة ، لقد رأيت التقرير عن Wikimedia bugzilla وكنت أخطط لإضافته إلى قائمة الأشياء التي يجب إصلاحها. شكرا للتحديق في المشكلة هنا لتتبع ذلك.

شكرا على نصيحة mtextFontInherit. كنت سأقوم بتمكين ذلك على أي حال ، ولكن هذا سبب آخر للقيام بذلك.

تمت إضافة بعض الدعم لـ RTL في الإصدار 2.3 ، ولكن تظل مشكلة التسلسلات متعددة الأحرف التي يتم التعامل معها كوحدة. بالنسبة إلى \text{} ، يجب أن يتم تجميع هذه الأحرف بالفعل في <span> ، لذلك ستكون إحدى الطرق للتعامل معها ، على الرغم من أنها ليست مريحة للغاية.

من الناحية المثالية ، ستضع MathJax كل تسلسل يشكل مجموعة واحدة في <mi> أو <mo> ، تمامًا كما هو الحال مع الأحرف اللاتينية المفردة الآن. لقد بحثت في هذا إلى حد ما ، وهناك بعض الصعوبات في التعامل معه. من الممكن الجمع بين الأحرف المجمعة مع الأحرف السابقة ، ولكن ليس من الواضح بالنسبة لي كيفية عمل بعض الشخصيات. على سبيل المثال ، يبدو أن virama (U + 0D4D) لا تجمع فقط بين الشخصية الموجودة على يساره ، ولكن أيضًا على اليمين ، على الرغم من أنني قد أكون قد أسيء فهمها. يبدو أيضًا أن بعض هذه المجموعات يتم التعامل معها بواسطة أحرف مركبة داخل الخطوط ، وليس بدمج الأحرف. لسوء الحظ ، لا يستطيع MathJax الوصول إلى معلومات ربط الأحرف من الخطوط. في حين أنه سيكون من الممكن إضافة بيانات ربط إلى جداول خطوط MathJax ، فقد يكون هذا قدرًا كبيرًا من البيانات التي سيتم استخدام القليل جدًا منها بواسطة أي صفحة واحدة.

لست على دراية كافية باللغات التي تستخدم هذه الميزات لمعرفة ما إذا كان ما أحاول تجربته سيكون كافيًا أم لا. أتساءل عما إذا كان من الممكن الحصول على بعض الأمثلة من مجموعة متنوعة من اللغات التي تعرض مجموعة من المواقف التي يجب استيعابها.

قد تتمثل إحدى الطرق في وضع البيانات اللازمة لكل نص برمجي لكل لغة في ملحق فردي يتم تحميله لتلك الصفحات التي تحتاجها (إما بشكل صريح في تكوين MathJax ، أو عبر \require{} داخل الرياضيات على الصفحة). هل تعتقد أن هذا سيكون مقبولا؟

ربما يكون @ amire80 من هندسة اللغة الخاصة بنا في WMF قادرًا على المساعدة قليلاً هنا ...

hartman هل تعتقد أنك يمكن أن تكز @ amire80 بعض الوقت؟ نود تحسين ذلك ، خاصةً إذا كانت ويكيبيديا تريد طرح إخراج SVG على نطاق أوسع.

أنا هنا :)

كيف يمكنني أن أقدم المساعدة؟

اختبارات؟ - بكل سرور ، فقط اتصل بي ماذا أختبر بالضبط.

أمثلة على كيفية عمل النصوص غير اللاتينية في الصيغ؟ - لا تستخدم في الكتب المدرسية العبرية ، لكنها تستخدم في الكتب المدرسية باللغتين العربية والفارسية. ربما يمكن أن تتناغم معebraminio هنا.

هل من شيء آخر؟

شكرا لزيارتكم @ amire80 :-)

كيف يمكنني أن أقدم المساعدة؟

آمل أن نتمكن من تحسين التعامل مع الأحرف المدمجة في النصوص غير اللاتينية. لقد ظهر هذا على WMF bugzilla / phabricator بشكل متكرر. لاقتباس دافيد من https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717:

من الناحية المثالية ، يضع MathJax كل تسلسل يشكل مجموعة واحدة في مجموعة واحدةأو، تمامًا كما هو الحال مع الأحرف اللاتينية المفردة الآن. لقد بحثت في هذا إلى حد ما ، وهناك بعض الصعوبات في التعامل معه. من الممكن الجمع بين الأحرف المجمعة مع الأحرف السابقة ، ولكن ليس من الواضح بالنسبة لي كيفية عمل بعض الشخصيات. على سبيل المثال ، يبدو أن virama (U + 0D4D) لا تجمع فقط بين الشخصية الموجودة على يساره ، ولكن أيضًا على اليمين ، على الرغم من أنني قد أكون قد أسيء فهمها. يبدو أيضًا أن بعض هذه المجموعات يتم التعامل معها بواسطة أحرف مركبة داخل الخطوط ، وليس بدمج الأحرف. لسوء الحظ ، لا يستطيع MathJax الوصول إلى معلومات ربط الأحرف من الخطوط. في حين أنه سيكون من الممكن إضافة بيانات ربط إلى جداول خطوط MathJax ، فقد يكون هذا قدرًا كبيرًا من البيانات التي سيتم استخدام القليل جدًا منها بواسطة أي صفحة واحدة.

لست على دراية كافية باللغات التي تستخدم هذه الميزات لمعرفة ما إذا كان ما أحاول تجربته سيكون كافيًا أم لا. أتساءل عما إذا كان من الممكن الحصول على بعض الأمثلة من مجموعة متنوعة من اللغات التي تعرض مجموعة من المواقف التي يجب استيعابها.

لذا فإن سؤالنا سيكون: هل لدى أي شخص خبرة يمكنه مشاركتها معنا؟ hartman كان لطيفًا بما يكفي للإشارة إليك ؛-)

(ربما يتعين علينا تقسيم هذا إلى قضية منفصلة).

الفكرة الأساسية (جدًا) لـ virama هي أن تسلسل الحرف الساكن + virama + يحتوي على ثلاثة أحرف Unicode ، والتي تظهر على أنها تشغل مساحة حرف رسومي واحد (ولكن يمكن أن يصبح أكثر تعقيدًا).

بشكل عام ، أود أن أفهم الوضع الحالي لماثجاكس. ماذا علي أن أفعل لاختبار العرض الحالي؟ تثبيت المثيل الخاص بي؟ أو هل هناك مثيل على الإنترنت حيث يمكن اختبار الإصدار الحالي؟

يحتوي الحرف الساكن + virama + الساكن على ثلاثة أحرف Unicode ، والتي تظهر على أنها تشغل مساحة حرف رسومي واحد

حق. الأحرف المجمعة شائعة بدرجة كافية في التخطيط الرياضي لذلك نحن نفهم الموقف بشكل عام.

(ولكن يمكن أن يصبح الأمر أكثر تعقيدًا).

هذه مشكلتنا. نحن نفتقر إلى التفاصيل الخاصة لمعظم اللغات الطبيعية ، والنصوص غير اللاتينية.

أو هل هناك مثيل على الإنترنت حيث يمكن اختبار الإصدار الحالي؟

يمكنك القيام بذلك على ميدياويكي (باستخدام وضع 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>

والذي سينقسم بدوره ناتج MathJax عبر ثلاثة امتدادات (في مخرجات HTML) أو ثلاثة g (في إخراج SVG) - وبالطبع هذا يكسر عرض الحرف المدمج.

(لقد لاحظت للتو أن Firefox يجمع أحيانًا الامتدادات في مخرجات HTML على سبيل المثال ، ത്ര لكن ليس الرمز المنخفض في കു_ശ . Chrome أكثر "تناسقًا" حيث لا يتم دمج أي شيء)

لذا فإن المشكلة بالنسبة لنا هي: هل هناك مجموعة موجزة من البيانات (أو بعض الإرشادات الفعالة) التي يمكننا استخدامها لتحديد جميع المواقف ذات الصلة حيث نحتاج إلى إعادة الدمج في عنصر ميل / مو واحد في MathML؟ بمجرد أن نحصل على ذلك ، سيعمل العرض أيضًا.

لذا فإن المشكلة بالنسبة لنا هي: هل هناك مجموعة موجزة من البيانات (أو بعض الإرشادات الفعالة) التي يمكننا استخدامها لتحديد جميع المواقف ذات الصلة حيث نحتاج إلى إعادة الدمج في عنصر ميل / مو واحد في MathML؟

نأسف للتعليق الطويل ، مع إعادة القليل من المناقشة خارج الموقع إلى أداة تعقب المشكلة.

ما مدى جدوى / تكلفة إنشاء قاعدة بيانات Unicode UCD
الجمع بين الطبقة المتاحة لماثجاكس لكل شخصية؟ في الأساس (أو
على الأقل كتقريب أولي جيد) أي حرف بغير الصفر
يجب أن يظل دمج الفئة (الحقل 4 في UnicodeData.txt) مع ملحق
التي تسبقها ، بالإضافة إلى أنها إذا كانت من الدرجة 9 (فيراما) ما يلي
الشخصية يجب أن تبقى معًا أيضًا.

من المحتمل أيضًا أن نلاحظ أن tex ، حتى tex unicode مثل xetex
أو luatex يكاد يكون من المؤكد أنه لن يحصل على هذا الحق بدونه
وضع علامة على
هذا هو ما ستحتاجه \ text {abc} أو \ mathit {abc} أو شيء آخر من هذا القبيل
أمر لفرض سلسلة من الأحرف ليتم طباعتها كنص بامتداد
خط واحد بدلاً من عادة TeX العادية لتقسيم الأشياء
حرف بحرف. حتى لو كانت البنية تبدو وكأنها واحدة
شخصية للمؤلف.

في النص الكلاسيكي ، لا يمثل ذلك مشكلة حيث يمكن أن تحتوي الخطوط على 256 حرفًا فقط
وبينما يمكن دعم الأحرف المكونة بمختلف حيل إعادة تعيين الماكرو
لا يمكن دعم الأحرف المكونة التي تتبع القاعدة بشكل أساسي حتى لو كانت بسيطة
تأليف لهجات مثل الحادة.

يبدو الدعم في متغيرات unicode tex مثل xetex و luatex متغيرًا بعض الشيء. في النص ، xetex
يسلم الأشياء إلى مكتبة HarfBuzz وكذلك بشكل جيد. يعالجها luatex داخليًا ويعمل حاليًا بشكل أقل جودة مع virama. في الرياضيات ، يتطلب كلاهما خطًا به جدول رياضيات من نوع opentype للقيام بأي شيء مفيد للغاية ولم أتمكن من العثور على مثل هذا الخط الذي يحتوي على virama.

مستند اللاتكس التالي يستخدم kartika في النص والرياضيات اللاتينية الحديثة في الرياضيات ، ستلاحظ ذلك
حتى اللكنات الأوروبية تفشل عادةً في الرياضيات ، ولكن حتى مثال virama يعمل إذا أضفت بعض العلامات \mbox هنا أو mi أو mtext بشكل مكافئ في MathML

تُظهر الصورة xetex في الأعلى و luatex في الأسفل.

لذلك ، في حين أن عدم طلب شيء مثل \ text {..} أو \ mbox {...} حول سلاسل الأحرف هذه سيكون أمرًا مرغوبًا فيه ، فإنه سيضع دعم Unicode الخاص بك بعيدًا عن ما يمكن أن تحققه TeX حاليًا
لذا فإن الأمر يعتمد قليلاً على ماهية مواصفات "بناء الجملة الشبيه بـ tex" ، إلى أي مدى أبعد مما يمكن أن تفعله TeX هو من المعقول دفعه؟

\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}

لست متأكدًا حقًا مما إذا كنت أفهم ما تدور حوله المناقشة ، ولكن إذا كانت الفكرة هي تحديد تسلسل الأحرف الذي يشكل وحدة واحدة ، فيجب أن توفر مجموعة حروف حروف Unicode المعلومات المطلوبة ..

نعم - ما يقوله khaledhosny يبدو وكأنه الشيء الصحيح بالنسبة لي ، رغم أنني لست من ذوي الخبرة به. ربما يمكن أن يساهم santhoshtr في مزيد من التفاصيل.

سانثوش ، أعتقد أن ما كتبه pkra عن ثلاثة تعليقات أعلاه يفسر المشكلة بشكل أفضل.

في 3 مارس 2015 الساعة 12:05 ، كتب خالد حسني [email protected] :

لست متأكدًا حقًا مما إذا كنت أفهم ما تدور حوله المناقشة ، ولكن إذا
الفكرة هي تحديد أي تسلسل من الشخصيات يشكل واحدًا
وحدة ، ثم Unicode Grapheme العنقودية
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries يجب أن يكون
توفير المعلومات المطلوبة ..

نعم ، لكنني أفترض أن السؤال هو إلى أي مدى يكون منطقيًا بالنسبة لجافا سكريبت
مكتبة للقيام بذلك
يدويًا إذا كان النظام الأساسي الأساسي لا يصنع خصائص unicode
متوفرة
وإذا كان يحاكي بناء جملة tex ، فإلى أي مدى ستذهب tex؟ أنت تعرف الكثير
حول دعم tex مثل أي شخص. إلى أي مدى سيكون من المعقول في xetex أن
لديك مثل هذه المجموعة تفعل أي شيء معقول في _math_ دون الهروب إلى النص
باستخدام \text{..} أو أمر ما من هذا القبيل ، نظرًا لأنه لا يمكنك تعيين ملف
\ mathclass لمثل هذه الكتلة؟

لقد وجدت تطبيق CoffeeScript لأشكال حروف الكتابة.
https://github.com/devongovett/grapheme-breaker

من الممكن ان يكون مفيدا.

شكرا لجميع التعليقات المفيدة. كي تختصر،

• لا تتعامل xetex / luatex مع الإدخال بالطريقة المطلوبة في هذه المشكلة ، أي بدون ترميز إضافي مثل \text
• ليس من الواضح (بالنسبة لي على الأقل) ما إذا كانت هناك خطط للتعامل مع الأمر بهذه الطريقة
• يمكن أن يبدأ الحل بالنهج البسيط الذي حدده David C أو يحتمل أن يبني على grapheme-breaker (شكرًاhartman!)

للإضافة إلى ذلك ،

• من ناحية أخرى ، يشير الاختبار السريع باستخدام LaTeXML و pandoc إلى أنهم يتعاملون مع مثل هذه الأحرف كما هو مطلوب هنا ، على سبيل المثال ، ليس مثل xetex / luatex.

لذلك يبدو لي أن الحل لا يمكن أن يكون في جوهر مدخلات TeX ولكن يجب أن يكون امتدادًا. هذه ليست مشكلة ، بالطبع ، لأنه من المحتمل أن ينتهي الأمر بالتمديد على أي حال.

سيكون من الجيد أن نسمع من مجتمعات MediaWiki / WMF إذا كانوا يريدون بالفعل تحديد من محركات TeX هنا.

مرة أخرى سيكون من الجيد الحصول على مزيد من ردود الفعل.

• في TeX folks ، هل التعامل مع الأحرف في وضع الرياضيات بدون ترميز إضافي هو الاتجاه المستقبلي لـ xetex / luatex / إلخ؟
• في MediaWiki / WMF: هل سلوك TeX غير القياسي مرغوب فيه فعلاً من قبل المجتمعات ذات الصلة؟

بدون مزيد من التعليقات ، أعتقد أنه يجب علينا أن نلاحق هذا / نخرجه من المرحلة 2.6.

دعني أفهم المشكلة هنا ، يريد الأشخاص القيام بأشياء مثل $x+y=<complex character>$ حيث من المحتمل أن يكون <complex character> حرفًا متعدد النقاط ، ويتم التعامل مع <complex character> كمعرف رياضي ، صحيح ؟ إذا كان الأمر كذلك ، فأعتقد أن هذا توقع معقول وإذا كانت محركات Unicode TeX الحالية لا تتعامل معه بشكل صحيح (ربما لا يفعلون ذلك) فمن المحتمل أن يكون خطأ أو ميزة مفقودة ، وليس شيئًا حسب التصميم.

أم أن الأشخاص يريدون القيام بأشياء مثل $<complex text string>$ ، حيث <complex text string> عبارة عن سلسلة نصية متعددة الأحرف ربما تحتاج إلى تخطيط نص معقد ، والحصول على تخطيط نص مناسب (ثنائي الاتجاه ، تشكيل ، إلخ.) ؟ لا أعتقد أن هذا توقع معقول وهناك حاجة إلى نوع من الترميز هنا للإشارة إلى أن هذه سلسلة نصية عادية يجب التعامل معها على هذا النحو.

شكرا @ khaledhosny!

[...] الناس يريدون القيام بأشياء مثل $ x + y =$ أينمن المحتمل أن يكون حرفًا متعدد النقاط ، ويكونتعامل كمعرف رياضيات ، أليس كذلك؟

نعم ، هكذا أفهمها أيضًا. (من الصعب تحديد ذلك لأن هذا في الأصل طلب من نهاية ويكيبيديا).

أعتقد أن هذا توقع معقول

شكرا!

إذا كانت محركات Unicode TeX الحالية لا تتعامل معها بشكل صحيح (من المحتمل أنها لا تفعل ذلك) فمن المحتمل أن يكون خطأ أو ميزة مفقودة ، وليس شيئًا حسب التصميم.

شكرا على ذلك ايضا جزء "ربما لا" يقلقني قليلاً ولكن إذا وافقت أنت و @ davidcarlisle على أن هذا هو السلوك المرغوب في محركات Unicode TeX ، فهذا يكفي بالنسبة لنا ، على ما أعتقد.

ما زلت آمل أن يتناغم جانب MediaWiki / WMF / Wikipedia.

وفقًا لـ F2F ، سنزيل هذا من الإصدار 2.6 من Milestone (أي الإصدار القادم).

ليس من الواضح ما هو النهج الصحيح ، على وجه الخصوص ، من حيث التوافق مع TeX / LaTeX (أو بالأحرى XeTeX / LuaTeX). كما أنه ليس من الواضح ما الذي تريده مؤسسة ويكيميديا ​​ومجتمع ويكيبيديا هنا حقًا.

للتوضيح ، نحن لا نغلق هذه المشكلة وما زلنا مهتمين بمعرفة كيفية عمل التخطيط المعقد في مدخلات TeX.

انفجار من المستقبل: هناك اقتراح TC39 "تجزئة Unicode" للسماح (من بين أشياء أخرى) بتقسيم السلاسل بواسطة حروف الكتابة https://github.com/tc39/proposal-intl-segmenter. يتضمن المستودع رابطًا إلى ملف متعدد التعبئة (وهناك أيضًا مظهر كروم غير قياسي على ما يبدو).

بارد. شكرا ، pkra.

لا مشكلة. إن polyfill للأسف عديم الفائدة - فهو يغطي Enligsh فقط. ولكن بالنسبة لأولئك الذين يرغبون في تجربته ، قد يكون استخدام الكروم مفيدًا.