Incluir Discourse-math cozido na visualização de impressão e e-mails

Funcionalidade
, ,
1

Problem
Discourse-math renders beautifully in the browser, but in contexts where JavaScript can’t run, math falls back to raw LaTeX source. Two high-impact cases:

  • Print view (/print or browser print-to-PDF): math shows as $...$ instead of rendered symbols.
  • Emails (digests, notifications, subscriptions): math is delivered raw, unreadable to recipients unless they copy-paste into a LaTeX editor.

This breaks important workflows for communities that rely on Discourse for technical content.

Why it matters

  • STEM educators and researchers often need to print topics or forward emails. If the math isn’t legible, those exports are unusable.
  • Other gaps in print/emails (spoilers, oneboxes, images) have been fixed — math is a glaring omission.
  • Supporting cooked math in non-JS contexts would make Discourse a first-class platform for technical communities.

Proposed solution

  • Lightweight step (print):
    • Ensure /print view includes cooked math HTML.
    • Trigger MathJax typesetting before print.
  • Heavier step (emails):
    • Explore server-side MathJax rendering, as Sam suggested.
    • Render math to SVG or pre-cooked HTML so recipients see legible equations directly in email clients.
  • Optional site setting:
    • “Use cooked math in print view/emails” → lets admins choose between raw source vs rendered math.

Related issues / prior work

  • :white_check_mark: Math inside [details] panes fixed (PR #111, June 2025).
  • :memo: Print view already had fixes for spoilers/oneboxes → precedent for including cooked elements.
  • :e_mail: Emails: Sam’s comment (#214) identified server-side render as the long-term solution.

Summary / TL;DR
Right now, math in print view and emails falls back to raw LaTeX. Adding cooked math rendering would make PDFs and digests readable, professional, and consistent with what users see in the browser.

Reproduce on Discourse with iOS Safari

Even when Request Desktop Site is enabled in Safari, Discourse still appends
?mobile_view=1 when opening /print, which forces the stripped-down mobile print view.

Workaround: manually change to ?mobile_view=0 for the full desktop print layout.

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

3 curtidas