Mathjax: Layout de texto complexo, em particular com entrada TeX [era: MathJax não suporta layout de texto complexo.]

Observe que se você definir mtextFontInherit para true nas seções HTML-CSS e SVG de sua configuração, o MathJax processará \text{} como um single <span> , e isso deve fazer como você solicita. Você está certo que MathJax poderia fazer melhor quando mtextFontInherit é false . Ele deve agrupar caracteres "desconhecidos" em uma única coleção, em vez de colocar cada um em um <span> separado.

PS, eu vi o relatório sobre o bugzilla da Wikimedia e estava planejando adicioná-lo à lista de coisas a serem corrigidas. Obrigado por abordar o problema aqui para rastrear isso.

Obrigado pela dica mtextFontInherit. Eu ia habilitar isso de qualquer maneira, mas esta é mais uma razão para fazer isso.

Algum suporte para RTL foi adicionado na v2.3, mas o problema de sequências de vários caracteres sendo tratadas como uma unidade permanece. Para \text{} , esses caracteres já devem estar agrupados em um único <span> , então essa seria uma maneira de lidar com isso, embora não muito conveniente.

Idealmente, o MathJax colocaria cada sequência que forma um grupo em um único <mi> ou <mo> , assim como faz para letras latinas únicas agora. Eu examinei isso até certo ponto, e há algumas dificuldades em lidar com isso. É possível combinar caracteres agrupados com seus caracteres anteriores, mas não está claro para mim como alguns caracteres funcionam. Por exemplo, parece que o virama (U+0D4D) combina não apenas o personagem à sua esquerda, mas também à direita, embora eu possa estar entendendo mal. Parece também que alguns desses agrupamentos são tratados por ligaduras dentro das fontes, não pela combinação de caracteres. Infelizmente, o MathJax não tem acesso às informações de ligadura das fontes. Embora seja possível adicionar dados de ligadura às tabelas de fontes do MathJax, isso pode ser uma quantidade significativa de dados, dos quais muito pouco seria usado por qualquer página.

Eu realmente não estou familiarizado o suficiente com as linguagens que usam esses recursos para saber se o que estou testando seria suficiente ou não. Eu estou querendo saber se é possível obter alguns exemplos de uma variedade de linguagens que mostram a gama de situações que precisam ser acomodadas.

Uma abordagem pode ser colocar os dados necessários para o script de cada idioma em uma extensão individual que é carregada para as páginas que precisam (explicitamente na configuração do MathJax ou via \require{} dentro da matemática da página). Você acha que isso seria aceitável?

Talvez @amire80 da nossa engenharia de linguagem WMF possa ajudar um pouco aqui...

@hartman você acha que poderia cutucar @amire80 algum dia? Adoraríamos melhorar isso, especialmente se a Wikipedia quiser lançar a saída SVG mais amplamente.

Eu estou bem aqui :)

Como posso ajudar?

Testando? - Com prazer, apenas me diga o que testar exatamente.

Exemplos de como scripts não latinos funcionam em fórmulas? - Não é usado em livros didáticos de hebraico, mas é usado em livros didáticos em árabe e persa. Talvez @ebraminio possa entrar aqui.

Algo mais?

Obrigado por visitar @amire80 :-)

Como posso ajudar?

Espero que possamos melhorar o manuseio de caracteres combinados em scripts não latinos. Isso surgiu no bugzilla/phabricator do WMF repetidamente. Para citar Davide de https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717 :

Idealmente, o MathJax colocaria cada sequência que forma um grupo em um únicoou, assim como faz para letras latinas únicas agora. Eu examinei isso até certo ponto, e há algumas dificuldades em lidar com isso. É possível combinar caracteres agrupados com seus caracteres anteriores, mas não está claro para mim como alguns caracteres funcionam. Por exemplo, parece que o virama (U+0D4D) combina não apenas o personagem à sua esquerda, mas também à direita, embora eu possa estar entendendo mal. Parece também que alguns desses agrupamentos são tratados por ligaduras dentro das fontes, não pela combinação de caracteres. Infelizmente, o MathJax não tem acesso às informações de ligadura das fontes. Embora seja possível adicionar dados de ligadura às tabelas de fontes do MathJax, isso pode ser uma quantidade significativa de dados, dos quais muito pouco seria usado por qualquer página.

Eu realmente não estou familiarizado o suficiente com as linguagens que usam esses recursos para saber se o que estou testando seria suficiente ou não. Eu estou querendo saber se é possível obter alguns exemplos de uma variedade de linguagens que mostram a gama de situações que precisam ser acomodadas.

Então, nossa pergunta seria: alguém tem experiência que possa compartilhar conosco? @hartman teve a gentileza de apontar para você ;-)

(Talvez devêssemos dividir isso em uma questão separada.)

A ideia (muito) básica de virama é que a sequência de consoante + virama + consoante tem três caracteres Unicode, que aparecem como ocupando o espaço de um glifo (mas pode ficar muito mais complicado).

