Includi Discourse-math cotto nella visualizzazione di stampa e nelle email

[Ethsim2 (Ethan)]

@sam

@Lhc_fl

Ciao, il plugin Math sembra fare affidamento sul frontend per il rendering. Pertanto, i nostri utenti di posta elettronica non possono ricevere la formula matematica renderizzata.

C’è un modo per risolvere questo problema?

Tecnicamente sì… ma è complicato. Dovremmo caricare MathJax in mini racer (o node) simulare il DOM e renderizzare in un SVG.

Sono sicuro che sia stato fatto prima da alcune persone, ma non riesco a trovare esempi facili in circolazione che siano mantenuti. Probabilmente vale la pena testare se il pacchetto node funzioni anche per cominciare.

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> inline \u003csvg ...\u003e (migliore fedeltà, nessun recupero esterno), oppure
  • <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 è:

1. Un minuscolo script Node che utilizza mathjax-full per renderizzare $begin:math:text$E\\=mc\\^2$end:math:text$ in SVG,
2. Vedere quali presupposti fa (DOM vs adattatore),
3. 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.