Включить обработанный Discourse-math в печатный вид и письма

Внести вклад Функция
, ,
1

Проблема
Discourse-math отлично отображается в браузере, но в контекстах, где JavaScript не может выполняться, математика возвращается к исходному коду LaTeX. Два высокоприоритетных случая:

  • Печать (/print или печать в PDF через браузер): математика отображается как $...$ вместо отрисованных символов.
  • Электронные письма (дайджесты, уведомления, подписки): математика доставляется в исходном виде и нечитаема для получателей, если они не копируют и не вставляют её в редактор LaTeX.

Это нарушает важные рабочие процессы для сообществ, полагающихся на Discourse для технической документации.

Почему это важно

  • Преподаватели и исследователи в области STEM часто нуждаются в печати тем или пересылке писем. Если математика нечитаема, такие экспорты становятся бесполезными.
  • Другие пробелы в печати/письмах (спойлеры, oneboxes, изображения) уже исправлены — отсутствие поддержки математики является очевидным упущением.
  • Поддержка обработанной математики в контекстах без JavaScript сделала бы Discourse платформой первого класса для технических сообществ.

Предлагаемое решение

  • Лёгкий шаг (печать):
    • Обеспечить, чтобы вид /print включал обработанный HTML-код математики.
    • Запускать типовую обработку MathJax перед печатью.
  • Более сложный шаг (электронные письма):
    • Изучить серверную отрисовку MathJax, как предложил Сэм.
    • Отрисовывать математику в SVG или предварительно обработанный HTML, чтобы получатели видели читаемые формулы непосредственно в почтовых клиентах.
  • Опциональная настройка сайта:
    • «Использовать обработанную математику в виде для печати/письмах» → позволяет администраторам выбирать между исходным кодом и отрисованной математикой.

Связанные задачи / предшествующая работа

  • :white_check_mark: Исправлена математика внутри панелей [details] (PR #111, июнь 2025).
  • :memo: В виде для печати уже были исправления для спойлеров и oneboxes → это служит прецедентом для включения обработанных элементов.
  • :e_mail: Электронные письма: комментарий Сэма (#214) определил серверную отрисовку как долгосрочное решение.

Резюме / TL;DR
В настоящее время математика в виде для печати и в письмах возвращается к исходному коду LaTeX. Добавление отрисовки обработанной математики сделало бы PDF-файлы и дайджесты читаемыми, профессиональными и согласованными с тем, что пользователи видят в браузере.

Воспроизвести в Discourse с iOS Safari

Даже при включённой опции Запросить версию для ПК в Safari, Discourse всё равно добавляет
?mobile_view=1 при открытии /print, что принудительно включает упрощённую мобильную версию для печати.

Обходной путь: вручную изменить на ?mobile_view=0 для получения полной версии для печати с макетом для ПК.

Пример
/t/fw-the-email-subject/12345/print?mobile_view=0

3 лайка
2

Да, я думаю, что резюме Сэма точное: если мы хотим, чтобы в письмах и печатных версиях отображалась отрендеренная математика, нам необходим серверный рендеринг формул (или хотя бы серверное «предварительное рендерирование»), поскольку почтовые клиенты не запускают MathJax.

Реалистичный подход был бы следующим:

  • Во время обработки (или в фоновой задаче после неё) найти все теги с математикой (строчные и блочные).
  • Отрендерить каждое выражение в SVG (или MathML в качестве запасного варианта), используя MathJax в среде Node.
  • Заменить математику в обработанном 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. Написать крошечный скрипт на Node с использованием mathjax-full для рендеринга $begin:math:text$E\=mc\^2$end:math:text$ в SVG,
  2. Проверить, какие допущения он делает (DOM или адаптер),
  3. Затем решить, является ли MiniRacer тупиковым вариантом, и нужно ли нам требовать наличия Node (или создать небольшой сервис).

Если эксперимент увенчается успехом, мы обсудим, куда именно это интегрировать (пайплайн писем, обработка или печатная версия), и что будем кэшировать/хранить.