Incluir Discourse-math cozido na visualização de impressão e e-mails

[Ethsim2 (Ethan)]

@sam

@Lhc_fl

Olá, o plugin de Matemática parece depender do frontend para renderização. Portanto, nossos usuários de e-mail não conseguem receber a fórmula matemática renderizada.

Existe alguma maneira de resolver esse problema?

Tecnicamente, sim… mas é complicado. Precisaríamos carregar o MathJax no Mini Racer (ou Node), simular o DOM e renderizar para um SVG.

Tenho certeza de que isso já foi feito por algumas pessoas, mas não consigo encontrar exemplos fáceis e mantidos por aí. Provavelmente vale a pena testar se o pacote Node funciona para começar.

Sim, acho que o resumo do Sam está correto: se quisermos que e-mails / visualização de impressão mostrem a matemática renderizada, precisamos de renderização de matemática no lado do servidor (ou pelo menos “pré-renderização” no lado do servidor), porque os clientes de e-mail não executarão o MathJax.

Uma abordagem realista seria:

• Durante o cozimento (ou em um trabalho em segundo plano após o cozimento), encontrar os spans de matemática (inline + display).
• Renderizar cada expressão para SVG (ou MathML como fallback) usando MathJax em um ambiente Node.
• Substituir a matemática no HTML cozido usado para e-mail/impressão por:
  • \u003csvg ...\u003e inline (melhor fidelidade, sem busca externa), ou
  • \u003cimg src=\"data:image/svg+xml;base64,...\"\u003e (mais compatível para alguns clientes, mas pode ficar grande).
• Armazenar em cache por uma chave estável (por exemplo, sha256(latex + display_mode + macros + font_config)), para que renderizemos apenas uma vez por fórmula exclusiva.

As partes complicadas (mas gerenciáveis se escopadas com cuidado):

• Simulação de DOM: A saída “de navegador” do MathJax quer um DOM; então provavelmente precisaríamos do mathjax-full + jsdom (ou usar a rota do adaptador puro).
• Desempenho / timeouts: fazer isso de forma assíncrona em uma fila de trabalhos e degradar graciosamente (deixar o LaTeX como está se a renderização falhar).
• Peculiaridades dos clientes de e-mail: alguns clientes removem SVG; então ter um plano de fallback é importante (por exemplo, texto simples/LaTeX, ou MathML onde for suportado).

Se alguém quiser um teste rápido, o primeiro experimento que eu faria é:

1. Um pequeno script Node usando mathjax-full para renderizar $begin:math:text$E\\=mc\\^2$end:math:text$ para SVG,
2. Ver quais suposições ele faz (DOM vs. adaptador),
3. Então decidir se o MiniRacer é um beco sem saída e devemos tratar isso como “precisa de Node disponível” (ou um pequeno serviço).

Se esse teste funcionar, então podemos discutir onde ele se encaixa (pipeline de e-mail vs. cozimento vs. visualização de impressão) e o que armazenamos em cache/guardamos.