Mathjax: 複雑なテキストレイアウト、特にTeX入力を使用[以前：MathJaxは複雑なテキストレイアウトをサポートしていません。]

構成のHTML-CSS ＃$セクションとSVGセクションでmtextFontInheritをtrueに設定すると、MathJaxは\text{}を単一の<span>であるため、要求どおりに実行できます。 mtextFontInheritがfalseの場合、MathJaxの方がうまくいく可能性があります。 「不明な」文字を個別の<span>に入れるのではなく、1つのコレクションにグループ化する必要があります。

PS、私はウィキメディアのバグジラに関するレポートを見て、修正するもののリストにそれを追加することを計画していました。 それを追跡するためにここで問題を見つめてくれてありがとう。

mtextFontInheritのヒントをありがとう。 とにかくそれを有効にするつもりでしたが、これがそれを行うもう1つの理由です。

v2.3ではRTLのサポートがいくつか追加されましたが、複数文字のシーケンスが1つの単位として扱われるという問題は残っています。 \text{}の場合、これらの文字はすでに1つの<span>にグループ化されている必要があります。これは、あまり便利ではありませんが、それを処理する1つの方法です。

理想的には、MathJaxは、現在の単一のラテン文字の場合と同様に、1つのグループを形成する各シーケンスを単一の<mi>または<mo>に配置します。 私はこれをある程度調べましたが、それを処理するのにいくつかの困難があります。 結合文字を前の文字とグループ化することは可能ですが、一部の文字がどのように機能するかは私にはわかりません。 たとえば、ヴィラーマ（U + 0D4D）は、誤解されているかもしれませんが、左側のキャラクターだけでなく、右側のキャラクターも組み合わせているようです。 また、これらのグループ化の一部は、文字の組み合わせではなく、フォント内の合字によって処理されるようです。 残念ながら、MathJaxはフォントからの合字情報にアクセスできません。 合字データをMathJaxのフォントテーブルに追加することは可能ですが、これはかなりの量のデータであり、1ページで使用されるデータはごくわずかです。

私は、これらの機能を使用して、試していることが十分かどうかを知るための言語に精通していません。 さまざまな言語から、対応する必要のあるさまざまな状況を示すいくつかの例を取得できるかどうか疑問に思っています。

1つのアプローチは、各言語のスクリプトに必要なデータを、それを必要とするページにロードされる個々の拡張機能に配置することです（MathJax構成で明示的に、またはページの数学内の\require{}を介して）。 それは受け入れられると思いますか？

おそらく、私たちのWMF言語エンジニアリングの@ amire80は、ここで少し役立つことができます...

@hartmanいつか@ amire80を突くことができると思いますか？ 特にウィキペディアがSVG出力をより広く展開したい場合は、これを改善したいと思います。

ここにいるよ ：）

手伝いましょうか？

テスト？ -喜んで、正確に何をテストするか教えてください。

非ラテン文字が数式でどのように機能するかの例？ -ヘブライ語の教科書では使用されていませんが、アラビア語とペルシア語の教科書では使用されています。 たぶん@ebraminioはここでチャイムを鳴らすことができます。

他に何か？

@ amire80に立ち寄ってくれてありがとう:-)

手伝いましょうか？

非ラテン文字の結合文字の処理を改善できることを願っています。 これは、WMFのbugzilla / phabricatorで繰り返し発生しています。 https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717からDavideを引用するには：

理想的には、MathJaxは1つのグループを形成する各シーケンスを1つにまとめますまた、現在の単一ラテン文字の場合と同じように。 私はこれをある程度調べましたが、それを処理するのにいくつかの困難があります。 結合文字を前の文字とグループ化することは可能ですが、一部の文字がどのように機能するかは私にはわかりません。 たとえば、ヴィラーマ（U + 0D4D）は、誤解されているかもしれませんが、左側のキャラクターだけでなく、右側のキャラクターも組み合わせているようです。 また、これらのグループ化の一部は、文字の組み合わせではなく、フォント内の合字によって処理されるようです。 残念ながら、MathJaxはフォントからの合字情報にアクセスできません。 合字データをMathJaxのフォントテーブルに追加することは可能ですが、これはかなりの量のデータであり、1ページで使用されるデータはごくわずかです。

私は、これらの機能を使用して、試していることが十分かどうかを知るための言語に精通していません。 さまざまな言語から、対応する必要のあるさまざまな状況を示すいくつかの例を取得できるかどうか疑問に思っています。

したがって、私たちの質問は次のようになります。誰かが私たちと共有できる専門知識を持っていますか？ @hartmanは親切にもあなたを指さしてくれました;-)

（おそらく、これを別の問題に分割する必要があります。）

