Mathjax: Diseño de texto complejo, en particular con entrada TeX [fue: MathJax no es compatible con el diseño de texto complejo.]

Tenga en cuenta que si establece mtextFontInherit en true en las secciones HTML-CSS y SVG de su configuración, entonces MathJax procesará \text{} como un single <span> , y eso debería hacer lo que solicita. Tiene razón en que MathJax podría hacerlo mejor cuando mtextFontInherit es false . Debería agrupar los caracteres "desconocidos" en una sola colección, en lugar de poner cada uno en un <span> separado.

PD: vi el informe sobre el bugzilla de Wikimedia y estaba planeando agregarlo a la lista de cosas para arreglar. Gracias por mirar el problema aquí para rastrear eso.

Gracias por la sugerencia de mtextFontInherit. Iba a habilitar eso de todos modos, pero esta es una razón más para hacerlo.

Se agregó algo de soporte para RTL en v2.3, pero el problema de las secuencias de múltiples caracteres que se tratan como una unidad permanece. Para \text{} , estos caracteres ya deberían estar agrupados en un solo <span> , por lo que sería una forma de manejarlo, aunque no muy conveniente.

Idealmente, MathJax colocaría cada secuencia que forma un grupo en un solo <mi> o <mo> , tal como lo hace ahora con las letras latinas individuales. He investigado esto hasta cierto punto, y hay algunas dificultades para manejarlo. Es posible tener caracteres combinados agrupados con sus caracteres anteriores, pero no me queda claro cómo funcionan algunos caracteres. Por ejemplo, parece que el virama (U+0D4D) combina no solo el carácter de su izquierda, sino también el de la derecha, aunque podría estar malinterpretándolo. También parece que algunas de estas agrupaciones se manejan mediante ligaduras dentro de las fuentes, no mediante la combinación de caracteres. Desafortunadamente, MathJax no tiene acceso a la información de ligadura de las fuentes. Si bien sería posible agregar datos de ligaduras a las tablas de fuentes de MathJax, esto podría ser una cantidad significativa de datos de los cuales muy pocos serían utilizados por cualquier página.

Realmente no estoy lo suficientemente familiarizado con los lenguajes que usan estas funciones para saber si lo que estoy probando sería suficiente o no. Me pregunto si es posible obtener algunos ejemplos de una variedad de idiomas que muestren la variedad de situaciones que deben adaptarse.

Un enfoque podría ser colocar los datos necesarios para el script de cada idioma en una extensión individual que se carga para aquellas páginas que lo necesitan (ya sea explícitamente en la configuración de MathJax o a través \require{} dentro de las matemáticas en la página). ¿Crees que sería aceptable?

Quizás @amire80 de nuestra ingeniería de lenguaje WMF pueda ayudar un poco aquí...

@hartman , ¿crees que podrías pinchar a @amire80 alguna vez? Nos encantaría mejorar esto, especialmente si Wikipedia quiere implementar la salida SVG más ampliamente.

Estoy aquí :)

¿Cómo puedo ayudar?

¿Pruebas? - Con mucho gusto, solo dime qué probar exactamente.

¿Ejemplos de cómo funcionan las escrituras no latinas en las fórmulas? - No se usa en los libros de texto en hebreo, pero se usa en los libros de texto en árabe y persa. Tal vez @ebraminio pueda intervenir aquí.

¿Algo más?

Gracias por visitar @amire80 :-)

¿Cómo puedo ayudar?

Espero que podamos mejorar el manejo de caracteres combinados en escrituras no latinas. Esto ha surgido repetidamente en WMF bugzilla/phabricator. Para citar a Davide de https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717:

Idealmente, MathJax pondría cada secuencia que forma un grupo en una solao, tal como lo hace ahora con las letras latinas individuales. He investigado esto hasta cierto punto, y hay algunas dificultades para manejarlo. Es posible tener caracteres combinados agrupados con sus caracteres anteriores, pero no me queda claro cómo funcionan algunos caracteres. Por ejemplo, parece que el virama (U+0D4D) combina no solo el carácter de su izquierda, sino también el de la derecha, aunque podría estar malinterpretándolo. También parece que algunas de estas agrupaciones se manejan mediante ligaduras dentro de las fuentes, no mediante la combinación de caracteres. Desafortunadamente, MathJax no tiene acceso a la información de ligadura de las fuentes. Si bien sería posible agregar datos de ligaduras a las tablas de fuentes de MathJax, esto podría ser una cantidad significativa de datos de los cuales muy pocos serían utilizados por cualquier página.

Realmente no estoy lo suficientemente familiarizado con los lenguajes que usan estas funciones para saber si lo que estoy probando sería suficiente o no. Me pregunto si es posible obtener algunos ejemplos de una variedad de idiomas que muestren la variedad de situaciones que deben adaptarse.

Entonces, nuestra pregunta sería: ¿alguien tiene experiencia que pueda compartir con nosotros? @hartman tuvo la amabilidad de señalarte ;-)

(Quizás deberíamos dividir esto en un tema separado).

