Discourse-math gekocht in Druckansicht und E-Mails aufnehmen

[Ethsim2 (Ethan)]

@sam

@Lhc_fl

Hallo, das Math-Plugin scheint auf das Frontend für das Rendern angewiesen zu sein. Daher können unsere E-Mail-Benutzer die gerenderte mathematische Formel nicht empfangen.

Gibt es eine Möglichkeit, dieses Problem zu lösen?

Technisch gesehen, ja … aber es ist knifflig. Wir müssten MathJax in Mini Racer (oder Node) laden, das DOM simulieren und in eine SVG rendern.

Ich bin sicher, das wurde schon einmal von einigen Leuten gemacht, kann aber keine einfachen Beispiele in freier Wildbahn finden, die gewartet werden. Wahrscheinlich lohnt es sich, zuerst zu testen, ob das Node-Paket überhaupt funktioniert.

Ja, ich denke, Sams Zusammenfassung ist zutreffend: Wenn wir möchten, dass E-Mails / Druckansichten gerenderte Mathematik anzeigen, benötigen wir serverseitiges Math-Rendering (oder zumindest serverseitiges „Vorab-Rendern“), da E-Mail-Clients MathJax nicht ausführen werden.

Ein realistischer Ansatz wäre:

• Während des Kochens (oder in einem Hintergrundauftrag nach dem Kochen) die Mathe-Spannen finden (inline + Anzeige).
• Jeden Ausdruck mit MathJax in einer Node-Umgebung in SVG (oder MathML als Fallback) rendern.
• Die Mathe im gekochten HTML, das für E-Mail/Druck verwendet wird, ersetzen durch entweder:
  • Inline <svg ...> (beste Wiedergabetreue, kein externer Abruf), oder
  • <img src="data:image/svg+xml;base64,..."> (kompatibler für einige Clients, kann aber groß werden).
• Nach einem stabilen Schlüssel cachen (z. B. sha256(latex + display_mode + macros + font_config)), damit wir nur einmal pro eindeutiger Formel rendern.

Die kniffligen Teile (die aber bei sorgfältiger Eingrenzung handhabbar sind):

• DOM-Simulation: Die „Browser“-Ausgabe von MathJax benötigt ein DOM; daher bräuchten wir wahrscheinlich mathjax-full + jsdom (oder die reine Adapter-Route verwenden).
• Leistung / Timeouts: Asynchron in einer Job-Warteschlange ausführen und elegant zurückfallen (LaTeX unverändert lassen, wenn das Rendern fehlschlägt).
• Eigenheiten von E-Mail-Clients: Einige Clients entfernen SVG; daher ist ein Fallback-Plan wichtig (z. B. Klartext/LaTeX oder MathML, wo unterstützt).

Wenn jemand einen schnellen Test durchführen möchte, wäre das erste Experiment, das ich machen würde:

1. Ein winziges Node-Skript, das mathjax-full verwendet, um $begin:math:text$E\\=mc\\^2$end:math:text$ in SVG zu rendern,
2. Sehen, welche Annahmen es trifft (DOM vs. Adapter),
3. Dann entscheiden, ob MiniRacer eine Sackgasse ist und wir dies als „Node verfügbar erforderlich“ behandeln sollten (oder als kleiner Dienst).

Wenn dieser Test funktioniert, können wir darüber sprechen, wo er angedockt wird (E-Mail-Pipeline vs. Kochen vs. Druckansicht) und was wir cachen/speichern.