Wzory matematyczne w wiadomościach e-mail

Czy istnieje sposób na wprowadzenie formuł LaTeX (lub podobnych) do wiadomości e-mail i renderowanie ich jako formuł składu po stronie odbierającej, być może przy współpracy strony odbierającej? Moim preferowanym klientem pocztowym jest Thunderbird, ale rozwiązania dla innych aplikacji również mogą być interesujące, a rozwiązania przenośne oczywiście najlepiej by działały.

Rzeczy, na które mam nadzieję, ale do tej pory nie mogłem znaleźć:

• Sposób odwoływania się do plików JavaScript MathJax z wiadomości e-mail HTML, wraz z konfiguracją po stronie klienta, która umożliwia wykonanie tego konkretnego JavaScript bez otwierania zbyt dużej luki w zabezpieczeniach.
• Niektóre dodatki, które umożliwiają MathJax po stronie odbierającej, bez konkretnego odniesienia do niego w wiadomości e-mail. Może to działać nawet w przypadku zwykłych wiadomości tekstowych, co jest dobrą rzeczą.
• Niektóre dodatki, które pozwalają użytkownikowi wprowadzić gdzieś kod LaTeX i które osadzają odpowiedni MathML w wiadomości w formacie HTML.
• Niektóre dodatki, które pozwalają mi zaznaczyć część mojej wiadomości przed kliknięciem przycisku. Zaznaczony tekst należy interpretować jako LaTeX i zastąpić go odpowiednim MathML. Oczywiście będzie to działać tylko w przypadku wiadomości w formacie HTML.

Jestem zainteresowany wszelkimi znanymi procedurami opisanymi powyżej. W przypadkach, gdy nie jest to od razu oczywiste, informacja o tym, które aplikacje po stronie wysyłającej, jak i po stronie przyjmującej popierają to podejście, byłaby mile widziana. Na przykład słyszałem, że zarówno Thunderbird, jak i Apple Mail będą obsługiwać MathML dla otrzymanych wiadomości e-mail, ale Outlook nie. Przynajmniej część dotyczącą renderowania formuły przez Thunderbirda, którą mogę potwierdzić.

Ta funkcja jest dostępna w Thunderbird w wersji 31.6.0

• Otwórz nową Napisz wiadomość
• „Wstaw”> „Wzór matematyczny”
• Wprowadź formułę
• kliknij „Wstaw”.

O ile mi wiadomo, obecnie nic nie robi tego, co chcesz.

Umieszczenie javascript w wiadomości e-mail byłoby ogólnie złym pomysłem, ale bookmarklet MathJax może pomóc klientom internetowym. Możesz użyć go na swoim kliencie internetowym przed wysłaniem wiadomości e-mail, ale nie sugerowałbym tego - rendering MathJax zależy od przeglądarki, więc często będzie to działać po stronie odbiorcy; utrudni to również ponowne wykorzystanie treści matematycznych.

Myślę, że MathML stanie się w przyszłości wybranym formatem wymiany (mam nadzieję, że dzięki wbudowanym źródłom danych, takim jak LaTeX, będzie można kontynuować tworzenie). Wiele edytorów równań produkuje MathML, ale te z wejściami LaTeX i MathML są rzadkie.

Ostatni post Frederica Wanga na blogu jest prawdopodobnie najlepszym (jedynym?) Źródłem, jeśli chodzi o obsługę MathML w klientach e-mail - w szczególności komentarz 5 . Fred jest współtwórcą implementacji MathML w Firefoksie i jest częścią zespołu MathJax (zrzeczenie się odpowiedzialności: ja jestem).

Problem praktyczny polega na znalezieniu równowagi między dobrym doświadczeniem dla współpracującej strony przyjmującej, a nie całkowitą awarią dla stron niewspółpracujących. Pamiętaj, że e-maile mogą być przechowywane przez wiele lat, czytane przez wiele programów i przekazywane innym osobom.

• Obecnie uważam, że TeX dla Gmaila robi to najlepiej - w szczególności pozwala renderować formuły zwykłego tekstu, takie jak, $2^n$a nawet (heurystycznie) 2^nw przychodzącej poczcie, co jest świetne podczas połączenia z osobą korzystającą z innego oprogramowania.

• Markdown Tutaj nie jest tak elastyczny pod względem matematycznym, ale także inne formatowanie Markdown i działa w wielu innych miejscach.

