Mathjax: Mise en page de texte complexe, en particulier avec l'entrée TeX [était : MathJax ne prend pas en charge la mise en page de texte complexe.]

Notez que si vous définissez mtextFontInherit sur true dans les sections HTML-CSS et SVG de votre configuration, alors MathJax traitera \text{} comme un single <span> , et cela devrait faire ce que vous demandez. Vous avez raison de dire que MathJax pourrait faire mieux quand mtextFontInherit vaut false . Il devrait regrouper les caractères "inconnus" dans une seule collection, plutôt que de les placer chacun dans un <span> séparé.

PS, j'ai vu le rapport sur le bugzilla Wikimedia et je prévoyais de l'ajouter à la liste des choses à corriger. Merci de regarder le problème ici pour suivre cela.

Merci pour le conseil mtextFontInherit. J'allais l'activer de toute façon, mais c'est une raison de plus de le faire.

Une certaine prise en charge de RTL a été ajoutée dans la v2.3, mais le problème des séquences à plusieurs caractères traitées comme une unité demeure. Pour \text{} , ces caractères devraient déjà être regroupés en un seul <span> , ce serait donc une façon de le gérer, mais pas très pratique.

Idéalement, MathJax mettrait chaque séquence qui forme un groupe dans un seul <mi> ou <mo> , comme il le fait actuellement pour les lettres latines simples. J'ai examiné cela dans une certaine mesure, et il y a quelques difficultés à le gérer. Il est possible d'avoir des caractères combinés regroupés avec leurs caractères précédents, mais je ne comprends pas comment fonctionnent certains caractères. Par exemple, il semble que le virama (U + 0D4D) combine non seulement le caractère à sa gauche, mais aussi à droite, bien que je puisse le mal comprendre. Il semble également que certains de ces regroupements soient gérés par des ligatures dans les polices, et non par des combinaisons de caractères. Malheureusement, MathJax n'a pas accès aux informations de ligature des polices. Bien qu'il soit possible d'ajouter des données de ligature aux tables de polices de MathJax, cela pourrait représenter une quantité importante de données dont très peu seraient utilisées par une seule page.

Je ne connais vraiment pas assez les langages qui utilisent ces fonctionnalités pour savoir si ce que j'essaie serait suffisant ou non. Je me demande s'il est possible d'obtenir des exemples tirés de diverses langues qui montrent l'éventail des situations qui doivent être prises en compte.

Une approche pourrait consister à placer les données nécessaires au script de chaque langue dans une extension individuelle chargée pour les pages qui en ont besoin (soit explicitement dans la configuration MathJax, soit via \require{} dans les mathématiques de la page). Pensez-vous que ce serait acceptable?

Peut-être que @amire80 de notre ingénierie linguistique WMF est en mesure d'aider un peu ici...

@hartman pensez-vous que vous pourriez pousser @ amire80 un certain temps? Nous serions ravis d'améliorer cela, surtout si Wikipedia veut déployer plus largement la sortie SVG.

Je suis ici :)

Comment puis-je aider?

Essai? - Volontiers, dis-moi juste ce qu'il faut tester exactement.

Des exemples de la façon dont les scripts non latins fonctionnent dans les formules ? - Il n'est pas utilisé dans les manuels d'hébreu, mais il est utilisé dans les manuels d'arabe et de persan. Peut-être que @ebraminio peut intervenir ici.

Rien d'autre?

Merci d'être passé par @amire80 :-)

Comment puis-je aider?

J'espère que nous pourrons améliorer la gestion des caractères combinés dans les scripts non latins. Cela est apparu à plusieurs reprises sur WMF bugzilla/phabricator. Pour citer Davide de https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717 :

