Problema
Discourse-math viene visualizzato magnificamente nel browser, ma nei contesti in cui JavaScript non può essere eseguito, la matematica viene visualizzata come sorgente LaTeX grezza. Due casi ad alto impatto:
Vista di stampa (/print o browser stampa su PDF): la matematica viene visualizzata come $...$ invece di simboli renderizzati.
Email (digest, notifiche, abbonamenti): la matematica viene inviata grezza, illeggibile ai destinatari a meno che non copino e incollino in un editor LaTeX.
Ciò interrompe importanti flussi di lavoro per le community che si affidano a Discourse per contenuti tecnici.
Perché è importante
Educatori e ricercatori STEM spesso hanno bisogno di stampare argomenti o inoltrare email. Se la matematica non è leggibile, tali esportazioni sono inutilizzabili.
Altre lacune nella stampa/email (spoiler, onebox, immagini) sono state risolte: la matematica è un’omissione lampante.
Supportare la matematica “cucinata” (cooked) in contesti non-JS renderebbe Discourse una piattaforma di prima classe per le community tecniche.
Soluzione proposta
Passaggio leggero (stampa):
Assicurarsi che la vista /print includa l’HTML della matematica “cucinata”.
Attivare la composizione tipografica di MathJax prima della stampa.
Passaggio più pesante (email):
Esplorare il rendering di MathJax lato server, come suggerito da Sam.
Renderizzare la matematica in SVG o HTML pre-cucinato in modo che i destinatari vedano equazioni leggibili direttamente nei client di posta elettronica.
Impostazione del sito opzionale:
“Usa matematica cucinata in vista di stampa/email” → consente agli amministratori di scegliere tra sorgente grezza o matematica renderizzata.
Problemi correlati / lavori precedenti
La matematica all’interno dei riquadri [details] è stata corretta (PR #111, giugno 2025).
La vista di stampa aveva già correzioni per spoiler/onebox → precedente per l’inclusione di elementi “cucinati”.
Email: il commento di Sam (#214) ha identificato il rendering lato server come la soluzione a lungo termine.
Riepilogo / TL;DR
Al momento, la matematica nella vista di stampa e nelle email viene visualizzata come LaTeX grezza. L’aggiunta del rendering della matematica “cucinata” renderebbe i PDF e i digest leggibili, professionali e coerenti con ciò che gli utenti vedono nel browser.
Riproduci su Discourse con Safari su iOS
Anche quando Richiedi sito desktop è abilitato in Safari, Discourse aggiunge ancora ?mobile_view=1 quando si apre /print, il che forza la vista di stampa mobile semplificata.
Soluzione: cambiare manualmente in ?mobile_view=0 per il layout di stampa desktop completo.
Esempio /t/fw-the-email-subject/12345/print?mobile_view=0
Sì, penso che il riassunto di Sam sia perfetto: se vogliamo che le email / la vista di stampa mostrino la matematica renderizzata, abbiamo bisogno del rendering della matematica lato server (o almeno di una “pre-renderizzazione” lato server), perché i client di posta elettronica non eseguiranno MathJax.
Un approccio realistico sarebbe:
Durante la cottura (o in un processo in background dopo la cottura), trovare gli span matematici (inline + display).
Renderizzare ogni espressione in SVG (o MathML come fallback) usando MathJax in un ambiente Node.
Sostituire la matematica nell’HTML cotto utilizzato per email/stampa con uno dei seguenti:
<img>\u003cimg src=\"data:image/svg+xml;base64,...\"\u003e (più compatibile per alcuni client, ma può diventare grande).
Memorizzare nella cache tramite una chiave stabile (ad esempio sha256(latex + display_mode + macros + font_config)), in modo da eseguire il rendering una sola volta per ogni formula unica.
Le parti complicate (ma gestibili se circoscritte attentamente):
Simulazione DOM: L’output “browser” di MathJax vuole un DOM; quindi probabilmente avremmo bisogno di mathjax-full + jsdom (o usare la rotta dell’adattatore puro).
Prestazioni / timeout: farlo in modo asincrono in una coda di lavoro e degradare con grazia (lasciare il LaTeX così com’è se il rendering fallisce).
Bizzarrie dei client di posta elettronica: alcuni client rimuovono SVG; quindi avere un piano di fallback è importante (ad esempio, testo semplice/LaTeX, o MathML dove supportato).
Se qualcuno vuole fare un rapido test, il primo esperimento che farei è:
Un minuscolo script Node che utilizza mathjax-full per renderizzare $begin:math:text$E\\=mc\\^2$end:math:text$ in SVG,
Vedere quali presupposti fa (DOM vs adattatore),
Quindi decidere se MiniRacer è un vicolo cieco e dovremmo trattarlo come “necessita di Node disponibile” (o un piccolo servizio).
Se quel test funziona, allora possiamo discutere dove si inserisce (pipeline email vs cottura vs vista di stampa) e cosa memorizziamo nella cache/archiviamo.
La matematica all’interno dei riquadri 
La vista di stampa aveva già correzioni per spoiler/onebox → precedente per l’inclusione di elementi “cucinati”.
Email: il commento di Sam (#214) ha identificato il rendering lato server come la soluzione a lungo termine.