Mais geralmente, eu adoraria entender a situação atual do MathJax. O que devo fazer para testar a renderização atual? Instalar minha própria instância? Ou existe uma instância online onde uma versão atual pode ser testada?

consoante + virama + consoante tem três caracteres Unicode, que aparecem como ocupando o espaço de um glifo

Certo. Caracteres combinados são bastante comuns no layout matemático para que possamos entender a situação em geral.

(mas pode ficar muito mais complicado).

Esse é o nosso problema. Não temos as especificidades para a maioria das linguagens naturais, scripts não latinos.

Ou existe uma instância online onde uma versão atual pode ser testada?

Você pode fazer isso no MediaWiki (usando o modo MathML/SVG da extensão math), no navegador ( este exemplo ou este codepen ) ou usar uma cópia local do MathJax -- o que você quiser.

Um exemplo básico: ത്ര será convertido para ത്ര e como não temos rotinas para identificar esses tipos de caracteres combinados, a entrada do TeX converte isso internamente para 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 a saída MathJax, por sua vez, será dividida em três spans (nas saídas HTML) ou três gs (na saída SVG) - e é claro que isso quebra a renderização do caractere combinado.

(Acabei de notar que o Firefox às vezes combina os intervalos nas saídas HTML, por exemplo, ത്ര mas não o subscrito em കു_ശ . O Chrome é mais "consistente" porque nada é combinado)

Então, para nós, o problema é: existe um conjunto conciso de dados (ou alguma heurística eficiente) que possamos usar para identificar todas as situações relevantes em que precisamos recombinar em um elemento mi/mo no MathML? Assim que tivermos isso, a renderização também funcionará.

Então, para nós, o problema é: existe um conjunto conciso de dados (ou alguma heurística eficiente) que possamos usar para > identificar todas as situações relevantes em que precisamos recombinar em um elemento mi/mo no MathML?

Desculpe pelo longo comentário, trazendo um pouco de discussão fora do site de volta ao rastreador de problemas.

Quão viável/caro seria fazer o banco de dados Unicode UCD
combinando classe disponível para mathjax para cada personagem? Basicamente (ou
pelo menos como uma boa primeira aproximação) qualquer caractere com diferente de zero
classe de combinação (campo 4 em UnicodeData.txt) precisa ficar com o
anterior, e além disso se for classe 9 (virama) o seguinte
personagem precisa ser mantido junto também.

Provavelmente também vale a pena notar que tex, mesmo tex unicode como xetex
ou luatex quase certamente _não_ vão acertar isso sem
marcação
ou seja, você precisará de \text{abc} ou \mathit{abc} ou algum outro
comando para forçar uma string de caracteres a ser digitada como texto com um
fonte única em vez do hábito normal do TeX de dividir as coisas
personagem por personagem. Mesmo que a construção _se pareça_ com um único
personagem ao autor.

No tex clássico, não é um problema, pois as fontes podem ter apenas 256 caracteres
e enquanto os caracteres compostos podem ser suportados com vários truques de remapeamento de macro
a composição de caracteres seguindo a base basicamente não é suportável, mesmo para simples
compondo acentos como agudo.

O suporte em variantes tex unicode, como xetex e luatex, parece um pouco variável. Em texto, xetex
entrega as coisas para a biblioteca HarfBuzz, então faz muito bem. luatex lida com isso internamente e atualmente faz menos bem com o virama. Em matemática ambos exigem uma fonte com uma tabela MATH opentype para fazer algo muito útil e não consegui encontrar uma fonte que tivesse uma virama.

O seguinte documento de látex está usando kartika em texto e matemática moderna latina em matemática, você notará que
até os acentos europeus normalmente falham em matemática, mas mesmo o exemplo virama funciona se você adicionar alguma marcação \mbox aqui ou mi ou mtext equivalentemente em MathML

A imagem mostra xetex na parte superior e luatex na parte inferior.

Portanto, embora não seja desejável algo como \text{..} ou \mbox{...} em torno de tais cadeias de caracteres, isso colocaria seu suporte unicode muito à frente do que o TeX pode alcançar atualmente
então depende um pouco de qual é a especificação da "sintaxe tipo tex", quão além do que o TeX pode fazer é razoável empurrá-lo?

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

Não tenho certeza se entendi do que se trata a discussão, mas se a ideia é identificar qual sequência de caracteres constitui uma única unidade, o agrupamento de grafemas Unicode deve fornecer as informações necessárias.

Sim - o que @khaledhosny diz parece a coisa certa para mim, embora eu não tenha muita experiência com isso. Talvez @santhoshtr possa contribuir com mais detalhes.

Santhosh, acho que o que @pkra escreveu três comentários acima explica melhor o problema.

Em 3 de março de 2015 às 12h05, Khaled Hosny [email protected] escreveu:

