Mathjax: Сложный текстовый макет, в частности с вводом TeX [было: MathJax не поддерживает сложный текстовый макет.]

Обратите внимание, что если вы установите mtextFontInherit в true в разделах HTML-CSS и SVG вашей конфигурации, тогда MathJax будет обрабатывать \text{} как single <span> , и так должно быть по вашему запросу. Вы правы в том, что MathJax может работать лучше, когда mtextFontInherit равно false . Он должен группировать «неизвестные» символы в единую коллекцию, а не помещать каждого в отдельный <span> .

PS: я видел отчет о багзилле Викимедиа и планировал добавить его в список того, что нужно исправить. Спасибо, что посмотрели проблему здесь, чтобы отследить это.

Спасибо за совет mtextFontInherit. Я все равно собирался включить это, но это еще одна причина сделать это.

Некоторая поддержка RTL была добавлена ​​в версии 2.3, но проблема многосимвольных последовательностей, рассматриваемых как единое целое, остается. Для \text{} эти символы уже должны быть сгруппированы в один <span> , так что это будет один из способов справиться с этим, хотя и не очень удобно.

В идеале MathJax поместил бы каждую последовательность, образующую одну группу, в один <mi> или <mo> , как сейчас это делается для отдельных латинских букв. Я изучил это в некоторой степени, и есть некоторые трудности с этим. Можно сгруппировать комбинированные символы с предшествующими им символами, но мне непонятно, как работают некоторые символы. Например, кажется, что вирама (U+0D4D) сочетает в себе не только символ слева, но и справа, хотя я могу неправильно понять это. Также кажется, что некоторые из этих группировок обрабатываются лигатурами внутри шрифтов, а не комбинацией символов. К сожалению, MathJax не имеет доступа к информации о лигатурах шрифтов. Хотя было бы возможно добавить данные лигатуры в таблицы шрифтов MathJax, это может быть значительный объем данных, очень небольшая часть которых будет использоваться какой-либо одной страницей.

Я действительно недостаточно знаком с языками, использующими эти функции, чтобы понять, будет ли достаточно того, что я пытаюсь сделать. Мне интересно, можно ли получить несколько примеров из разных языков, которые показывают диапазон ситуаций, которые необходимо учитывать.

Один из подходов может состоять в том, чтобы поместить данные, необходимые для сценария каждого языка, в отдельное расширение, которое загружается для тех страниц, которым они нужны (либо явно в конфигурации MathJax, либо через \require{} в математике на странице). Как вы думаете, это было бы приемлемо?

Возможно , @amire80 из нашей языковой разработки WMF может немного помочь здесь...

@hartman , как ты думаешь, ты мог бы когда-нибудь ткнуть @amire80 ? Мы хотели бы улучшить это, особенно если Википедия хочет более широко использовать вывод SVG.

Я прямо здесь :)

Чем могу помочь?

Тестирование? - С удовольствием, только скажи мне, что именно проверить.

Примеры того, как нелатинские шрифты работают в формулах? - Он не используется в учебниках иврита, но используется в учебниках арабского и персидского языков. Может быть , @ebraminio сможет сюда вмешаться.

Что-нибудь еще?

Спасибо, что заглянули к @amire80 :-)

Чем могу помочь?

Я надеюсь, что мы сможем улучшить обработку комбинированных символов в нелатинских сценариях. Это неоднократно всплывало в WMF bugzilla/phabricator. Чтобы процитировать Давиде из https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717:

В идеале MathJax поместил бы каждую последовательность, формирующую одну группу, в одинили, так же, как и для одиночных латинских букв сейчас. Я изучил это в некоторой степени, и есть некоторые трудности с этим. Можно сгруппировать комбинированные символы с предшествующими им символами, но мне непонятно, как работают некоторые символы. Например, кажется, что вирама (U+0D4D) сочетает в себе не только символ слева, но и справа, хотя я могу неправильно понять это. Также кажется, что некоторые из этих группировок обрабатываются лигатурами внутри шрифтов, а не комбинацией символов. К сожалению, MathJax не имеет доступа к информации о лигатурах шрифтов. Хотя было бы возможно добавить данные лигатуры в таблицы шрифтов MathJax, это может быть значительный объем данных, очень небольшая часть которых будет использоваться какой-либо одной страницей.

