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

[Ethsim2 (Ethan)]

Problema
O Discourse-math é renderizado de forma excelente no navegador, mas em contextos onde o JavaScript não pode ser executado, a matemática volta à fonte LaTeX bruta. Dois casos de alto impacto:
\n

• Visualização de impressão (/print ou navegador imprimir para PDF): a matemática aparece como $...$ em vez de símbolos renderizados.
• E-mails (resumos, notificações, assinaturas): a matemática é entregue bruta, ilegível para os destinatários, a menos que eles copiem e colem em um editor LaTeX.
  \n
  Isso quebra fluxos de trabalho importantes para comunidades que dependem do Discourse para conteúdo técnico.
  \n
  —\n
  \nPor que importa
• Educadores e pesquisadores de STEM frequentemente precisam imprimir tópicos ou encaminhar e-mails. Se a matemática não for legível, essas exportações são inutilizáveis.
• Outras lacunas em impressão/e-mails (spoilers, oneboxes, imagens) foram corrigidas — a matemática é uma omissão gritante.
• Suportar matemática “cozida” em contextos sem JS tornaria o Discourse uma plataforma de primeira classe para comunidades técnicas.
  \n
  —\n
  \nSolução proposta
• Etapa leve (impressão):
  • Garantir que a visualização /print inclua o HTML da matemática “cozida”.
  • Acionar a composição do MathJax antes da impressão.
• Etapa mais pesada (e-mails):
  • Explorar a renderização do MathJax no lado do servidor, como sugerido por Sam.
  • Renderizar a matemática para SVG ou HTML pré-cozido para que os destinatários vejam equações legíveis diretamente nos clientes de e-mail.
• Configuração de site opcional:
  • “Usar matemática cozida em visualização de impressão/e-mails” → permite que os administradores escolham entre fonte bruta vs. matemática renderizada.
    \n
    —\n
    \nProblemas relacionados / trabalho anterior
• Matemática dentro de painéis [details] corrigida (PR #111, junho de 2025).
• A visualização de impressão já tinha correções para spoilers/oneboxes → precedente para incluir elementos cozidos.
• E-mails: O comentário de Sam (#214) identificou a renderização no lado do servidor como a solução de longo prazo.
  \n
  —\n
  \nResumo / TL;DR
  No momento, a matemática na visualização de impressão e nos e-mails volta à fonte LaTeX bruta. Adicionar a renderização de matemática cozida tornaria os PDFs e resumos legíveis, profissionais e consistentes com o que os usuários veem no navegador.
  \n

Reproduzir no Discourse com Safari no iOS

Mesmo quando Solicitar Site para Computador está ativado no Safari, o Discourse ainda anexa
?mobile_view=1 ao abrir /print, o que força a visualização de impressão móvel simplificada.
\n
Solução alternativa: altere manualmente para ?mobile_view=0 para o layout completo de impressão para desktop.
\n
Exemplo
/t/fw-the-email-subject/12345/print?mobile_view=0

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