• Ten formularz na stronie Murraya Bourne'a IntMath wymaga wysłania z niego zamiast zwykłego klienta poczty i używa ASCIIMathML zamiast notacji TeX (łatwiej, ale ma przyjemną funkcję pozwalającą odbiorcy zobaczyć pocztę w przeglądarce - i tam odpowiedzieć .

Na poziomie technicznym jedynym sposobem wyświetlania szerokiej gamy formuł dla dowolnego klienta (z wyjątkiem czystego tekstu) wydają się być obrazy PNG. Prawidłowe postępowanie powinno obejmować:

• alt cofanie tekstu.
• osadzanie obrazu w poczcie, dzięki czemu jest niezależny i nie zależy od zewnętrznych serwerów. URI danych mają złą obsługę, wieloczęściową ze cid:znacznie lepszą (patrz komentarze tam).
• używając obrazu o wysokiej rozdzielczości, który nie wygląda okropnie na ekranie o wysokiej DPI.
• ustawienie wysokości, szerokości i wyrównania w pionie w exjednostkach. To powinno być w stanie dopasować rozmiar i odniesienia do otaczającego tekstu.

Sprawienie, by wszystkie powyższe działania działały na różnych klientach, jest trudne ... Na przykład zobacz Problemy Markdown .

Istnieje wiele lepszych sposobów renderowania matematyki niż PNG. Problem z nimi wszystkimi polega na tym, jak wrócić do obrazu (a nawet tekstu), gdy nie działają?

• Niektóre proste podzbiory matematyki można dobrze renderować za pomocą Unicode + HTML + CSS. Rzeczywiście TeX dla Gmaila ma taki tryb. KaTeX podniósł poprzeczkę w zakresie renderowania czystego CSS wysokiej jakości, z tym że opiera się na interfejsach WWW, które nie działają w prawie klienckim programie pocztowym. MathJax 2.5 ma tryb „CommonHTML”, który obecnie używa CSS + HTML bez nawet stron internetowych, ale wygląda brzydko (planują zacząć używać stron internetowych, aby uczynić ładniejszym) ...

  W każdym razie CSS w klientach e-mail jest daleko w tyle za przeglądarkami i jest przerażająco nierówny , więc złożone układy matematyczne nie będą działać.

• MathML jest świetną i semantycznie właściwą rzeczą, a nawet działa u niektórych klientów; niestety powrót do obrazów wydaje się trudny. Z oficjalnych mechanizmów awaryjnych nawet Chrome dostał tylko połowę w 2014 roku (dzięki Fred Wand), więc czego można oczekiwać od klientów e-mail?

• OK MathML jest złożonym i niszowym formatem, ale z pewnością SVG powinien być nietrudny po ~ 15 latach istnienia? Niestety, obsługa SVG przez pocztę e-mail jest bardzo smutna (np. Gmail ostatnio zrezygnował z obsługi, nawet tekstu alternatywnego), a znane techniki zastępcze bez javascript nie działają w wiadomościach e-mail. (Nie uważam testowania rozdzielczości ekranu == iPhone | iPad za akceptowalną technikę ...)

Najczystsze techniki zastępcze polegają na ignorowaniu przez klientów tagów, których nie rozumieją; niestety cicho, niektóre (pocztowe) klienty poczty akceptują tylko białą listę tagów i całkowicie upuszczają rzeczy takie jak <math>...<img .../>...</math>zamiast renderowania img...

Jeśli chodzi o robienie tych bez cofania się, więc odbiorca nie może w ogóle czytać matematyki bez odpowiedniego narzędzia - jest to trudne wezwanie (w porównaniu do PNG, które jest brzydsze, ale działa), ale może być do zaakceptowania.
[W rzeczywistości zawsze istnieje możliwość włączenia zastępczego tekstu / zwykłego. Nie wszyscy odbierający go udostępniają, a rozpoczęcie wiadomości od „Nie widzisz matematyki? Szukaj„ Pokaż oryginał ”w swoim kliencie e-mail” byłoby kiepskim doświadczeniem ...
Jednak to, co robi system IntMath z „kliknij tutaj, aby przeczytać ( i odpowiedz ) jako strona internetowa ”jest bardzo dobra.]

Co z tym dodatkiem zwanym równaniami?

Zobacz: https://addons.mozilla.org/en-US/thunderbird/addon/equations/