Я действительно недостаточно знаком с языками, использующими эти функции, чтобы понять, будет ли достаточно того, что я пытаюсь сделать. Мне интересно, можно ли получить несколько примеров из разных языков, которые показывают диапазон ситуаций, которые необходимо учитывать.

Итак, наш вопрос: есть ли у кого-нибудь опыт, которым они могут поделиться с нами? @hartman был достаточно любезен, чтобы указать на вас ;-)

(Возможно, стоит выделить это в отдельную тему.)

(Самая) основная идея вирамы состоит в том, что последовательность согласная + вирама + согласная состоит из трех символов Unicode, которые занимают пространство одного глифа (но это может быть намного сложнее).

В целом, я хотел бы понять текущую ситуацию с MathJax. Что я должен сделать, чтобы протестировать текущий рендеринг? Установить мой собственный экземпляр? Или есть онлайн-экземпляр, где можно протестировать текущую версию?

согласная + вирама + согласная имеет три символа Unicode, которые появляются как занимающие пространство одного глифа

Верно. Комбинированные символы достаточно распространены в математической раскладке, поэтому мы понимаем ситуацию в целом.

(но это может быть намного сложнее).

Это наша проблема. Нам не хватает специфики для большинства естественных языков, нелатинских шрифтов.

Или есть онлайн-экземпляр, где можно протестировать текущую версию?

Вы можете сделать это на MediaWiki (используя режим MathML/SVG математического расширения), в браузере ( этот образец или этот codepen ) или использовать локальную копию MathJax — как вам больше нравится.

Простой пример: ത്ര будет преобразовано в ത്ര , и, поскольку у нас нет подпрограмм для идентификации таких комбинированных символов, ввод TeX преобразует это внутренне в MathML как

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mrow class="MJX-TeXAtom-ORD">
    <mo>&#xD24;</mo>
  </mrow>
  <mrow class="MJX-TeXAtom-ORD">
    <mo>&#xD4D;</mo>
  </mrow>
  <mrow class="MJX-TeXAtom-ORD">
    <mo>&#xD30;</mo>
  </mrow>
</math>

Который вывод MathJax, в свою очередь, будет разделен на три диапазона (в выходных данных HTML) или три g (в выходных данных SVG) - и, конечно, это нарушает рендеринг комбинированного символа.

(Я только что заметил, что Firefox иногда объединяет диапазоны в выходных данных HTML, например, ത്ര , но не нижний индекс в കു_ശ . Chrome более «последовательный» в том, что ничего не объединяется)

Итак, для нас проблема заключается в следующем: существует ли краткий набор данных (или какая-то эффективная эвристика), который мы могли бы использовать для определения всех соответствующих ситуаций, когда нам нужно повторно объединить в один элемент mi/mo в MathML? Как только мы получим это, рендеринг также будет работать.

Итак, для нас проблема заключается в следующем: существует ли краткий набор данных (или какая-то эффективная эвристика), который мы могли бы использовать для > идентификации всех соответствующих ситуаций, когда нам нужно повторно объединить в один элемент mi/mo в MathML?

Извините за длинный комментарий, возвращая немного обсуждения вне сайта в систему отслеживания проблем.

Насколько осуществимо/дорого было бы создать базу данных Unicode UCD
комбинированный класс, доступный для mathjax для каждого персонажа? В основном (или
по крайней мере, в хорошем первом приближении) любой символ с ненулевым
класс объединения (поле 4 в UnicodeData.txt) должен оставаться с
предшествующий, и, кроме того, если это класс 9 (вирама), следующий
характер тоже нужно держать вместе.

