Problem
Discourse-math wird im Browser schön gerendert, aber in Kontexten, in denen JavaScript nicht ausgeführt werden kann, fällt die Mathematik auf die rohe LaTeX-Quelle zurück. Zwei hochwirksame Fälle:
Druckansicht (/print oder Browser Print-to-PDF): Mathematik wird als $...$ anstelle von gerenderten Symbolen angezeigt.
E-Mails ( Digests, Benachrichtigungen, Abonnements): Mathematik wird roh geliefert, für Empfänger unlesbar, es sei denn, sie kopieren und fügen sie in einen LaTeX-Editor ein.
Dies unterbricht wichtige Arbeitsabläufe für Gemeinschaften, die sich für technische Inhalte auf Discourse verlassen.
Warum es wichtig ist
STEM-Lehrer und Forscher müssen oft Themen drucken oder E-Mails weiterleiten. Wenn die Mathematik nicht lesbar ist, sind diese Exporte unbrauchbar.
Andere Lücken in Druck/E-Mails (Spoiler, Oneboxen, Bilder) wurden behoben - Mathematik ist eine offensichtliche Auslassung.
Die Unterstützung von “gekochter” Mathematik in Nicht-JS-Kontexten würde Discourse zu einer erstklassigen Plattform für technische Gemeinschaften machen.
Vorgeschlagene Lösung
Leichter Schritt (Druck):
Stellen Sie sicher, dass die /print-Ansicht die “gekochte” Mathematik-HTML enthält.
Rendern Sie Mathematik in SVG oder vorab “gekochte” HTML, damit Empfänger lesbare Gleichungen direkt in E-Mail-Clients sehen.
Optionale Website-Einstellung:
„Gekochte Mathematik in Druckansicht/E-Mails verwenden“ → ermöglicht Administratoren die Wahl zwischen roher Quelle und gerenderter Mathematik.
Verwandte Probleme / Vorherige Arbeiten
Mathematik innerhalb von [details]-Bereichen behoben (PR #111, Juni 2025).
Druckansicht hatte bereits Korrekturen für Spoiler/Oneboxen → Präzedenzfall für die Einbeziehung “gekochter” Elemente.
E-Mails: Sams Kommentar (#214) identifizierte serverseitiges Rendering als langfristige Lösung.
Zusammenfassung / TL;DR
Derzeit fällt Mathematik in der Druckansicht und in E-Mails auf rohes LaTeX zurück. Das Hinzufügen von “gekochtem” Mathematik-Rendering würde PDFs und Digests lesbar, professionell und konsistent mit dem machen, was Benutzer im Browser sehen.
Auf Discourse mit iOS Safari reproduzieren
Selbst wenn Desktop-Website anfordern in Safari aktiviert ist, fügt Discourse immer noch ?mobile_view=1 hinzu, wenn /print geöffnet wird, was die abgespeckte mobile Druckansicht erzwingt.
Workaround: Manuell zu ?mobile_view=0 wechseln, um das vollständige Desktop-Drucklayout zu erhalten.
Beispiel /t/fw-the-email-subject/12345/print?mobile_view=0
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:
Ein winziges Node-Skript, das mathjax-full verwendet, um $begin:math:text$E\\=mc\\^2$end:math:text$ in SVG zu rendern,
Sehen, welche Annahmen es trifft (DOM vs. Adapter),
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.
Mathematik innerhalb von 
Druckansicht hatte bereits Korrekturen für Spoiler/Oneboxen → Präzedenzfall für die Einbeziehung “gekochter” Elemente.
E-Mails: Sams Kommentar (#214) identifizierte serverseitiges Rendering als langfristige Lösung.