La idea (muy) básica de virama es que la secuencia de consonante + virama + consonante tiene tres caracteres Unicode, que parecen ocupar el espacio de un glifo (pero puede volverse mucho más complicado).

En términos más generales, me encantaría entender la situación actual de MathJax. ¿Qué debo hacer para probar el renderizado actual? ¿Instalar mi propia instancia? ¿O hay una instancia en línea donde se puede probar una versión actual?

consonante + virama + consonante tiene tres caracteres Unicode, que aparecen ocupando el espacio de un glifo

Derecha. Los caracteres combinados son lo suficientemente comunes en el diseño matemático para que entendamos la situación en general.

(pero puede ser mucho más complicado).

Ese es nuestro problema. Carecemos de los detalles para la mayoría de los lenguajes naturales, escrituras no latinas.

¿O hay una instancia en línea donde se puede probar una versión actual?

Puede hacer esto en MediaWiki (usando el modo MathML/SVG de la extensión matemática), en el navegador ( este ejemplo o este codepen ) o usar una copia local de MathJax, lo que desee.

Un ejemplo básico: ത്ര se convertirá en ത്ര y dado que no tenemos ninguna rutina para identificar este tipo de caracteres combinados, la entrada de TeX convierte esto internamente a MathML como

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

Que la salida de MathJax a su vez se dividirá en tres intervalos (en las salidas HTML) o tres g (en la salida SVG) y, por supuesto, esto rompe la representación del carácter combinado.

(Acabo de darme cuenta de que Firefox a veces combina los intervalos en las salidas HTML, por ejemplo, ത്ര pero no el subíndice en കു_ശ . Chrome es más "consistente" en el sentido de que no se combina nada)

Entonces, para nosotros, el problema es: ¿existe un conjunto conciso de datos (o alguna heurística eficiente) que podamos usar para identificar todas las situaciones relevantes en las que necesitamos volver a combinar en un elemento mi/mo en MathML? Una vez que tengamos eso, el renderizado también funcionará.

Entonces, para nosotros, el problema es: ¿hay un conjunto conciso de datos (o alguna heurística eficiente) que podamos usar para identificar todas las situaciones relevantes en las que necesitamos volver a combinar en un elemento mi/mo en el MathML?

Perdón por el comentario largo, trayendo un poco de discusión fuera del sitio al rastreador de problemas.

¿Qué tan factible/caro sería hacer que la base de datos Unicode UCD
combinando la clase disponible para mathjax para cada personaje? Básicamente (o
al menos como una buena primera aproximación) cualquier carácter que no sea cero
la clase de combinación (campo 4 en UnicodeData.txt) debe permanecer con el
precedente, y además si es clase 9 (virama) el siguiente
el carácter también debe mantenerse unido.

Probablemente también valga la pena señalar que tex, incluso unicode tex como xetex
o luatex es casi seguro que _no_ van a hacer esto bien sin
margen
es decir, necesitará \text{abc} o \mathit{abc} o algún otro
comando para forzar que una cadena de caracteres se escriba como texto con un
fuente única en lugar del hábito normal de TeX de dividir las cosas
personaje por personaje. Incluso si la construcción _parece_ como un solo
personaje al autor.

En texto clásico no es un problema ya que las fuentes solo pueden tener 256 caracteres
y aunque los personajes compuestos se pueden admitir con varios trucos de reasignación de macros
componer caracteres siguiendo la base básicamente no es compatible incluso para simples
componer acentos como agudos.

El soporte en variantes de texto Unicode como xetex y luatex parece un poco variable. En texto, xetex
entrega las cosas a la biblioteca HarfBuzz, por lo que lo hace bastante bien. luatex lo maneja internamente y actualmente lo hace menos bien con el virama. En matemáticas, ambos requieren una fuente con una tabla MATH de tipo abierto para hacer algo muy útil y no pude encontrar una fuente que tuviera un virama.

El siguiente documento de látex usa kartika en texto y matemáticas modernas latinas en matemáticas, notará que
incluso los acentos europeos suelen fallar en matemáticas, pero incluso el ejemplo de virama funciona si agrega algo de marcado \mbox aquí o mi o mtext manera equivalente en MathML

La imagen muestra xetex en la parte superior y luatex en la parte inferior.

Entonces, aunque sería deseable no requerir algo como \text{..} o \mbox{...} alrededor de tales cadenas de caracteres, pondría su compatibilidad con Unicode muy por delante de lo que TeX puede lograr actualmente.
por lo tanto, depende un poco de cuál sea la especificación de la "sintaxis similar a tex", ¿qué tan lejos de lo que puede hacer TeX es razonable impulsarlo?

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

No estoy muy seguro de entender de qué se trata la discusión, pero si la idea es identificar qué secuencia de caracteres constituye una sola unidad, entonces el agrupamiento de grafemas Unicode debería proporcionar la información necesaria.

Sí, lo que dice @khaledhosny me parece correcto, aunque no tengo mucha experiencia con eso. Tal vez @santhoshtr pueda aportar más detalles.

Santhosh, creo que lo que @pkra escribió tres comentarios arriba explica mejor el problema.

