Mathjax: 복잡한 텍스트 레이아웃, 특히 TeX 입력 [이전: MathJax는 복잡한 텍스트 레이아웃을 지원하지 않습니다.]

구성의 HTML-CSS 및 SVG 섹션에서 mtextFontInherit 를 true 로 설정하면 MathJax는 \text{} 를 단일 <span> , 그래서 그것은 당신이 요청한대로 할 것입니다. mtextFontInherit 가 false 일 때 MathJax가 더 잘할 수 있다는 것이 맞습니다. "알 수 없는" 문자를 별도의 <span> 에 넣지 않고 단일 컬렉션으로 그룹화해야 합니다.

추신, 저는 Wikimedia bugzilla 에 대한 보고서를 보고 수정할 사항 목록에 추가할 계획이었습니다. 문제를 추적하기 위해 여기에서 문제를 찾아주셔서 감사합니다.

mtextFontInherit 팁 감사합니다. 나는 어쨌든 그것을 활성화할 예정이었지만, 이것이 그렇게 해야 하는 또 하나의 이유입니다.

RTL에 대한 일부 지원이 v2.3에 추가되었지만 여러 문자 시퀀스가 ​​하나의 단위로 취급되는 문제가 남아 있습니다. \text{} 의 경우 이러한 문자는 이미 단일 <span> 로 그룹화되어 있어야 처리할 수 있지만 그다지 편리하지는 않습니다.

이상적으로 MathJax는 단일 라틴 문자에 대해 수행하는 것처럼 하나의 그룹을 형성하는 각 시퀀스를 단일 <mi> 또는 <mo> 에 넣습니다. 나는 이것을 어느 정도 조사했고 그것을 처리하는 데 약간의 어려움이 있습니다. 결합 문자를 이전 문자와 그룹화하는 것이 가능하지만 일부 문자가 어떻게 작동하는지 명확하지 않습니다. 예를 들어 virama(U+0D4D)는 왼쪽 캐릭터 뿐만 아니라 오른쪽 캐릭터도 합체한 것 같은데 제가 잘못 이해하고 있는 것 같습니다. 또한 이러한 그룹화 중 일부는 문자를 결합하는 것이 아니라 글꼴 내의 합자에 의해 처리되는 것 같습니다. 불행히도 MathJax는 글꼴의 합자 정보에 액세스할 수 없습니다. MathJax의 글꼴 테이블에 합자 데이터를 추가하는 것이 가능하지만 이는 한 페이지에서 거의 사용되지 않는 상당한 양의 데이터일 수 있습니다.

나는 내가 시도하고 있는 것이 충분한지 아닌지를 알기 위해 이러한 기능을 사용하는 언어에 대해 충분히 익숙하지 않습니다. 수용해야 하는 상황의 범위를 보여주는 다양한 언어에서 몇 가지 예를 얻을 수 있는지 궁금합니다.

한 가지 접근 방식은 각 언어의 스크립트에 필요한 데이터를 필요한 페이지에 대해 로드되는 개별 확장에 넣는 것입니다(MathJax 구성에서 명시적으로 또는 페이지의 수학 내에서 \require{} 를 통해). 그것이 받아들여질 것이라고 생각합니까?

아마도 WMF 언어 엔지니어링의 @amire80 이 여기에서 약간의 도움을 줄 수 있을 것입니다...

@hartman @amire80 을 찔러볼 수 있을까요? 특히 Wikipedia에서 SVG 출력을 더 광범위하게 출시하려는 경우 이를 개선하고 싶습니다.

나 여기 있어요 :)

내가 어떻게 도움이 될 수 있습니다?

테스트? - 정확히 무엇을 테스트해야 하는지 알려주세요.

비 라틴 문자가 수식에서 작동하는 방식의 예는 무엇입니까? - 히브리어 교과서에서는 사용하지 않지만 아랍어, 페르시아어 교과서에서는 사용합니다. @ebraminio 가 여기에 끼어들 수도 있습니다.

다른 건 없나요?

@amire80 에 들러주셔서 감사합니다 :-)

내가 어떻게 도움이 될 수 있습니다?

라틴어가 아닌 스크립트에서 결합된 문자의 처리를 개선할 수 있기를 바랍니다. 이것은 WMF bugzilla/phabricator에 반복적으로 나타났습니다. https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717에서 Davide를 인용하려면 :