Idéalement, MathJax mettrait chaque séquence qui forme un groupe dans un seulou, tout comme il le fait maintenant pour les lettres latines simples. J'ai examiné cela dans une certaine mesure, et il y a quelques difficultés à le gérer. Il est possible d'avoir des caractères combinés regroupés avec leurs caractères précédents, mais je ne comprends pas comment fonctionnent certains caractères. Par exemple, il semble que le virama (U + 0D4D) combine non seulement le caractère à sa gauche, mais aussi à droite, bien que je puisse le mal comprendre. Il semble également que certains de ces regroupements soient gérés par des ligatures dans les polices, et non par des combinaisons de caractères. Malheureusement, MathJax n'a pas accès aux informations de ligature des polices. Bien qu'il soit possible d'ajouter des données de ligature aux tables de polices de MathJax, cela pourrait représenter une quantité importante de données dont très peu seraient utilisées par une seule page.

Je ne connais vraiment pas assez les langages qui utilisent ces fonctionnalités pour savoir si ce que j'essaie serait suffisant ou non. Je me demande s'il est possible d'obtenir des exemples tirés de diverses langues qui montrent l'éventail des situations qui doivent être prises en compte.

Donc notre question serait : est-ce que quelqu'un a une expertise qu'il peut partager avec nous ? @hartman a eu la gentillesse de vous pointer du doigt ;-)

(Peut-être devrions-nous diviser cela en un problème distinct.)

L'idée (très) basique de virama est que la séquence consonne + virama + consonne a trois caractères Unicode, qui apparaissent comme occupant l'espace d'un glyphe (mais cela peut devenir beaucoup plus compliqué).

Plus généralement, j'aimerais comprendre la situation actuelle de MathJax. Que dois-je faire pour tester le rendu actuel ? Installer ma propre instance ? Ou existe-t-il une instance en ligne où une version actuelle peut être testée ?

consonne + virama + consonne a trois caractères Unicode, qui apparaissent comme occupant l'espace d'un glyphe

Droit. Les caractères combinés sont assez courants dans la disposition mathématique pour que nous comprenions la situation en général.

(mais cela peut devenir beaucoup plus compliqué).

C'est notre problème. Nous manquons de détails pour la plupart des scripts non latins en langage naturel.

Ou existe-t-il une instance en ligne où une version actuelle peut être testée ?