ヴィラーマの（非常に）基本的な考え方は、子音+ヴィラーマ+子音のシーケンスには、1つのグリフのスペースを占めるように見える3つのUnicode文字があるということです（ただし、はるかに複雑になる可能性があります）。

より一般的には、MathJaxの現在の状況を理解したいと思います。 現在のレンダリングをテストするにはどうすればよいですか？ 自分のインスタンスをインストールしますか？ または、現在のバージョンをテストできるオンラインインスタンスはありますか？

子音+ヴィラーマ+子音には3つのUnicode文字があり、1つのグリフのスペースを占めるように見えます

右。 結合文字は数学的なレイアウトでは十分に一般的であるため、一般的な状況を理解しています。

（ただし、はるかに複雑になる可能性があります）。

それが私たちの問題です。 ほとんどの自然言語、非ラテン文字の詳細が欠けています。

または、現在のバージョンをテストできるオンラインインスタンスはありますか？

これは、MediaWiki（math拡張機能のMathML / SVGモードを使用）、ブラウザー（このサンプルまたはこのcodepen ）、または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出力が3つのスパン（HTML出力の場合）または3つのg（SVG出力の場合）に分割されます。もちろん、これにより、結合された文字のレンダリングが中断されます。

（FirefoxがHTML出力のスパンを結合することがあることに気づきました。たとえばത്രですが、 കു_ശの添え字は結合しません。Chromeは、何も結合されないという点でより「一貫性」があります）

したがって、私たちにとっての問題は、MathMLで1つのmi / mo要素に再結合する必要があるすべての関連する状況を識別するために使用できる簡潔なデータセット（またはいくつかの効率的なヒューリスティック）がありますか？ それができたら、レンダリングも機能します。

したがって、私たちにとっての問題は次のとおりです。MathMLで1つのmi / mo要素に再結合する必要があるすべての関連する状況を特定するために使用できる簡潔なデータセット（またはいくつかの効率的なヒューリスティック）はありますか？

長いコメントをお詫び申し上げます。少しオフサイトのディスカッションを課題追跡システムに戻します。

UnicodeUCDデータベースを作成することはどれほど実行可能/高価でしょうか
各キャラクターのmathjaxで利用可能なクラスを組み合わせますか？ 基本的に（または
少なくとも良い最初の近似として）ゼロ以外の文字
結合クラス（UnicodeData.txtのフィールド4）は、
前のもの、さらにクラス9（ヴィラーマ）の場合は次の
キャラクターも一緒に保つ必要があります。

xetexのようなユニコードtexでさえ、そのtexにも注目する価値があるでしょう。
またはluatexはほぼ確実にこれを正しく行うことはできません
マークアップ
つまり、\ text {abc}または\ mathit {abc}またはその他のそのようなものが必要になります
文字列をテキストとしてタイプセットするように強制するコマンド
TeXの通常の分割の習慣ではなく単一のフォント
文字ごと。 コンストラクトが単一のように見える場合でも
作者へのキャラクター。

従来のtexでは、フォントは256文字しか使用できないため、問題にはなりません。
構成された文字は、さまざまなマクロ再マッピングのトリックでサポートできます。
ベースに続く文字の作成は、基本的に単純な場合でもサポートされません
鋭いようなアクセントを構成します。

xetexやluatexなどのUnicodetexバリアントでのサポートは少し可変のようです。 テキストでは、xetex
HarfBuzzライブラリに物事を渡すので、かなりうまくいきます。 luatexはそれを内部で処理し、現在、ビラマではうまく機能しません。 数学では、どちらも非常に便利なことを行うためにOpenType MATHテーブルを備えたフォントが必要であり、ヴィラーマを備えたそのようなフォントは見つかりませんでした。

次のラテックスドキュメントは、テキストでkartikaを使用し、数学でlatin modernmathを使用しています。
ヨーロッパのアクセントでさえ、通常、数学では失敗しますが、ここにマークアップ\mboxを追加するか、MathMLで同等にmiまたはmtextを追加すると、ヴィラーマの例でも機能します。

画像は上部にxetex、下部にluatexを示しています。

したがって、そのような文字列の周りに\ text {..}や\ mbox {...}のようなものを必要としないことは望ましいことですが、それはあなたのユニコードサポートを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はより多くの詳細を提供することができます。

Santhosh、 @ pkraが上記の3つのコメントを書いたことは、問題を最もよく説明していると思います。

2015年3月3日12：05、 KhaledHosnynotifications @ github.comは次のように書いています。

議論が何であるかを理解しているかどうかはよくわかりませんが、
アイデアは、文字のどのシーケンスが単一を構成するかを識別することです
ユニット、次にUnicode書記素クラスタリング
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries should
必要な情報を提供します。

