Mathjax: Komplexes Textlayout, insbesondere mit TeX-Eingabe [war: MathJax unterstützt kein komplexes Textlayout.]

Beachten Sie, dass wenn Sie in den Abschnitten HTML-CSS und SVG Ihrer Konfiguration mtextFontInherit auf true setzen, MathJax \text{} als Single <span> , und das sollte tun, was Sie verlangen. Sie haben recht, dass MathJax es besser machen könnte, wenn mtextFontInherit gleich false ist. Es sollte "unbekannte" Zeichen in einer einzigen Sammlung gruppieren, anstatt jedes in ein separates <span> zu packen.

PS, ich habe den Bericht über den Wikimedia-Bugzilla gesehen und hatte vor, ihn der Liste der zu behebenden Dinge hinzuzufügen. Danke, dass Sie das Problem hier angestarrt haben, um das zu verfolgen.

Danke für den mtextFontInherit-Tipp. Ich wollte das sowieso aktivieren, aber das ist ein Grund mehr, das zu tun.

Etwas Unterstützung für RTL wurde in v2.3 hinzugefügt, aber das Problem, dass Sequenzen aus mehreren Zeichen als Einheit behandelt werden, bleibt bestehen. Für \text{} sollten diese Zeichen bereits in einem einzigen <span> gruppiert sein, so dass dies eine Möglichkeit wäre, damit umzugehen, wenn auch nicht sehr bequem.

Im Idealfall würde MathJax jede Sequenz, die eine Gruppe bildet, in ein einzelnes <mi> oder <mo> setzen, genau wie es jetzt für einzelne lateinische Buchstaben der Fall ist. Ich habe mich bis zu einem gewissen Grad damit befasst, und es gibt einige Schwierigkeiten, damit umzugehen. Es ist möglich, Kombinationszeichen mit ihren vorhergehenden Zeichen zu gruppieren, aber mir ist nicht klar, wie einige Zeichen funktionieren. Zum Beispiel scheint das Virama (U + 0D4D) nicht nur das Zeichen auf der linken Seite, sondern auch auf der rechten Seite zu kombinieren, obwohl ich es möglicherweise missverstehe. Es scheint auch, dass einige dieser Gruppierungen durch Ligaturen innerhalb der Schriftarten gehandhabt werden, nicht durch Kombinieren von Zeichen. Leider hat MathJax keinen Zugriff auf Ligaturinformationen aus den Schriftarten. Während es möglich wäre, Ligaturdaten zu den Schriftarttabellen von MathJax hinzuzufügen, könnte dies eine beträchtliche Datenmenge sein, von der nur sehr wenige von einer Seite verwendet würden.

Ich bin wirklich nicht vertraut genug mit den Sprachen, die diese Funktionen verwenden, um zu wissen, ob das, was ich ausprobiere, ausreichen würde oder nicht. Ich frage mich, ob es möglich ist, einige Beispiele aus einer Vielzahl von Sprachen zu erhalten, die die Bandbreite der Situationen zeigen, die berücksichtigt werden müssen.

Ein Ansatz könnte darin bestehen, die für das Skript jeder Sprache erforderlichen Daten in eine individuelle Erweiterung zu packen, die für die Seiten geladen wird, die sie benötigen (entweder explizit in der MathJax-Konfiguration oder über \require{} innerhalb der Mathematik auf der Seite). Meint ihr das wäre akzeptabel?

Vielleicht kann @amire80 von unserem WMF Language Engineering hier ein wenig aushelfen...

@hartman denkst du, du könntest mal @amire80 anstupsen ? Wir würden dies gerne verbessern, insbesondere wenn Wikipedia die SVG-Ausgabe breiter ausrollen möchte.

Ich bin genau hier :)

Wie kann ich helfen?

Testen? - Sagen Sie mir gerne, was genau getestet werden soll.

Beispiele dafür, wie nicht-lateinische Schriften in Formeln funktionieren? - Es wird nicht in hebräischen Lehrbüchern verwendet, aber es wird in Lehrbüchern auf Arabisch und Persisch verwendet. Vielleicht kann sich @ebraminio hier einschalten.

Noch etwas?

Danke, dass du bei @amire80 vorbeischaust :-)

Wie kann ich helfen?

Ich hoffe, dass wir den Umgang mit kombinierten Zeichen in nicht-lateinischen Schriften verbessern können. Dies ist wiederholt auf WMF bugzilla/phabricator aufgetaucht. Um Davide aus https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717 zu zitieren:

Im Idealfall würde MathJax jede Sequenz, die eine Gruppe bildet, in eine einzelne einfügenoder, genau wie jetzt für einzelne lateinische Buchstaben. Ich habe mich bis zu einem gewissen Grad damit befasst, und es gibt einige Schwierigkeiten, damit umzugehen. Es ist möglich, Kombinationszeichen mit ihren vorhergehenden Zeichen zu gruppieren, aber mir ist nicht klar, wie einige Zeichen funktionieren. Zum Beispiel scheint das Virama (U + 0D4D) nicht nur das Zeichen auf der linken Seite, sondern auch auf der rechten Seite zu kombinieren, obwohl ich es möglicherweise missverstehe. Es scheint auch, dass einige dieser Gruppierungen durch Ligaturen innerhalb der Schriftarten gehandhabt werden, nicht durch Kombinieren von Zeichen. Leider hat MathJax keinen Zugriff auf Ligaturinformationen aus den Schriftarten. Während es möglich wäre, Ligaturdaten zu den Schriftarttabellen von MathJax hinzuzufügen, könnte dies eine beträchtliche Datenmenge sein, von der nur sehr wenige von einer Seite verwendet würden.

Ich bin wirklich nicht vertraut genug mit den Sprachen, die diese Funktionen verwenden, um zu wissen, ob das, was ich ausprobiere, ausreichen würde oder nicht. Ich frage mich, ob es möglich ist, einige Beispiele aus einer Vielzahl von Sprachen zu erhalten, die die Bandbreite der Situationen zeigen, die berücksichtigt werden müssen.

Unsere Frage wäre also: Hat jemand Fachwissen, das er mit uns teilen kann? @hartman war so freundlich, auf dich zu zeigen ;-)

(Vielleicht sollten wir dies in einer separaten Ausgabe aufteilen.)

Die (sehr) grundlegende Idee von virama ist, dass die Folge von Konsonant + virama + Konsonant drei Unicode-Zeichen hat, die den Platz einer Glyphe einnehmen (aber es kann viel komplizierter werden).

Generell würde ich gerne die aktuelle Situation von MathJax verstehen. Was soll ich tun, um das aktuelle Rendering zu testen? Meine eigene Instanz installieren? Oder gibt es eine Online-Instanz, wo eine aktuelle Version getestet werden kann?

Konsonant + Virama + Konsonant hat drei Unicode-Zeichen, die den Platz einer Glyphe einnehmen

Rechts. Kombinierte Zeichen sind im mathematischen Layout häufig genug, sodass wir die Situation im Allgemeinen verstehen.

(aber es kann viel komplizierter werden).

Das ist unser Problem. Uns fehlen die Besonderheiten für die meisten natürlichsprachlichen, nicht-lateinischen Schriften.

Oder gibt es eine Online-Instanz, wo eine aktuelle Version getestet werden kann?

Sie können dies auf MediaWiki (unter Verwendung des MathML/SVG-Modus der Math-Erweiterung), im Browser ( dieses Beispiel oder diesen Codepen ) tun oder eine lokale Kopie von MathJax verwenden – je nachdem, was Sie möchten.

Ein einfaches Beispiel: ത്ര wird in ത്ര konvertiert und da wir keine Routinen haben, um diese Art von kombinierten Zeichen zu identifizieren, konvertiert die TeX-Eingabe dies intern in MathML als

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

Was die MathJax-Ausgabe wiederum auf drei Spans (in den HTML-Ausgaben) oder drei Gs (in der SVG-Ausgabe) aufteilt – und dies unterbricht natürlich die Wiedergabe des kombinierten Zeichens.

(Mir ist gerade aufgefallen, dass Firefox manchmal die Spannen in den HTML-Ausgaben kombiniert, z. B. ത്ര , aber nicht den Index in കു_ശ . Chrome ist insofern "konsistenter", als nichts kombiniert wird.)

Das Problem für uns ist also: Gibt es einen prägnanten Datensatz (oder eine effiziente Heuristik), die wir verwenden könnten, um alle relevanten Situationen zu identifizieren, in denen wir in MathML zu einem mi/mo-Element neu kombinieren müssen? Sobald wir das haben, wird das Rendern auch funktionieren.

Das Problem für uns ist also: Gibt es einen prägnanten Datensatz (oder eine effiziente Heuristik), die wir verwenden könnten, um > alle relevanten Situationen zu identifizieren, in denen wir in MathML zu einem mi/mo-Element neu kombinieren müssen?

Entschuldigung für den langen Kommentar, der ein bisschen Off-Site-Diskussion zurück zum Issue-Tracker bringt.

Wie machbar/teuer wäre es, die Unicode-UCD-Datenbank zu erstellen
Kombinationsklasse, die Mathjax für jeden Charakter zur Verfügung steht? Grundsätzlich (bzw
zumindest als gute erste Annäherung) jedes Zeichen, das nicht Null ist
Die Kombinationsklasse (Feld 4 in UnicodeData.txt) muss bei der bleiben
vorangehenden, und zusätzlich, wenn es sich um Klasse 9 (virama) handelt, das folgende
Charakter muss auch zusammengehalten werden.