Vous pouvez le faire sur MediaWiki (en utilisant le mode MathML/SVG de l'extension math), dans le navigateur ( cet échantillon ou ce codepen ) ou utiliser une copie locale de MathJax -- selon ce que vous voulez.

Un exemple de base : ത്ര sera converti en ത്ര et comme nous n'avons aucune routine pour identifier ces types de caractères combinés, l'entrée TeX le convertit en interne en MathML comme

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

Ce que la sortie MathJax divisera à son tour en trois span (dans les sorties HTML) ou trois g (dans la sortie SVG) - et bien sûr, cela casse le rendu du caractère combiné.

(Je viens de remarquer que Firefox combine parfois les étendues dans les sorties HTML, par exemple, ത്ര mais pas l'indice dans കു_ശ . Chrome est plus "cohérent" dans la mesure où rien n'est combiné)

Donc, pour nous, le problème est : existe-t-il un ensemble concis de données (ou une heuristique efficace) que nous pourrions utiliser pour identifier toutes les situations pertinentes où nous devons recombiner en un élément mi/mo dans le MathML ? Une fois que nous aurons cela, le rendu fonctionnera également.

Donc pour nous, le problème est : existe-t-il un ensemble concis de données (ou une heuristique efficace) que nous pourrions utiliser pour > identifier toutes les situations pertinentes où nous devons recombiner en un élément mi/mo dans le MathML ?

Désolé pour le long commentaire, ramenant un peu de discussion hors site au suivi des problèmes.

Dans quelle mesure serait-il faisable/coûteux de créer la base de données Unicode UCD
combiner la classe disponible à mathjax pour chaque personnage? Fondamentalement (ou
au moins en bonne première approximation) tout caractère non nul
la classe de combinaison (champ 4 dans UnicodeData.txt) doit rester avec le
le précédent, et en plus si c'est la classe 9 (virama) le suivant
le personnage doit également rester ensemble.

Il est probablement également intéressant de noter que tex, même tex unicode comme xetex
ou luatex ne vont certainement pas réussir sans
balisage
c'est-à-dire que vous aurez besoin de \text{abc} ou \mathit{abc} ou d'un autre
commande pour forcer une chaîne de caractères à être composée en tant que texte avec un
police unique plutôt que l'habitude normale de TeX de diviser les choses
caractère par caractère. Même si la construction _ressemble_ à un seul
caractère à l'auteur.

Dans le texte classique, ce n'est pas un problème car les polices ne peuvent avoir que 256 caractères
et tandis que les caractères composés peuvent être pris en charge avec diverses astuces de remappage de macros
composer des caractères suivant la base n'est fondamentalement pas supportable même pour de simples
composer des accents comme les aigus.

La prise en charge des variantes unicode tex telles que xetex et luatex semble un peu variable. Dans le texte, xetex
remet les choses à la bibliothèque HarfBuzz et le fait plutôt bien. luatex le gère en interne et s'en sort actuellement moins bien avec le virama. En mathématiques, les deux nécessitent une police avec une table MATH opentype pour faire quelque chose de très utile et je n'ai pas pu trouver une telle police qui avait un virama.

Le document latex suivant utilise kartika dans le texte et les mathématiques modernes latines dans les mathématiques, vous remarquerez que
même les accents européens échouent généralement en mathématiques, mais même l'exemple virama fonctionne si vous ajoutez un balisage \mbox ici ou mi ou mtext manière équivalente en MathML

L'image montre xetex en haut et luatex en bas.

Ainsi, bien qu'il soit souhaitable de ne pas exiger quelque chose comme \text{..} ou \mbox{...} autour de ces chaînes de caractères, cela placerait votre support unicode bien en avance sur ce que TeX peut actuellement réaliser
donc cela dépend un peu de ce qu'est la spécification de la "syntaxe de type tex", à quelle distance au-delà de ce que TeX peut faire est-il raisonnable de le pousser?

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

Je ne sais pas vraiment si je comprends le sujet de la discussion, mais si l'idée est d'identifier quelle séquence de caractères constitue une seule unité, alors le regroupement de graphèmes Unicode devrait fournir les informations nécessaires.

Oui - ce que dit @khaledhosny me semble être la bonne chose, même si je n'en ai pas l'expérience. Peut-être que @santhoshtr peut apporter plus de détails.

Santhosh, je pense que ce que @pkra a écrit trois commentaires ci-dessus explique le mieux le problème.

Le 3 mars 2015 à 12h05, Khaled Hosny [email protected] a écrit :

Je ne sais pas vraiment si je comprends le sujet de la discussion, mais si
l'idée est d'identifier quelle séquence de caractères constitue un seul
unité, puis clustering Unicode Grapheme
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries devrait
donner les informations nécessaires..

Oui mais je suppose que la question est de savoir dans quelle mesure cela a du sens pour un javascript
bibliothèque pour faire ça
à la main si la plate-forme sous-jacente ne crée pas les propriétés unicode
disponible
et s'il émule la syntaxe tex, jusqu'où irait tex? Vous en savez autant
sur le support tex comme n'importe qui. Jusqu'où serait-il raisonnable dans xetex de
avoir un tel cluster faire quelque chose de sensé en _math_ sans s'échapper vers le texte
avec \text{..} ou une telle commande, étant donné que vous ne pouvez pas assigner un
\mathclass à un tel cluster ?

J'ai trouvé une implémentation CoffeeScript pour les graphèmes.
https://github.com/devongovett/grapheme-breaker

Peut être utile.

Merci pour tous les commentaires utiles. Résumer,

• xetex/luatex ne gère pas l'entrée de la manière demandée dans ce problème, c'est-à-dire sans balisage supplémentaire tel que \text
• ce n'est pas clair (pour moi du moins) s'il est prévu de le gérer de cette façon
• une solution pourrait commencer par l'approche simple décrite par David C ou potentiellement s'appuyer sur graphème-breaker (merci @hartman!)

Pour ajouter à cela,

• D'un autre côté, un test rapide avec LaTeXML et pandoc indique qu'ils gèrent les caractères demandés ici, c'est-à-dire pas comme xetex/luatex.

Il me semble donc qu'une solution ne peut pas être dans l'entrée principale de TeX mais doit être une extension. Ce n'est pas un problème, bien sûr, car cela aurait probablement fini par une extension de toute façon.

Ce serait bien d'entendre les communautés MediaWiki/WMF si elles veulent réellement se démarquer des moteurs TeX ici.

Encore une fois, ce serait bien d'avoir plus de retours.

• Chez les gens de TeX, la gestion des caractères en mode mathématique sans balisage supplémentaire est-elle la direction future de xetex/luatex/etc ?
• Chez les gens de MediaWiki / WMF : un comportement TeX non standard est-il réellement souhaité par les communautés concernées ?

Sans plus de commentaires, je pense que nous devrions abandonner ce point / le déplacer hors du jalon 2.6.

Permettez-moi de comprendre le problème ici, les gens veulent faire des choses comme $x+y=<complex character>$ où <complex character> est peut-être un graphème de points multi-codes, et avoir <complex character> traité comme un identifiant mathématique, à droite ? Si tel est le cas, je pense que c'est une attente raisonnable et si les moteurs Unicode TeX actuels ne le gèrent pas correctement (ils ne le font probablement pas), il s'agit probablement d'un bogue ou d'une fonctionnalité manquante, et non de quelque chose par conception.

Ou est-ce que les gens veulent faire des choses comme $<complex text string>$ , où <complex text string> est une chaîne de texte à plusieurs caractères qui nécessite éventuellement une disposition de texte complexe et obtenir une disposition de texte appropriée (bidi, mise en forme, etc.) ? Je ne pense pas que ce soit une attente raisonnable et une sorte de balisage est nécessaire ici pour indiquer qu'il s'agit d'une chaîne de texte normale qui doit être traitée comme telle.

Merci, @khaledhosny !

[...] les gens veulent faire des choses comme $x+y=$ oùest peut-être un graphème de points multi-codes, et onttraité comme un identifiant mathématique, n'est-ce pas ?

Oui, c'est aussi ce que je comprends. (C'est un peu difficile à dire puisqu'il s'agit à l'origine d'une demande de la part de Wikipédia).