이상적으로 MathJax는 하나의 그룹을 형성하는 각 시퀀스를 단일또는, 지금 단일 라틴 문자에 대해 수행하는 것처럼. 나는 이것을 어느 정도 조사했고 그것을 처리하는 데 약간의 어려움이 있습니다. 결합 문자를 이전 문자와 그룹화하는 것이 가능하지만 일부 문자가 어떻게 작동하는지 명확하지 않습니다. 예를 들어 virama(U+0D4D)는 왼쪽 캐릭터 뿐만 아니라 오른쪽 캐릭터도 합체한 것 같은데 제가 잘못 이해하고 있는 것 같습니다. 또한 이러한 그룹화 중 일부는 문자를 결합하는 것이 아니라 글꼴 내의 합자에 의해 처리되는 것 같습니다. 불행히도 MathJax는 글꼴의 합자 정보에 액세스할 수 없습니다. MathJax의 글꼴 테이블에 합자 데이터를 추가하는 것이 가능하지만 이는 한 페이지에서 거의 사용되지 않는 상당한 양의 데이터일 수 있습니다.

나는 내가 시도하고 있는 것이 충분한지 아닌지를 알기 위해 이러한 기능을 사용하는 언어에 대해 충분히 익숙하지 않습니다. 수용해야 하는 상황의 범위를 보여주는 다양한 언어에서 몇 가지 예를 얻을 수 있는지 궁금합니다.

따라서 우리의 질문은 다음과 같습니다. 우리와 공유할 수 있는 전문 지식이 있는 사람이 있습니까? @hartman 이 친절하게 안내해 주셨어요 ;-)

(아마도 우리는 이것을 별도의 문제로 분리해야 할 것입니다.)

virama의 (매우) 기본적인 아이디어는 자음 + virama + 자음의 시퀀스에 3개의 유니코드 문자가 있다는 것입니다. 이 문자는 하나의 글리프 공간을 차지하는 것처럼 보이지만 훨씬 더 복잡해질 수 있습니다.

더 일반적으로 MathJax의 현재 상황을 이해하고 싶습니다. 현재 렌더링을 테스트하려면 어떻게 해야 합니까? 내 인스턴스를 설치하시겠습니까? 아니면 현재 버전을 테스트할 수 있는 온라인 인스턴스가 있습니까?

consonant + virama + consonant에는 3개의 유니코드 문자가 있으며 한 글리프의 공간을 차지하는 것으로 나타납니다.

오른쪽. 결합된 문자는 수학적 레이아웃에서 충분히 일반적이므로 일반적으로 상황을 이해합니다.

(하지만 훨씬 더 복잡해질 수 있습니다.)

그것이 우리의 문제입니다. 우리는 대부분의 자연어, 비 라틴 문자에 대한 세부 사항이 부족합니다.

아니면 현재 버전을 테스트할 수 있는 온라인 인스턴스가 있습니까?

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 출력은 차례로 3개의 범위(HTML 출력에서) 또는 3개의 g(SVG 출력에서)로 분할됩니다. 물론 이것은 결합된 문자의 렌더링을 중단합니다.

(방금 Firefox가 때때로 HTML 출력의 범위를 결합한다는 것을 알았습니다. 예: ത്ര 하지만 കു_ശ 의 첨자는 아닙니다. Chrome은 아무 것도 결합되지 않는다는 점에서 더 "일관적"입니다)

따라서 문제는 다음과 같습니다. MathML에서 하나의 mi/mo 요소로 다시 결합해야 하는 모든 관련 상황을 식별하는 데 사용할 수 있는 간결한 데이터 세트(또는 효율적인 휴리스틱)가 있습니까? 일단 그것이 있으면 렌더링도 작동합니다.

따라서 우리에게 문제는 다음과 같습니다. MathML에서 하나의 mi/mo 요소로 다시 결합해야 하는 모든 관련 상황을 식별하는 데 사용할 수 있는 간결한 데이터 세트(또는 효율적인 휴리스틱)가 있습니까?

긴 논평을 해서 죄송합니다. 문제 추적기에 약간의 오프사이트 토론을 가져왔습니다.

유니코드 UCD 데이터베이스를 만드는 것이 얼마나 실현 가능하거나 비용이 많이 듭니까?
각 문자에 대해 Mathjax에서 사용할 수 있는 결합 클래스? 기본적으로(또는
적어도 좋은 첫 번째 근사치로) 0이 아닌 모든 문자
결합 클래스(UnicodeData.txt의 필드 4)는
앞의 것, 그리고 추가로 클래스 9(virama)인 경우 다음
캐릭터도 함께 유지해야 합니다.