Вероятно, также стоит отметить, что tex, даже unicode tex, например xetex
или luatex почти наверняка _не_ сделают это правильно без
разметка
то есть вам понадобится \text{abc} или \mathit{abc} или что-то подобное
команда, чтобы заставить строку символов быть набранной как текст с
один шрифт, а не обычная привычка TeXа разделять вещи
персонаж за персонажем. Даже если конструкция _выглядит_ как единый
характер для автора.

В классическом тексте это не проблема, так как шрифты могут иметь только 256 символов.
и в то время как составные символы могут поддерживаться с помощью различных трюков переназначения макросов
составление символов, следующих за основой, в принципе не поддерживается даже для простых
составляя акценты, как острое.

Поддержка вариантов Unicode tex, таких как xetex и luatex, кажется немного изменчивой. В тексте xetex
передает вещи в библиотеку HarfBuzz, так что делает это довольно хорошо. luatex справляется с этим внутренне и в настоящее время хуже справляется с вирамой. В математике обоим требуется шрифт с таблицей MATH открытого типа, чтобы делать что-то очень полезное, и я не смог найти такой шрифт с вирамой.

В следующем латексном документе используется картика в тексте и латинская современная математика в математике, вы заметите, что
даже европейские акценты обычно терпят неудачу в математике, но даже пример с вирамой работает, если вы добавите некоторую разметку \mbox здесь или mi или mtext эквивалентно в MathML

Изображение показывает xetex вверху и luatex внизу.

Таким образом, хотя было бы желательно не требовать что-то вроде \text{..} или \mbox{...} вокруг таких строк символов, это поставило бы вашу поддержку Unicode далеко впереди того, что TeX может достичь в настоящее время.
так что это немного зависит от того, какова спецификация «текстоподобного синтаксиса», насколько далеко за пределы того, что может сделать TeX, разумно его продвигать?

\documentclass{article}

\usepackage{fontspec}
\usepackage{unicode-math}
\setmainfont{kartika.ttf}


\begin{document}

U+0d24 U+0d4d U+0d30 outputs e.g., ത്ര but 

abc $abc \mbox{ത്ര} $  U+0063

abç $abç \mbox{ത്ര} $ U+00e7

abç $abç \mbox{ത്ര} $  U+0063 U+0327

\end{document}

Я не совсем уверен, понимаю ли я, о чем идет речь, но если идея состоит в том, чтобы определить, какая последовательность символов составляет единое целое, то кластеризация графем Unicode должна предоставить необходимую информацию.

Да, то, что говорит @khaledhosny , кажется мне правильным, хотя я не очень разбираюсь в этом. Возможно , @santhoshtr может предоставить более подробную информацию.

Сантош, я думаю, что то, что @pkra написал тремя комментариями выше, лучше всего объясняет проблему.

3 марта 2015 г., в 12:05, Халед Хосни ( [email protected] ) написал:

Я не совсем уверен, понимаю ли я, о чем идет речь, но если
идея состоит в том, чтобы определить, какая последовательность символов составляет один
unit, затем кластеризация Unicode Grapheme
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries должен
предоставить необходимую информацию..

Да, но я полагаю, вопрос в том, насколько это имеет смысл для javascript
библиотека для этого
вручную, если базовая платформа не создает свойства юникода
доступный
и если он эмулирует синтаксис tex, как далеко зайдет tex? Вы знаете, как много
по поводу техподдержки кому как. Насколько разумно было бы в xetex
пусть такой кластер делает что-нибудь разумное в _math_ без перехода к тексту
с помощью \text{..} или какой-либо подобной команды, учитывая, что вы не можете назначить
\mathclass в такой кластер?

Я нашел реализацию CoffeeScript для графем.
https://github.com/devongovett/grapheme-break

Может быть полезно.

Спасибо за все полезные комментарии. Обобщить,