Je pense que c'est une attente raisonnable

Merci!

si les moteurs Unicode TeX actuels ne le gèrent pas correctement (ils ne le font probablement pas), il s'agit probablement d'un bogue ou d'une fonctionnalité manquante, et non de quelque chose par conception.

Merci pour ça aussi. La partie "ils ne le font probablement pas" m'inquiète légèrement, mais si vous et @davidcarlisle convenez que c'est le comportement souhaité dans les moteurs Unicode TeX, alors cela nous suffit, je pense.

En espérant toujours que le côté MediaWiki/WMF/Wikipedia intervienne.

Conformément à F2F, nous supprimons cela du jalon v2.6 (c'est-à-dire la prochaine version).

La bonne approche n'est pas claire, en particulier en termes de compatibilité avec TeX/LaTeX (ou plutôt XeTeX/LuaTeX). On ne sait pas non plus ce que le WMF et la communauté Wikipedia veulent vraiment ici.

Pour être clair, nous ne fermons pas ce problème et nous sommes toujours intéressés à comprendre comment la mise en page complexe pourrait fonctionner dans l'entrée TeX.

Blast from the future : il y a une proposition TC39 "Unicode segmentation" pour permettre (entre autres) de séparer les chaînes par graphème https://github.com/tc39/proposal-intl-segmenter. Le référentiel comprend un lien vers un polyfill (et il y a aussi une fonctionnalité Chrome non standard apparemment).

Frais. Merci, @pkra.

Aucun problème. Le polyfill est malheureusement inutile -- il ne couvre que l'anglais. Mais pour ceux qui veulent l'essayer, le chrome intégré peut être utile.