tex는 물론 xetex와 같은 유니코드 tex도 주목할 가치가 있습니다.
또는 luatex는 없이는 이것을 바로잡을 _아님_
마크업
즉, \text{abc} 또는 \mathit{abc} 또는 이와 같은 다른 것이 필요합니다.
문자열을 텍스트로 조판하는 명령
TeX의 일반적인 분할 습관이 아닌 단일 글꼴
캐릭터별로. 구조가 단일처럼 _보여도_
작가에게 캐릭터.

클래식 텍스에서는 글꼴이 256자만 가질 수 있으므로 문제가 되지 않습니다.
다양한 매크로 재매핑 트릭으로 구성된 문자를 지원할 수 있습니다.
기본에 따라 문자를 구성하는 것은 기본적으로 간단한 경우에도 지원되지 않습니다.
예리한 악센트를 구성합니다.

xetex 및 luatex와 같은 유니코드 tex 변형 지원은 약간 가변적입니다. 텍스트에서 xetex
HarfBuzz 라이브러리에 물건을 넘기므로 꽤 잘 작동합니다. luatex는 내부적으로 이를 처리하며 현재 virama에서는 잘 작동하지 않습니다. 수학에서 둘 다 매우 유용한 작업을 수행하기 위해 개방형 MATH 테이블이 있는 글꼴이 필요하며 virama가 있는 글꼴을 찾을 수 없었습니다.

다음 라텍스 문서는 텍스트에서 kartika를 사용하고 수학에서 현대 라틴 수학을 사용하고 있습니다.
유럽식 악센트도 일반적으로 수학에서 실패하지만, 여기에 \mbox $ 또는 MathML에서 mi 또는 mtext 일부 마크업을 추가하면 virama 예제도 작동합니다.

이미지는 상단에 xetex, 하단에 luatex를 보여줍니다.

따라서 이러한 문자열 주위에 \text{..} 또는 \mbox{...}와 같은 것을 요구하지 않는 것이 바람직하지만, TeX가 현재 달성할 수 있는 것보다 훨씬 앞서서 유니코드 지원을 제공할 것입니다.
따라서 "tex-like syntax"의 사양이 무엇인지에 따라 약간 다릅니다. 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}

토론 내용을 이해하고 있는지 확실하지 않지만 단일 단위를 구성하는 문자 시퀀스를 식별하는 것이라면 유니코드 자소 클러스터링 이 필요한 정보를 제공해야 합니다.

예 - @khaledhosny 가 말한 것은 나에게 옳은 것처럼 들립니다. 비록 제가 모든 경험이 있는 것은 아니지만. @santhoshtr 이 더 자세한 정보를 제공할 수 있습니다.

Santhosh, 위의 @pkra 가 쓴 세 가지 의견이 문제를 가장 잘 설명한다고 생각합니다.

2015년 3월 3일 12:05에 Khaled Hosny [email protected] 은 다음과 같이 썼습니다.

토론 내용을 이해하고 있는지 잘 모르겠습니다만,
아이디어는 단일 문자를 구성하는 문자 시퀀스를 식별하는 것입니다.
단위, 유니코드 문자소 클러스터링
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries 는
필요한 정보를 제공합니다..

예, 하지만 질문은 자바스크립트에 대해 얼마나 의미가 있느냐는 것입니다.
그것을 하기 위한 도서관
기본 플랫폼이 유니코드 속성을 만들지 않는 경우 수동으로
사용 가능
tex 구문을 에뮬레이트하는 경우 tex는 어디까지 갈까요? 너만큼은 알잖아
누구처럼 tex 지원에 대해. xetex에서 얼마나 합리적입니까?
이러한 클러스터가 텍스트로 이스케이프하지 않고 _math_에서 합리적인 모든 작업을 수행하도록 하십시오.
\text{..} 또는 이러한 명령을 사용하여 할당할 수 없는 경우
그런 클러스터에 \mathclass?

자소에 대한 CoffeeScript 구현을 찾았습니다.
https://github.com/devongovett/grapheme-breaker

유용할 수 있습니다.

모든 유용한 의견에 감사드립니다. 요약,

• xetex/luatex는 \text 와 같은 추가 마크업 없이 이 문제에서 요청된 방식으로 입력을 처리하지 않습니다.
• 이런 식으로 처리할 계획이 있는지 (적어도 나에게는) 명확하지 않습니다.
• 솔루션은 David C가 설명한 간단한 접근 방식으로 시작하거나 잠재적으로 grapheme-breaker를 기반으로 구축할 수 있습니다(@hartman에게 감사드립니다!)