• xetex/luatex не обрабатывает ввод так, как требуется в этом выпуске, то есть без дополнительной разметки, такой как \text
• не ясно (мне по крайней мере), есть ли планы справиться с этим таким образом
• решение может начаться с простого подхода, описанного Дэвидом С., или, возможно, основываться на методе разрушения графем (спасибо, @hartman!)

Чтобы добавить к этому,

• С другой стороны, быстрый тест с LaTeXML и pandoc показывает, что они обрабатывают такие символы, как здесь запрошено, то есть не так, как xetex/luatex.

Поэтому мне кажется, что решение не может быть в основном вводе TeX, но должно быть расширением. Это не проблема, конечно, так как это, вероятно, все равно закончилось бы расширением.

Было бы хорошо получить известие от сообществ MediaWiki/WMF, если они действительно хотят здесь разграничить TeX-движки.

Опять же, было бы хорошо получить больше отзывов.

• Ребята из TeX, является ли обработка символов в математическом режиме без дополнительной разметки будущим направлением xetex/luatex/etc?
• Люди из MediaWiki/WMF: действительно ли нестандартное поведение TeX желательно для соответствующих сообществ?

Без дополнительной обратной связи, я думаю, мы должны сделать ставку на это / переместить его из контрольной точки 2.6.

Позвольте мне понять проблему здесь, люди хотят делать такие вещи, как $x+y=<complex character>$ , где <complex character> , возможно, является графемой с несколькими кодовыми точками, а <complex character> рассматривается как математический идентификатор, правильно ? Если это так, то я думаю, что это разумное ожидание, и если текущие механизмы Unicode TeX не обрабатывают его правильно (вероятно, они этого не делают), это, вероятно, ошибка или отсутствующая функция, а не что-то задуманное.

Или люди хотят делать такие вещи, как $<complex text string>$ , где <complex text string> — это многосимвольная текстовая строка, которая, возможно, требует сложного макета текста и получает правильный макет текста (биди, формирование и т. д.) ? Я не думаю, что это разумное ожидание, и здесь нужна какая-то разметка, чтобы указать, что это обычная текстовая строка, которую нужно рассматривать как таковую.

Спасибо, @khaledhosny!

[...] люди хотят делать что-то вроде $x+y=$ гдевозможно, является графемой с несколькими кодовыми точками и имеетрассматривается как математический идентификатор, верно?

Да я тоже так понимаю. (Немного сложно сказать, так как изначально это запрос из Википедии).

Я думаю, это разумное ожидание

Спасибо!

если текущие механизмы Unicode TeX не обрабатывают его правильно (вероятно, они этого не делают), это, вероятно, ошибка или отсутствующая функция, а не что-то задуманное.

Спасибо и за это. Часть «вероятно, нет» меня немного беспокоит, но если вы и @davidcarlisle согласны с тем, что это желаемое поведение в движках Unicode TeX, то, я думаю, для нас этого достаточно.

Все еще надеюсь, что сторона MediaWiki/WMF/Wikipedia вмешается.

Согласно F2F, мы удаляем это из вехи v2.6 (т. е. из предстоящего выпуска).

Непонятно, какой правильный подход, в частности, с точки зрения совместимости с TeX/LaTeX (точнее, XeTeX/LuaTeX). Также неясно, чего на самом деле хотят здесь WMF и сообщество Википедии.

Чтобы внести ясность, мы не закрываем этот вопрос и по-прежнему заинтересованы в выяснении того, как сложный макет может работать во входных данных TeX.

Взрыв из будущего: есть предложение TC39 «Сегментация Unicode», позволяющее (среди прочего) разбивать строки по графемам https://github.com/tc39/proposal-intl-segmenter. Репозиторий включает ссылку на полифилл (и, по-видимому, есть нестандартная функция Chrome).

Прохладный. Спасибо, @pkra.

Без проблем. Полифилл, к сожалению, бесполезен — он охватывает только Enligsh. Но для тех, кто хочет попробовать, встроенный хром может быть полезен.