Incluir Discourse-math cocinado en la vista de impresión y correos electrónicos

Característica
, ,
1

Problema
Discourse-math se renderiza perfectamente en el navegador, pero en contextos donde JavaScript no puede ejecutarse, las matemáticas se degradan a código LaTeX sin procesar. Dos casos de alto impacto:

  • Vista de impresión (/print o navegador imprimir a PDF): las matemáticas se muestran como $...$ en lugar de símbolos renderizados.
  • Correos electrónicos (resúmenes, notificaciones, suscripciones): las matemáticas se entregan sin procesar, ilegibles para los destinatarios a menos que copien y peguen en un editor de LaTeX.

Esto interrumpe flujos de trabajo importantes para las comunidades que dependen de Discourse para contenido técnico.

Por qué importa

  • Los educadores e investigadores de STEM a menudo necesitan imprimir temas o reenviar correos electrónicos. Si las matemáticas no son legibles, esas exportaciones no se pueden utilizar.
  • Otras lagunas en la impresión/correos electrónicos (spoilers, oneboxes, imágenes) se han solucionado; las matemáticas son una omisión flagrante.
  • El soporte para matemáticas cocinadas en contextos sin JS haría de Discourse una plataforma de primera clase para comunidades técnicas.

Solución propuesta

  • Paso ligero (impresión):
    • Asegurar que la vista /print incluya HTML de matemáticas cocinadas.
    • Activar la composición de MathJax antes de imprimir.
  • Paso más pesado (correos electrónicos):
    • Explorar la renderización de MathJax en el lado del servidor, como sugirió Sam.
    • Renderizar las matemáticas a SVG o HTML pre-cocinado para que los destinatarios vean ecuaciones legibles directamente en los clientes de correo electrónico.
  • Configuración opcional del sitio:
    • “Usar matemáticas cocinadas en vista de impresión/correos electrónicos” → permite a los administradores elegir entre código fuente sin procesar o matemáticas renderizadas.

Problemas relacionados / trabajo previo

  • :white_check_mark: Se solucionaron las matemáticas dentro de los paneles [details] (PR #111, junio de 2025).
  • :memo: La vista de impresión ya tenía correcciones para spoilers/oneboxes → precedente para incluir elementos cocinados.
  • :e_mail: Correos electrónicos: El comentario de Sam (#214) identificó la renderización en el lado del servidor como la solución a largo plazo.

Resumen / TL;DR
En este momento, las matemáticas en la vista de impresión y en los correos electrónicos se degradan a LaTeX sin procesar. Agregar la renderización de matemáticas cocinadas haría que los PDF y los resúmenes fueran legibles, profesionales y consistentes con lo que los usuarios ven en el navegador.

Reproducir en Discourse con Safari en iOS

Incluso cuando Solicitar sitio de escritorio está habilitado en Safari, Discourse todavía agrega
?mobile_view=1 al abrir /print, lo que fuerza la vista de impresión móvil simplificada.

Solución: cambie manualmente a ?mobile_view=0 para obtener el diseño de impresión de escritorio completo.

Ejemplo
/t/fw-the-email-subject/12345/print?mobile_view=0

3 Me gusta
2

Sí, creo que el resumen de Sam es acertado: si queremos que el correo electrónico / la vista de impresión muestren matemáticas renderizadas, necesitamos renderizado de matemáticas del lado del servidor (o al menos “pre-renderizado” del lado del servidor), porque los clientes de correo electrónico no ejecutarán MathJax.

Un enfoque realista sería:

  • Durante la cocción (o en un trabajo en segundo plano después de la cocción), buscar los tramos de matemáticas (en línea + visualización).
  • Renderizar cada expresión a SVG (o MathML como alternativa) usando MathJax en un entorno Node.
  • Reemplazar las matemáticas en el HTML cocido utilizado para correo electrónico/impresión con:
    • \u003csvg ...\u003e en línea (mejor fidelidad, sin búsqueda externa), o
    • \u003cimg src=\"data:image/svg+xml;base64,...\"\u003e (más compatible para algunos clientes, pero puede volverse grande).
  • Almacenar en caché mediante una clave estable (por ejemplo, sha256(latex + display_mode + macros + font_config)), para que solo rendericemos una vez por fórmula única.

Las partes complicadas (pero manejables si se delimitan cuidadosamente):

  • Simulación de DOM: La salida de “navegador” de MathJax quiere un DOM; por lo que probablemente necesitaríamos mathjax-full + jsdom (o usar la ruta del adaptador puro).
  • Rendimiento / tiempos de espera: hacerlo de forma asíncrona en una cola de trabajos y degradar elegantemente (dejar LaTeX tal como está si el renderizado falla).
  • Peculiaridades de los clientes de correo electrónico: algunos clientes eliminan SVG; por lo que tener un plan de respaldo es importante (por ejemplo, texto plano/LaTeX, o MathML donde sea compatible).

Si alguien quiere una prueba rápida, el primer experimento que haría es:

  1. Un pequeño script de Node usando mathjax-full para renderizar $begin:math:text$E\\=mc\\^2$end:math:text$ a SVG,
  2. Ver qué suposiciones hace (DOM vs adaptador),
  3. Luego decidir si MiniRacer es un callejón sin salida y deberíamos tratar esto como “necesita Node disponible” (o un servicio pequeño).

Si esa prueba funciona, entonces podemos hablar sobre dónde encaja (tubería de correo electrónico vs cocción vs vista de impresión), y qué almacenamos en caché/guardamos.