印刷ビューとメールに調理済みのDiscourse-mathを含める

問題
Discourse-math はブラウザでは美しくレンダリングされますが、JavaScript が実行できないコンテキストでは、数式は生の LaTeX ソースにフォールバックします。影響の大きい 2 つのケース:

  • 印刷ビュー (/print またはブラウザの印刷から PDF へ): 数式はレンダリングされた記号の代わりに $...$ として表示されます。
  • メール (ダイジェスト、通知、購読): 数式は生のまま配信され、受信者が LaTeX エディタにコピー&ペーストしない限り読めません。

これにより、Discourse を技術コンテンツのコミュニティに依存しているワークフローが中断されます。


なぜ重要か

  • STEM 教育者や研究者は、トピックを印刷したり、メールを転送したりする必要があることがよくあります。数式が判読できない場合、それらのエクスポートは使用できません。
  • 印刷/メールでのその他のギャップ (スポイラー、onebox、画像) は修正されました。数式は明白な欠落です。
  • 非 JS コンテキストでの調理済み数式のサポートは、Discourse を技術コミュニティにとってファーストクラスのプラットフォームにするでしょう。

提案される解決策

  • 軽量ステップ (印刷):
    • /print ビューに調理済み数式 HTML が含まれるようにします。
    • 印刷前に MathJax の組版をトリガーします。
  • 重いステップ (メール):
    • サーバーサイドの MathJax レンダリングを検討します。Sam が提案したように。
    • 数式を SVG または事前調理済みの HTML にレンダリングして、受信者がメールクライアントで直接読める方程式を見られるようにします。
  • オプションのサイト設定:
    • 「印刷ビュー/メールで調理済み数式を使用」→ 管理者が生のソースとレンダリングされた数式のどちらかを選択できるようにします。

関連する問題 / 事前作業

  • :white_check_mark: [details] ペイン内の数式は修正されました (PR #111、2025 年 6 月)。
  • :memo: 印刷ビューには、スポイラー/onebox の修正が既にありました → 調理済み要素を含めるための前例。
  • :e_mail: メール: Sam のコメント (#214) は、サーバーサイドレンダリングを長期的な解決策として特定しました。

概要 / TL;DR
現在、印刷ビューとメールの数式は生の LaTeX にフォールバックします。調理済み数式レンダリングを追加すると、PDF とダイジェストが読める、プロフェッショナルで、ユーザーがブラウザで表示するものと一貫性のあるものになります。

iOS Safari を使用した Discourse で再現する

Safari で デスクトップサイトをリクエスト が有効になっていても、Discourse は /print を開くときに ?mobile_view=1 を追加し、これは簡略化されたモバイル印刷ビューを強制します。

回避策: デスクトップ印刷レイアウト全体を表示するには、手動で ?mobile_view=0 に変更します。


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

「いいね!」 3

ええ、Samの要約は的を射ていると思います。メール/印刷ビューでレンダリングされた数式を表示したい場合、メールクライアントはMathJaxを実行しないため、サーバーサイドの数式レンダリング(または少なくともサーバーサイドの「プリレンダリング」)が必要です。

現実的なアプローチは次のようになります。

  • クッキング中(またはクッキング後のバックグラウンドジョブで)、数式のスパン(インライン+ディスプレイ)を見つけます。
  • MathJaxを使用して、Node環境で各式をSVG(フォールバックとしてMathML)にレンダリングします。
  • メール/印刷に使用されるクック済みHTML内の数式を次のいずれかに置き換えます。
    • インラインの<svg ...>(最高の忠実度、外部フェッチなし)、または
    • <img src="data:image/svg+xml;base64,...">(一部のクライアントにより互換性があるが、大きくなる可能性がある)。
  • 安定したキー(例:sha256(latex + display_mode + macros + font_config))でキャッシュし、一意の数式ごとに一度だけレンダリングします。

トリッキーな点(ただし、慎重にスコープを設定すれば管理可能):

  • DOMシミュレーション: MathJaxの「ブラウザ」出力はDOMを必要とします。そのため、mathjax-full + jsdom(または純粋なアダプタールートを使用)が必要になるでしょう。
  • パフォーマンス/タイムアウト: ジョブキューで非同期的に実行し、優雅にデグレードします(レンダリングが失敗した場合はLaTeXをそのまま残す)。
  • メールクライアントの癖: 一部のクライアントはSVGを削除します。そのため、フォールバックプラン(例:プレーンテキスト/LaTeX、またはサポートされている場合はMathML)を持つことが重要です。

誰かが簡単なテスト(スパイク)をしたい場合、最初に行う実験は次のとおりです。

  1. mathjax-fullを使用して$begin:math:text$E\\=mc\\^2$end:math:text$をSVGにレンダリングする小さなNodeスクリプト
  2. それがどのような仮定をしているかを確認する(DOM対アダプター)
  3. その後、MiniRacerがデッドエンドであり、これを「Nodeが利用可能である必要がある」こと(または小さなサービス)として扱うべきかどうかを判断します。

そのスパイクが成功した場合、それがどこにプラグインするか(メールパイプライン対クッキング対印刷ビュー)、および何をキャッシュ/保存するかについて話し合うことができます。