Es ist wahrscheinlich auch erwähnenswert, dass tex, sogar Unicode-Tex wie xetex
oder luatex werden dies ohne ziemlich sicher _nicht_ hinbekommen
Auszeichnung
das heißt, Sie benötigen \text{abc} oder \mathit{abc} oder etwas anderes
Befehl, um zu erzwingen, dass eine Zeichenkette als Text mit a gesetzt wird
eine einzige Schriftart und nicht die normale Angewohnheit von TeX, Dinge aufzuteilen
Charakter für Charakter. Auch wenn das Konstrukt wie ein Single _aussieht_
Charakter für den Autor.

In klassischem Text ist dies kein Problem, da Schriftarten nur 256 Zeichen haben können
und während komponierte Charaktere mit verschiedenen Makro-Remapping-Tricks unterstützt werden können
Das Erstellen von Zeichen nach der Basis ist selbst für einfache Personen grundsätzlich nicht tragbar
Komponieren von Akzenten wie Akut.

Die Unterstützung in Unicode-Tex-Varianten wie xetex und luatex scheint etwas variabel zu sein. Im Text xetex
übergibt die Dinge an die HarfBuzz-Bibliothek und macht das ziemlich gut. luatex handhabt es intern und funktioniert derzeit weniger gut mit virama. In Mathematik benötigen beide eine Schriftart mit einer OpenType-MATH-Tabelle, um etwas sehr Nützliches zu tun, und ich konnte keine solche Schriftart finden, die ein Virama hatte.

Das folgende Latex-Dokument verwendet Kartika im Text und lateinische moderne Mathematik in Mathematik, das werden Sie bemerken
Selbst europäische Akzente versagen normalerweise in Mathematik, aber selbst das Virama-Beispiel funktioniert, wenn Sie hier ein Markup \mbox oder mi oder mtext entsprechend in MathML hinzufügen

Das Bild zeigt oben xetex und unten luatex.

Obwohl es wünschenswert wäre, um solche Zeichenketten herum nicht so etwas wie \text{..} oder \mbox{...} zu benötigen, würde es Ihre Unicode-Unterstützung dem, was TeX derzeit leisten kann, einen großen Schritt voraus machen
es hängt also ein bisschen davon ab, was die Spezifikation der "tex-ähnlichen Syntax" ist, wie weit über das hinaus, was TeX kann, ist es vernünftig, sie zu treiben?

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

Ich bin mir nicht sicher, ob ich verstehe, worum es in der Diskussion geht, aber wenn die Idee darin besteht, zu identifizieren, welche Zeichenfolge eine einzelne Einheit darstellt, sollte Unicode-Graphem-Clustering die erforderlichen Informationen liefern.

Ja - was @khaledhosny sagt, klingt für mich nach dem Richtigen, obwohl ich nicht alle Erfahrung damit habe. Vielleicht kann @santhoshtr mehr Details beitragen.

Santhosh, ich denke, das, was @pkra oben drei Kommentare geschrieben hat, erklärt das Problem am besten.

Am 3. März 2015 um 12:05 schrieb Khaled Hosny [email protected] :

Ich bin mir nicht sicher, ob ich verstehe, worum es in der Diskussion geht, aber wenn
Die Idee ist, zu identifizieren, welche Folge von Zeichen eine einzelne bilden
Einheit, dann Unicode-Graphem-Clustering
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries sollte
die nötigen Infos geben..

Ja, aber ich nehme an, die Frage ist, inwieweit es für ein Javascript sinnvoll ist
Bibliothek dazu
von Hand, wenn die zugrunde liegende Plattform die Unicode-Eigenschaften nicht erstellt
erhältlich
und wenn es die tex-syntax emuliert, wie weit würde tex gehen? Das weißt du
über die tex-Unterstützung wie jeder andere. Wie weit wäre es sinnvoll in xetex zu
Lassen Sie einen solchen Cluster irgendetwas Vernünftiges in _math_ tun, ohne in Text zu flüchten
mit \text{..} oder einem ähnlichen Befehl, da Sie a nicht zuweisen können
\mathclass zu einem solchen Cluster?

Ich habe eine CoffeeScript-Implementierung für Grapheme gefunden.
https://github.com/devongovett/grapheme-breaker

Könnte nützlich sein.

Danke für all die nützlichen Kommentare. Zusammenfassen,

• xetex/luatex behandeln Eingaben nicht wie in dieser Ausgabe gefordert, dh ohne zusätzliches Markup wie \text
• Es ist (zumindest für mich) nicht klar, ob es Pläne gibt, dies auf diese Weise zu handhaben
• Eine Lösung könnte mit dem einfachen Ansatz beginnen, den David C skizziert hat, oder möglicherweise auf Graphem-Breaker aufbauen (danke @hartman!).