El 3 de marzo de 2015 a las 12:05, Khaled Hosny [email protected] escribió:

No estoy muy seguro de entender de qué se trata la discusión, pero si
la idea es identificar qué secuencia de caracteres constituye un único
unidad, luego agrupamiento Unicode Grapheme
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries debería
proporcionar la información necesaria..

Sí, pero supongo que la pregunta es hasta qué punto tiene sentido para un javascript.
biblioteca para hacer eso
a mano si la plataforma subyacente no tiene las propiedades Unicode
disponible
y si está emulando la sintaxis de tex, ¿hasta dónde llegaría tex? sabes tanto
sobre el soporte de tex como nadie. ¿Hasta dónde sería razonable en xetex
hacer que un grupo de este tipo haga algo sensato en _matemáticas_ sin escapar al texto
con \text{..} o algún comando similar, dado que no puede asignar un
\mathclass a tal clúster?

Encontré una implementación de CoffeeScript para grafemas.
https://github.com/devongovett/grapheme-breaker

Podría ser útil

Gracias por todos los comentarios útiles. Para resumir,

• xetex/luatex no maneja la entrada de la forma solicitada en este problema, es decir, sin marcado adicional como \text
• no está claro (al menos para mí) si hay planes para manejarlo de esta manera
• una solución podría comenzar con el enfoque simple que David C describió o potencialmente construir sobre el rompedor de grafemas (¡gracias @hartman!)

Para agregar a eso,

• Por otro lado, una prueba rápida con LaTeXML y pandoc indica que manejan los caracteres que se solicitan aquí, es decir, no como xetex/luatex.

Entonces, me parece que una solución no puede estar en la entrada principal de TeX, sino que debe ser una extensión. Eso no es un problema, por supuesto, ya que probablemente habría terminado en una extensión de todos modos.

Sería bueno saber de las comunidades de MediaWiki/WMF si realmente quieren delinear los motores TeX aquí.

Una vez más, sería bueno recibir más comentarios.

• En TeX, ¿el manejo de caracteres en modo matemático sin marcas adicionales es la dirección futura de xetex/luatex/etc?
• En MediaWiki / WMF amigos: ¿las comunidades relevantes realmente desean un comportamiento TeX no estándar?

Sin más comentarios, creo que deberíamos despejar esto / sacarlo del hito 2.6.

Permítanme entender el problema aquí, la gente quiere hacer cosas como $x+y=<complex character>$ donde <complex character> es posiblemente un grafema de punto de código múltiple, y que <complex character> se trate como un identificador matemático, ¿verdad? ? Si es así, creo que es una expectativa razonable y si los motores Unicode TeX actuales no lo manejan correctamente (probablemente no lo hagan), es probable que sea un error o una característica faltante, no algo por diseño.

¿O es que la gente quiere hacer cosas como $<complex text string>$ , donde <complex text string> es una cadena de texto de varios caracteres que posiblemente necesite un diseño de texto complejo y obtener un diseño de texto adecuado (bidi, forma, etc.) ? No creo que sea una expectativa razonable y se necesita algún tipo de marcado aquí para indicar que se trata de una cadena de texto normal que debe tratarse como tal.

¡Gracias, @khaledhosny!

[...] la gente quiere hacer cosas como $x+y=$ dondees posiblemente un grafema de punto de código múltiple, y tienetratado como un identificador matemático, ¿verdad?

Sí, así lo entiendo yo también. (Es un poco difícil de decir ya que originalmente es una solicitud del extremo de Wikipedia).

Creo que es una expectativa razonable.

¡Gracias!

si los motores Unicode TeX actuales no lo manejan correctamente (probablemente no lo hagan), es probable que sea un error o una característica faltante, no algo por diseño.

Gracias por eso, también. La parte de "probablemente no" me preocupa un poco, pero si usted y @davidcarlisle están de acuerdo en que es el comportamiento deseado en los motores Unicode TeX, creo que eso es suficiente para nosotros.

Todavía espero que el lado de MediaWiki/WMF/Wikipedia participe.

Según F2F, estamos eliminando esto del Milestone v2.6 (es decir, el próximo lanzamiento).

No está claro cuál es el enfoque correcto, en particular, en términos de compatibilidad con TeX/LaTeX (o más bien XeTeX/LuaTeX). Tampoco está claro lo que WMF y la comunidad de Wikipedia realmente quieren aquí.

Para ser claros, no estamos cerrando este problema y todavía estamos interesados ​​en averiguar cómo podría funcionar el diseño complejo en la entrada de TeX.

Explosión del futuro: hay una propuesta TC39 de "segmentación Unicode" para permitir (entre otras cosas) dividir cadenas por grafema https://github.com/tc39/proposal-intl-segmenter. El repositorio incluye un enlace a un polyfill (y aparentemente también hay una característica de Chrome no estándar).

Frio. Gracias, @pkra.

No hay problema. Desafortunadamente, el polyfill es inútil: solo cubre Enligsh. Pero para aquellos que quieran probarlo, la integración de Chrome podría ser útil.