تضمين Discourse-math المطبوخ في عرض الطباعة ورسائل البريد الإلكتروني

نعم، أعتقد أن ملخص سام دقيق: إذا أردنا أن تعرض رسائل البريد الإلكتروني / عرض الطباعة الرياضيات معروضة، فنحن بحاجة إلى عرض الرياضيات من جانب الخادم (أو على الأقل “العرض المسبق” من جانب الخادم)، لأن عملاء البريد الإلكتروني لن يقوموا بتشغيل MathJax.

النهج الواقعي سيكون:

  • أثناء الطهي (أو في مهمة خلفية بعد الطهي)، ابحث عن نطاقات الرياضيات (المضمنة + المعروضة).
  • اعرض كل تعبير إلى SVG (أو MathML كحل بديل) باستخدام MathJax في بيئة Node.
  • استبدل الرياضيات في HTML المطبوخ المستخدم للبريد الإلكتروني/الطباعة بأحد ما يلي:
    • \u003csvg ...\u003e مضمن (أفضل دقة، لا يوجد استدعاء خارجي)، أو
    • \u003cimg src=\"data:image/svg+xml;base64,...\"\u003e (أكثر توافقًا لبعض العملاء، ولكنه قد يصبح كبيرًا).
  • التخزين المؤقت بواسطة مفتاح ثابت (على سبيل المثال 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” (أو خدمة صغيرة).

إذا نجح هذا الاختبار، فيمكننا التحدث عن مكان توصيله (مسار البريد الإلكتروني مقابل الطهي مقابل عرض الطباعة)، وما نقوم بتخزينه مؤقتًا/تخزينه.