Um das zu ergänzen,

• Andererseits zeigt ein schneller Test mit LaTeXML und pandoc, dass sie solche Zeichen wie hier verlangt behandeln, dh nicht wie xetex/luatex.

Es scheint mir also, dass eine Lösung nicht in der Kern-TeX-Eingabe enthalten sein kann, sondern eine Erweiterung sein muss. Das ist natürlich kein Problem, da es wahrscheinlich ohnehin zu einer Verlängerung gekommen wäre.

Es wäre gut, von MediaWiki/WMF-Communities zu hören, wenn sie sich hier tatsächlich von den TeX-Engines abgrenzen wollen.

Auch hier wäre es gut, mehr Feedback zu bekommen.

• Ist die Behandlung von Zeichen im mathematischen Modus ohne zusätzliches Markup die zukünftige Richtung von xetex/luatex/etc, TeX-Leute?
• Leute von MediaWiki / WMF: Ist nicht standardmäßiges TeX-Verhalten tatsächlich von den relevanten Communities erwünscht?

Ohne weiteres Feedback, denke ich, sollten wir uns darauf konzentrieren / es aus dem 2.6-Meilenstein entfernen.

Lassen Sie mich das Problem hier verstehen, Leute wollen Dinge wie $x+y=<complex character>$ tun, wobei <complex character> möglicherweise ein Graphem mit mehreren Codepunkten ist und <complex character> als mathematische Kennung behandelt wird, richtig ? Wenn ja, dann denke ich, dass dies eine vernünftige Erwartung ist, und wenn aktuelle Unicode-TeX-Engines nicht richtig damit umgehen (das tun sie wahrscheinlich nicht), ist es wahrscheinlich ein Fehler oder eine fehlende Funktion, nicht etwas vom Design.

Oder möchten die Leute Dinge wie $<complex text string>$ tun, wobei <complex text string> eine Textzeichenfolge mit mehreren Zeichen ist, die möglicherweise ein komplexes Textlayout benötigt, und ein korrektes Textlayout (Bidi, Formgebung usw.) ? Ich denke nicht, dass dies eine vernünftige Erwartung ist, und hier ist eine Art Markup erforderlich, um anzuzeigen, dass dies eine normale Textzeichenfolge ist, die als solche behandelt werden muss.

Danke, @khaledhosny!

[...] Leute Dinge wie $x+y= machen wollen$ woist möglicherweise ein Graphem mit mehreren Codepunkten und hatals mathematischer Bezeichner behandelt, richtig?

Ja, so verstehe ich das auch. (Es ist ein bisschen schwierig zu sagen, da dies ursprünglich eine Anfrage von der Wikipedia-Seite ist).

Ich denke, das ist eine vernünftige Erwartung

Danke!

Wenn aktuelle Unicode-TeX-Engines nicht richtig damit umgehen (das tun sie wahrscheinlich nicht), ist es wahrscheinlich ein Fehler oder eine fehlende Funktion, nicht etwas, das beabsichtigt ist.

Danke auch dafür. Der Teil "sie tun es wahrscheinlich nicht" macht mir etwas Sorgen, aber wenn Sie und @davidcarlisle sich einig sind, dass dies das gewünschte Verhalten in Unicode-TeX-Engines ist, dann reicht uns das, denke ich.

Ich hoffe immer noch, dass sich die MediaWiki/WMF/Wikipedia-Seite meldet.

Gemäß F2F entfernen wir dies aus v2.6 Milestone (dh der kommenden Version).

Es ist nicht klar, was der richtige Ansatz ist, insbesondere in Bezug auf die Kompatibilität mit TeX/LaTeX (bzw. XeTeX/LuaTeX). Es ist auch nicht klar, was die WMF und die Wikipedia-Community hier wirklich wollen.

Um es klar zu sagen, wir schließen dieses Thema nicht und sind immer noch daran interessiert herauszufinden, wie komplexes Layout in der TeX-Eingabe funktionieren könnte.

Explosion aus der Zukunft: Es gibt einen TC39-Vorschlag "Unicode-Segmentierung", um (unter anderem) zu ermöglichen, Zeichenfolgen per Graphem aufzuteilen https://github.com/tc39/proposal-intl-segmenter. Das Repository enthält einen Link zu einem Polyfill (und es gibt anscheinend auch ein nicht standardmäßiges Chrome-Feature).

Cool. Danke, @pkra.

Kein Problem. Das Polyfill ist leider nutzlos - es deckt nur Englisch ab. Aber für diejenigen, die es ausprobieren möchten, könnte der Chrom-Build-in nützlich sein.