거기에 덧붙이자면,

• 반면에 LaTeXML 및 pandoc을 사용한 빠른 테스트는 여기에서 요청한 문자, 즉 xetex/luatex와 같은 문자를 처리하지 않는다는 것을 나타냅니다.

따라서 솔루션은 핵심 TeX 입력에 있을 수 없지만 확장이 필요한 것 같습니다. 그것은 아마도 어쨌든 확장으로 끝났을 것이기 때문에 물론 문제가 아닙니다.

여기에서 TeX 엔진을 실제로 기술하고 싶다면 MediaWiki/WMF 커뮤니티의 의견을 듣는 것이 좋습니다.

다시 한 번 더 많은 피드백을 받는 것이 좋습니다.

• TeX 사람들은 xetex/luatex/etc의 미래 방향을 추가 마크업 없이 수학 모드에서 처리합니까?
• MediaWiki/WMF에서: 비표준 TeX 동작이 관련 커뮤니티에서 실제로 원하는 것입니까?

더 많은 피드백이 없다면 우리는 이것에 대해 언급해야 한다고 생각합니다 / 2.6 이정표에서 벗어나야 합니다.

여기서 문제를 이해하겠습니다. 사람들은 $x+y=<complex character>$ 와 같은 일을 하고 싶어합니다. 여기서 <complex character> 는 아마도 다중 코드 포인트 자소이고 <complex character> 는 수학 식별자로 취급됩니다. ? 그렇다면 이는 합리적인 예상이며 현재의 유니코드 TeX 엔진이 이를 올바르게 처리하지 못한다면(아마도 하지 않을 것입니다) 버그나 누락된 기능일 가능성이 높으며 설계상의 문제가 아닙니다.

아니면 사람들이 $<complex text string>$ 와 같은 작업을 하기를 원합니까? 여기서 <complex text string> 는 복잡한 텍스트 레이아웃이 필요할 수 있는 다중 문자 텍스트 문자열이며 적절한 텍스트 레이아웃(bidi, 모양 등) ? 나는 그것이 합리적인 기대라고 생각하지 않으며 이것이 이와 같이 취급되어야 하는 일반 텍스트 문자열임을 나타내기 위해 일종의 마크업이 여기에 필요합니다.

감사합니다, @khaledhosny!

[...] 사람들은 $x+y=와 같은 일을 하기를 원합니다.$ 어디에아마도 다중 코드 포인트 자소이며,수학 식별자로 처리됩니다. 맞죠?

네 저도 그렇게 이해합니다. (원래 위키피디아 측에서 요청한 내용이라 말씀드리기가 조금 어렵습니다.)

합리적인 기대라고 생각합니다

감사 해요!

현재 유니코드 TeX 엔진이 이를 올바르게 처리하지 못한다면(아마도 하지 않을 것입니다) 버그나 누락된 기능일 가능성이 높으며, 의도된 것이 아닙니다.

그것도 감사합니다. "그들은 아마 하지 않을 것"이라는 부분이 약간 걱정되지만 당신과 @davidcarlisle 이 유니코드 TeX 엔진에서 원하는 동작이라는 데 동의한다면 그것으로 충분하다고 생각합니다.

여전히 MediaWiki/WMF/Wikipedia 측에서 차임벨이 울리기를 바랍니다.

F2F에 따라 v2.6 마일스톤(즉, 곧 출시될 릴리스)에서 이를 제거합니다.

특히 TeX/LaTeX(또는 XeTeX/LuaTeX)와의 호환성 측면에서 올바른 접근 방식이 무엇인지 명확하지 않습니다. WMF와 Wikipedia 커뮤니티가 여기서 진정으로 원하는 것이 무엇인지도 분명하지 않습니다.

분명히 하자면, 우리는 이 문제를 끝내지 않고 TeX 입력에서 복잡한 레이아웃이 어떻게 작동하는지 알아내는 데 여전히 관심이 있습니다.

미래의 폭발: https://github.com/tc39/proposal-intl-segmenter로 문자열을 분할할 수 있도록 하는 TC39 제안 "유니코드 분할"이 있습니다. 저장소에는 polyfill에 대한 링크가 포함되어 있습니다(그리고 분명히 비표준 Chrome 기능도 있습니다).

멋있는. @pkra님 감사합니다.

문제 없어요. 폴리필은 불행히도 쓸모가 없습니다. Enligsh만 다룹니다. 하지만 사용해 보고 싶은 사람들에게는 크롬 내장 기능이 유용할 수 있습니다.