Não tenho certeza se entendi do que se trata a discussão, mas se
a ideia é identificar qual sequência de caracteres constitui um único
unidade e, em seguida, clustering de Grafemas Unicode
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries deve
forneça as informações necessárias..

Sim, mas suponho que a questão é até que ponto faz sentido para um javascript
biblioteca para fazer isso
manualmente se a plataforma subjacente não fizer as propriedades unicode
acessível
e se estiver emulando a sintaxe do tex, até onde o tex iria? Você sabe tanto
sobre o suporte tex como ninguém. Até que ponto seria razoável em xetex para
faça com que esse cluster faça qualquer coisa sensata em _math_ sem escapar para texto
com \text{..} ou algum comando semelhante, dado que você não pode atribuir um
\mathclass para tal cluster?

Encontrei uma implementação CoffeeScript para grafemas.
https://github.com/devongovett/grapheme-breaker

Pode ser útil.

Obrigado por todos os comentários úteis. Para resumir,

• xetex/luatex não trata a entrada da maneira solicitada neste problema, ou seja, sem marcação extra, como \text
• não está claro (pelo menos para mim) se há planos para lidar com isso dessa maneira
• uma solução pode começar com a abordagem simples que David C descreveu ou potencialmente construir no quebra-grafema (obrigado @hartman!)

Para adicionar a isso,

• Por outro lado, um teste rápido com LaTeXML e pandoc indica que eles lidam com os caracteres solicitados aqui, ou seja, não como xetex/luatex.

Portanto, parece-me que uma solução não pode estar na entrada principal do TeX, mas precisa ser uma extensão. Isso não é um problema, é claro, já que provavelmente acabaria sendo uma extensão de qualquer maneira.

Seria bom ouvir as comunidades MediaWiki/WMF se eles realmente quiserem delinear os mecanismos TeX aqui.

Novamente, seria bom obter mais feedback.

• No pessoal do TeX, lidar com caracteres no modo matemático sem marcação extra é a direção futura de xetex/luatex/etc?
• No pessoal do MediaWiki / WMF: o comportamento fora do padrão do TeX é realmente desejado pelas comunidades relevantes?

Sem mais feedback, acho que devemos apostar nisso / tirá-lo do marco 2.6.

Deixe-me entender o problema aqui, as pessoas querem fazer coisas como $x+y=<complex character>$ onde <complex character> é possivelmente um grafema de ponto multi-código, e ter <complex character> tratado como um identificador matemático, certo ? Se sim, então eu acho que é uma expectativa razoável e se os atuais mecanismos Unicode TeX não lidarem com isso corretamente (eles provavelmente não o fazem), é provável que seja um bug ou um recurso ausente, não algo por design.

Ou é que as pessoas querem fazer coisas como $<complex text string>$ , onde <complex text string> é uma string de texto com vários caracteres que possivelmente precisa de um layout de texto complexo e obter um layout de texto adequado (bidi, modelagem etc.) ? Eu não acho que seja uma expectativa razoável e algum tipo de marcação é necessária aqui para indicar que esta é uma string de texto regular que precisa ser tratada como tal.

Obrigado, @khaledhosny!

[...] as pessoas querem fazer coisas como $x+y=$ ondeé possivelmente um grafema de ponto multi-código, e temtratado como um identificador matemático, certo?

Sim, é assim que eu entendo também. (É um pouco difícil dizer, pois este é originalmente um pedido do final da Wikipedia).

Eu acho que é uma expectativa razoável

Obrigado!

se os atuais mecanismos Unicode TeX não lidarem com isso corretamente (provavelmente não), provavelmente é um bug ou um recurso ausente, não algo por design.

Obrigado por isso também. A parte "eles provavelmente não" me preocupa um pouco, mas se você e @davidcarlisle concordam que é o comportamento desejado nos mecanismos Unicode TeX, então isso é suficiente para nós, eu acho.

Ainda esperando que o lado do MediaWiki/WMF/Wikipedia entre em contato.

De acordo com o F2F, estamos removendo isso do marco v2.6 (ou seja, o próximo lançamento).

Não está claro qual é a abordagem correta, em particular, em termos de compatibilidade com TeX/LaTeX (ou melhor, XeTeX/LuaTeX). Também não está claro o que o WMF e a comunidade Wikipedia realmente querem aqui.

Para ser claro, não estamos encerrando este problema e ainda estamos interessados ​​em descobrir como o layout complexo pode funcionar na entrada do TeX.

Explosão do futuro: há uma proposta TC39 "segmentação Unicode" para permitir (entre outras coisas) dividir strings por grafema https://github.com/tc39/proposal-intl-segmenter. O repositório inclui um link para um polyfill (e também há um recurso não padrão do Chrome, aparentemente).

Frio. Obrigado, @pkra.

Sem problemas. Infelizmente, o polyfill é inútil - ele cobre apenas o inglês. Mas para aqueles que querem experimentá-lo, o chrome build-in pode ser útil.