在打印视图和电子邮件中包含已发布的 Discourse-math

功能
, ,
2

是的，我认为 Sam 的总结很准确：如果我们希望电子邮件/打印视图显示渲染后的数学公式，我们需要服务器端数学渲染（或至少是服务器端“预渲染”），因为电子邮件客户端不会运行 MathJax。

一个现实的方法是：

  • 在编译（cooking）期间（或编译后在后台作业中），查找数学跨度（行内 + 显示）。
  • 使用 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 的地方使用 MathML）。

如果有人想快速进行实验，我首先会做的实验是：

  1. 一个使用 mathjax-full 的微型 Node 脚本，将 $begin:math:text$E\\=mc\\^2$end:math:text$ 渲染为 SVG，
  2. 查看它做出了哪些假设（DOM 与适配器），
  3. 然后决定 MiniRacer 是否是死胡同，我们应该将其视为“需要 Node 可用”（或一个小型服务）。

如果该实验成功，我们就可以讨论它插入的位置（电子邮件管道与编译与打印视图），以及我们缓存/存储的内容。