Inclure Discourse-math cuit dans la vue d'impression et les e-mails

Fonctionnalité
, ,
1

Problème
Discourse-math s’affiche magnifiquement dans le navigateur, mais dans les contextes où JavaScript ne peut pas s’exécuter, les mathématiques reviennent à la source LaTeX brute. Deux cas à fort impact :

  • Vue d’impression (/print ou impression du navigateur en PDF) : les mathématiques s’affichent comme $...$ au lieu de symboles rendus.
  • E-mails (résumés, notifications, abonnements) : les mathématiques sont livrées brutes, illisibles pour les destinataires, à moins qu’ils ne les copient-collent dans un éditeur LaTeX.

Cela perturbe des flux de travail importants pour les communautés qui s’appuient sur Discourse pour le contenu technique.

Pourquoi c’est important

  • Les éducateurs et chercheurs en STEM ont souvent besoin d’imprimer des sujets ou de transférer des e-mails. Si les mathématiques ne sont pas lisibles, ces exportations sont inutilisables.
  • D’autres lacunes dans l’impression/les e-mails (spoilers, oneboxes, images) ont été corrigées — les mathématiques sont une omission flagrante.
  • La prise en charge des mathématiques cuites dans les contextes sans JS ferait de Discourse une plateforme de premier plan pour les communautés techniques.

Solution proposée

  • Étape légère (impression) :
    • Assurez-vous que la vue /print inclut le HTML des mathématiques cuites.
    • Déclenchez la composition MathJax avant l’impression.
  • Étape plus lourde (e-mails) :
    • Explorez le rendu MathJax côté serveur, comme suggéré par Sam.
    • Rendez les mathématiques en SVG ou en HTML pré-cuit afin que les destinataires voient des équations lisibles directement dans les clients de messagerie.
  • Paramètre de site optionnel :
    • « Utiliser les mathématiques cuites dans la vue d’impression/les e-mails » → permet aux administrateurs de choisir entre la source brute et les mathématiques rendues.

Problèmes connexes / travaux antérieurs

  • :white_check_mark: Les mathématiques à l’intérieur des volets [details] ont été corrigées (PR #111, juin 2025).
  • :memo: La vue d’impression avait déjà des corrections pour les spoilers/oneboxes → précédent pour inclure des éléments cuits.
  • :e_mail: E-mails : le commentaire de Sam (#214) a identifié le rendu côté serveur comme la solution à long terme.

Résumé / TL;DR
Actuellement, les mathématiques dans la vue d’impression et les e-mails reviennent à LaTeX brut. L’ajout du rendu des mathématiques cuites rendrait les PDF et les résumés lisibles, professionnels et cohérents avec ce que les utilisateurs voient dans le navigateur.

Reproduire sur Discourse avec Safari sur iOS

Même lorsque Demander le site de bureau est activé dans Safari, Discourse ajoute toujours
?mobile_view=1 lors de l’ouverture de /print, ce qui force la vue d’impression mobile simplifiée.

Solution de contournement : changer manuellement en ?mobile_view=0 pour la mise en page d’impression de bureau complète.

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

3 « J'aime »
2

Oui, je pense que le résumé de Sam est exact : si nous voulons que les e-mails / la vue d’impression affichent les maths rendues, nous avons besoin d’un rendu des maths côté serveur (ou au moins d’un « pré-rendu » côté serveur), car les clients de messagerie n’exécuteront pas MathJax.

Une approche réaliste serait :

  • Pendant la cuisson (ou dans un travail d’arrière-plan après la cuisson), trouver les spans mathématiques (en ligne + affichage).
  • Rendre chaque expression en SVG (ou MathML en secours) en utilisant MathJax dans un environnement Node.
  • Remplacer les maths dans le HTML cuit utilisé pour les e-mails/l’impression par :
    • \u003csvg ...\u003e en ligne (meilleure fidélité, pas de récupération externe), ou
    • \u003cimg src=\"data:image/svg+xml;base64,...\"\u003e (plus compatible pour certains clients, mais peut devenir volumineux).
  • Mettre en cache avec une clé stable (par exemple, sha256(latex + display_mode + macros + font_config)), afin de ne rendre qu’une seule fois par formule unique.

Les points délicats (mais gérables s’ils sont délimités avec soin) :

  • Simulation de DOM : La sortie « navigateur » de MathJax veut un DOM ; nous aurions donc probablement besoin de mathjax-full + jsdom (ou d’utiliser la voie de l’adaptateur pur).
  • Performance / délais d’attente : le faire de manière asynchrone dans une file d’attente de tâches et dégrader gracieusement (laisser le LaTeX tel quel si le rendu échoue).
  • Particularités des clients de messagerie : certains clients suppriment les SVG ; avoir un plan de secours est donc important (par exemple, texte brut/LaTeX, ou MathML là où il est pris en charge).

Si quelqu’un souhaite faire un essai rapide, la première expérience que je ferais serait :

  1. Un tout petit script Node utilisant mathjax-full pour rendre $begin:math:text$E\\=mc\\^2$end:math:text$ en SVG,
  2. Voir quelles hypothèses il fait (DOM vs adaptateur),
  3. Décider ensuite si MiniRacer est une impasse et si nous devons traiter cela comme « nécessite Node disponible » (ou un petit service).

Si cet essai fonctionne, nous pourrons discuter de l’endroit où il s’intègre (pipeline d’e-mail vs cuisson vs vue d’impression), et de ce que nous mettons en cache/stockons.