はい、しかし問題は、JavaScriptにとってどれだけ意味があるかということだと思います
それを行うためのライブラリ
基盤となるプラットフォームがUnicodeプロパティを作成しない場合は手動で
利用可能
そして、それがtex構文をエミュレートしている場合、texはどこまで行くのでしょうか？ あなたは多くを知っています
誰としてもtexサポートについて。 xetexでどれだけ合理的であるか
そのようなクラスターに、テキストにエスケープせずに_math_で賢明なことを何でもしてもらいます
\text{..}またはそのようなコマンドを使用して、
そのようなクラスターへの\ mathclass？

書記素のCoffeeScript実装を見つけました。
https://github.com/devongovett/grapheme-breaker

役に立つかもしれません。

有益なコメントをありがとう。 要約する、

• xetex / luatexは、この問題で要求された方法で入力を処理しません。つまり、 \textなどの追加のマークアップがありません。
• このように処理する計画があるかどうかは（少なくとも私には）明確ではありません
• 解決策は、David Cが概説した単純なアプローチから始めるか、書記素ブレーカーに基づいて構築する可能性があります（@hartmanに感謝します！）

それに加えて、

• 一方、LaTeXMLとpandocを使用した簡単なテストでは、ここで要求されているような文字、つまりxetex / luatexとは異なる文字を処理することが示されています。

したがって、ソリューションをコアTeX入力に含めることはできませんが、拡張機能である必要があるように思われます。 もちろん、それは問題ではありません。とにかく拡張機能になってしまう可能性があるからです。

ここでTeXエンジンから実際に描写したい場合は、MediaWiki / WMFコミュニティから話を聞くとよいでしょう。

繰り返しになりますが、より多くのフィードバックを得るのは良いことです。

• TeXの人々では、余分なマークアップなしで数学モードで文字を処理していますか？xetex / luatex / etcの将来の方向性ですか？
• MediaWiki / WMFの人々：非標準のTeXの振る舞いは、関連するコミュニティによって実際に望まれていますか？

これ以上のフィードバックがなければ、これをパントするか、2.6マイルストーンから外す必要があると思います。

ここで問題を理解させてください。人々は$x+y=<complex character>$のようなことをしたいと思っています。ここで、 <complex character>はおそらくマルチコードの書記素であり、 <complex character>は数学の識別子として扱われます。 ？ もしそうなら、それは合理的な期待であり、現在のUnicode TeXエンジンがそれを正しく処理しない場合（おそらくそうではない）、それはバグまたは機能の欠如であり、設計によるものではない可能性があります。

それとも、 $<complex text string>$のようなことをしたいのでしょうか。ここで、 <complex text string>は、複雑なテキストレイアウトを必要とする可能性のある複数文字のテキスト文字列であり、適切なテキストレイアウト（ビディ、シェーピングなど）を取得します。 ？ これは合理的な期待ではないと思います。これが通常のテキスト文字列であり、そのように扱う必要があることを示すために、ここで何らかのマークアップが必要です。

ありがとう、@ khaledhosny！

[...]人々は$ x + y =のようなことをしたい$ここでおそらくマルチコードの書記素であり、数学の識別子として扱われますよね？

はい、それは私もそれを理解する方法です。 （これはもともとウィキペディアの終わりからの要求であるため、言うのは少し難しいです）。

それは合理的な期待だと思います

ありがとう！

現在のUnicodeTeXエンジンが正しく処理しない場合（おそらく処理しない場合）、バグまたは機能の欠落である可能性があり、設計によるものではありません。

それもありがとう。 「おそらくそうではない」部分は私を少し心配しますが、あなたと@davidcarlisleがそれがUnicode TeXエンジンで望ましい動作であることに同意するなら、それで十分だと思います。

まだMediaWiki / WMF / Wikipedia側がチャイムを鳴らすことを望んでいます。

F2Fに従って、これをv2.6マイルストーン（つまり、次のリリース）から削除します。

特に、TeX / LaTeX（またはXeTeX / LuaTeX）との互換性の観点から、正しいアプローチが何であるかは明確ではありません。 また、WMFとウィキペディアコミュニティがここで本当に何を望んでいるのかも明確ではありません。

明確にするために、この問題を解決するわけではなく、TeX入力で複雑なレイアウトがどのように機能するかを理解することに引き続き関心があります。

未来からの爆発:(とりわけ）書記素https://github.com/tc39/proposal-intl-segmenterによって文字列を分割できるようにするTC39提案「Unicodeセグメンテーション」があります。 リポジトリにはポリフィルへのリンクが含まれています（また、明らかに非標準のChrome機能もあります）。

いいね。 ありがとう、@ pkra。

問題ない。 ポリフィルは残念ながら役に立たない-それはEnligshだけをカバーしている。 しかし、それを試してみたい人にとっては、chromeビルトインが役立つかもしれません。