Mathjax: Tata letak teks kompleks, khususnya dengan input TeX [adalah: MathJax tidak mendukung tata letak teks Kompleks.]

Perhatikan bahwa jika Anda menyetel mtextFontInherit ke true di bagian HTML-CSS dan SVG dari konfigurasi Anda, maka MathJax akan memproses \text{} sebagai single <span> , dan itu harus dilakukan sesuai permintaan Anda. Anda benar bahwa MathJax dapat melakukan lebih baik ketika mtextFontInherit adalah false . Itu harus mengelompokkan karakter "tidak dikenal" ke dalam satu koleksi, daripada menempatkan masing-masing ke dalam <span> yang terpisah.

PS, saya melihat laporan tentang bugzilla Wikimedia dan berencana untuk menambahkannya ke daftar hal-hal yang harus diperbaiki. Terima kasih telah melihat masalah di sini untuk melacaknya.

Terima kasih atas tip mtextFontInherit. Saya akan mengaktifkannya, tetapi ini adalah satu lagi alasan untuk melakukan itu.

Beberapa dukungan untuk RTL ditambahkan di v2.3, tetapi masalah urutan beberapa karakter yang diperlakukan sebagai satu unit tetap ada. Untuk \text{} , karakter-karakter ini seharusnya sudah dikelompokkan menjadi satu <span> , jadi itu akan menjadi salah satu cara untuk menanganinya, meskipun tidak terlalu nyaman.

Idealnya, MathJax akan menempatkan setiap urutan yang membentuk satu grup menjadi satu <mi> atau <mo> , seperti halnya untuk huruf Latin tunggal sekarang. Saya telah melihat hal ini sampai tingkat tertentu, dan ada beberapa kesulitan dalam menanganinya. Dimungkinkan untuk menggabungkan karakter yang dikelompokkan dengan karakter sebelumnya, tetapi tidak jelas bagi saya bagaimana beberapa karakter bekerja. Sebagai contoh, sepertinya virama (U+0D4D) menggabungkan tidak hanya karakter di sebelah kiri, tetapi juga di sebelah kanan, meskipun saya mungkin salah paham. Tampaknya juga beberapa pengelompokan ini ditangani oleh pengikat di dalam font, bukan dengan menggabungkan karakter. Sayangnya, MathJax tidak memiliki akses ke informasi ligatur dari font. Meskipun dimungkinkan untuk menambahkan data pengikat ke tabel font MathJax, ini bisa menjadi sejumlah besar data yang sangat sedikit yang akan digunakan oleh satu halaman mana pun.

Saya benar-benar tidak cukup akrab dengan bahasa yang menggunakan fitur ini untuk mengetahui apakah yang saya coba cukup atau tidak. Saya bertanya-tanya apakah mungkin untuk mendapatkan beberapa contoh dari berbagai bahasa yang menunjukkan berbagai situasi yang perlu diakomodasi.

Salah satu pendekatan mungkin dengan menempatkan data yang diperlukan untuk setiap skrip bahasa ke dalam ekstensi individual yang dimuat untuk halaman yang membutuhkannya (baik secara eksplisit dalam konfigurasi MathJax, atau melalui \require{} dalam matematika di halaman). Apakah menurut Anda itu bisa diterima?

Mungkin @amire80 dari rekayasa bahasa WMF kami dapat membantu sedikit di sini...

@hartman apakah Anda pikir Anda bisa mencolek @amire80 suatu saat? Kami ingin meningkatkan ini, terutama jika Wikipedia ingin meluncurkan keluaran SVG lebih luas.

Aku disini :)

Bagaimana saya bisa membantu?

Pengujian? - Dengan senang hati, beri tahu saya apa yang harus diuji dengan tepat.

Contoh cara kerja skrip non-Latin dalam rumus? - Ini tidak digunakan dalam buku teks Ibrani, tetapi digunakan dalam buku teks dalam bahasa Arab dan Persia. Mungkin @ebraminio bisa ikutan di sini.

Ada yang lain?

Terima kasih sudah mampir @amire80 :-)

Bagaimana saya bisa membantu?

Saya berharap kami dapat meningkatkan penanganan karakter gabungan dalam skrip non-Latin. Ini telah muncul di bugzilla/phabricator WMF berulang kali. Mengutip Davide dari https://github.com/mathjax/MathJax/issues/474#issuecomment -38324717 :

Idealnya, MathJax akan menempatkan setiap urutan yang membentuk satu grup menjadi satuatau, seperti halnya untuk huruf Latin tunggal sekarang. Saya telah melihat hal ini sampai tingkat tertentu, dan ada beberapa kesulitan dalam menanganinya. Dimungkinkan untuk menggabungkan karakter yang dikelompokkan dengan karakter sebelumnya, tetapi tidak jelas bagi saya bagaimana beberapa karakter bekerja. Sebagai contoh, sepertinya virama (U+0D4D) menggabungkan tidak hanya karakter di sebelah kiri, tetapi juga di sebelah kanan, meskipun saya mungkin salah paham. Tampaknya juga beberapa pengelompokan ini ditangani oleh pengikat di dalam font, bukan dengan menggabungkan karakter. Sayangnya, MathJax tidak memiliki akses ke informasi ligatur dari font. Meskipun dimungkinkan untuk menambahkan data pengikat ke tabel font MathJax, ini bisa menjadi sejumlah besar data yang sangat sedikit yang akan digunakan oleh satu halaman mana pun.

Saya benar-benar tidak cukup akrab dengan bahasa yang menggunakan fitur ini untuk mengetahui apakah yang saya coba cukup atau tidak. Saya bertanya-tanya apakah mungkin untuk mendapatkan beberapa contoh dari berbagai bahasa yang menunjukkan berbagai situasi yang perlu diakomodasi.

Jadi pertanyaan kami adalah: apakah ada yang memiliki keahlian yang dapat mereka bagikan dengan kami? @hartman cukup baik untuk menunjuk Anda ;-)

(Mungkin kita harus membagi ini menjadi masalah terpisah.)

Ide (sangat) dasar dari virama adalah bahwa urutan konsonan + virama + konsonan memiliki tiga karakter Unicode, yang muncul sebagai menempati ruang satu mesin terbang (tetapi bisa menjadi jauh lebih rumit).

Secara lebih umum, saya ingin memahami situasi MathJax saat ini. Apa yang harus saya lakukan untuk menguji rendering saat ini? Instal instance saya sendiri? Atau adakah contoh online di mana versi saat ini dapat diuji?

konsonan + virama + konsonan memiliki tiga karakter Unicode, yang muncul sebagai menempati ruang satu mesin terbang

Benar. Karakter gabungan cukup umum dalam tata letak matematika sehingga kami memahami situasi secara umum.

(tapi itu bisa menjadi jauh lebih rumit).

Itu masalah kita. Kami tidak memiliki spesifikasi untuk sebagian besar bahasa alami, skrip non-Latin.

Atau adakah contoh online di mana versi saat ini dapat diuji?

Anda dapat melakukannya di MediaWiki (menggunakan mode MathML/SVG dari ekstensi matematika), di browser ( sampel ini atau codepen ini ) atau menggunakan salinan lokal MathJax -- mana saja yang Anda suka.

Contoh dasar: ത്ര akan dikonversi menjadi ത്ര dan karena kami tidak memiliki rutinitas untuk mengidentifikasi jenis karakter gabungan ini, input TeX mengubahnya secara internal ke MathML sebagai

<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>

Yang mana output MathJax pada gilirannya akan dibagi menjadi tiga rentang (dalam output HTML) atau tiga g (dalam output SVG) -- dan tentu saja ini merusak rendering karakter gabungan.

(Saya baru menyadari bahwa Firefox terkadang menggabungkan bentang dalam keluaran HTML misalnya, ത്ര tetapi bukan subskrip dalam കു_ശ . Chrome lebih "konsisten" karena tidak ada yang digabungkan)

Jadi bagi kami masalahnya adalah: apakah ada kumpulan data yang ringkas (atau heuristik yang efisien) yang dapat kami gunakan untuk mengidentifikasi semua situasi yang relevan di mana kami perlu menggabungkan kembali menjadi satu elemen mi/mo di MathML? Setelah kita memilikinya, rendering akan bekerja juga.

Jadi bagi kami masalahnya adalah: apakah ada kumpulan data yang ringkas (atau heuristik yang efisien) yang dapat kami gunakan untuk > mengidentifikasi semua situasi yang relevan di mana kami perlu menggabungkan kembali menjadi satu elemen mi/mo di MathML?

Maaf atas komentar yang panjang, membawa sedikit diskusi di luar situs kembali ke pelacak masalah.

Seberapa layak/mahalnya membuat basis data UCD Unicode?
menggabungkan kelas yang tersedia untuk mathjax untuk setiap karakter? Pada dasarnya (atau
setidaknya sebagai pendekatan pertama yang baik) karakter apa pun dengan bukan nol
menggabungkan kelas (bidang 4 di UnicodeData.txt) harus tetap dengan
sebelumnya, dan sebagai tambahan jika itu kelas 9 (virama) berikut ini
karakter juga perlu dijaga.

Mungkin juga perlu diperhatikan bahwa tex, bahkan unicode tex seperti xetex
atau luatex hampir pasti _tidak_ akan melakukannya dengan benar tanpa
markup
yaitu Anda akan membutuhkan \text{abc} atau \mathit{abc} atau yang lainnya
perintah untuk memaksa string karakter untuk diketik sebagai teks dengan a
font tunggal daripada kebiasaan normal TeX untuk membagi segalanya
karakter demi karakter. Bahkan jika konstruksi _terlihat_ seperti tunggal
karakter kepada penulis.

Dalam teks klasik itu bukan masalah karena font hanya dapat memiliki 256 karakter
dan sementara karakter yang tersusun dapat didukung dengan berbagai trik pemetaan ulang makro
menyusun karakter mengikuti basis pada dasarnya tidak dapat didukung bahkan untuk yang sederhana
menyusun aksen seperti akut.

Dukungan dalam varian tex unicode seperti xetex dan luatex tampaknya sedikit bervariasi. Dalam teks, xetex
menyerahkan semuanya ke perpustakaan HarfBuzz begitu juga dengan cukup baik. luatex menanganinya secara internal dan saat ini kurang baik dengan virama. Dalam matematika keduanya memerlukan font dengan tabel MATEMATIKA tipe terbuka untuk melakukan sesuatu yang sangat berguna dan saya tidak dapat menemukan font yang memiliki virama.

Dokumen lateks berikut menggunakan kartika dalam teks dan matematika modern latin dalam matematika, Anda akan mencatat bahwa
bahkan aksen Eropa biasanya gagal dalam matematika, tetapi bahkan contoh virama berfungsi jika Anda menambahkan beberapa markup \mbox di sini atau mi atau mtext secara setara di MathML

Gambar menunjukkan xetex di bagian atas dan luatex di bagian bawah.

Jadi meskipun tidak memerlukan sesuatu seperti \text{..} atau \mbox{...} di sekitar string karakter seperti itu akan diinginkan, itu akan menempatkan dukungan unicode Anda jauh di depan apa yang saat ini dapat dicapai TeX
jadi itu sedikit tergantung pada apa spesifikasi "sintaks seperti tex", seberapa jauh melampaui apa yang dapat dilakukan TeX apakah masuk akal untuk mendorongnya?

\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}

Saya tidak begitu yakin apakah saya mengerti tentang apa diskusi itu, tetapi jika idenya adalah untuk mengidentifikasi urutan karakter apa yang merupakan satu unit, maka pengelompokan grafem Unicode harus memberikan informasi yang diperlukan..

Ya - apa yang dikatakan @khaledhosny terdengar seperti hal yang benar bagi saya, meskipun saya tidak terlalu berpengalaman dengannya. Mungkin @santhoshtr bisa berkontribusi lebih detail.

Santhosh, saya pikir apa yang @pkra tulis tiga komentar di atas menjelaskan masalahnya dengan baik.

Pada 3 Maret 2015 pukul 12:05, Khaled Hosny [email protected] menulis:

Saya tidak begitu yakin apakah saya mengerti tentang apa diskusi itu, tetapi jika
idenya adalah untuk mengidentifikasi urutan karakter apa yang membentuk satu
unit, lalu pengelompokan Unicode Grapheme
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries harus
memberikan informasi yang dibutuhkan..

Ya tapi saya kira pertanyaannya adalah seberapa jauh masuk akal untuk sebuah javascript
perpustakaan untuk melakukan itu
dengan tangan jika platform yang mendasarinya tidak membuat properti unicode
tersedia
dan jika itu meniru sintaks tex seberapa jauh tex akan pergi? Anda tahu sebanyak itu
tentang dukungan tex sebagai siapa pun. Seberapa jauh masuk akal di xetex untuk
minta kluster seperti itu melakukan sesuatu yang masuk akal di _math_ tanpa melarikan diri ke teks
dengan \text{..} atau perintah semacam itu, mengingat Anda tidak dapat menetapkan a
\mathclass ke cluster seperti itu?

Saya menemukan implementasi CoffeeScript untuk grafem.
https://github.com/devongovett/grapheme-breaker

Mungkin berguna.

Terima kasih untuk semua komentar yang bermanfaat. Untuk meringkas,

• xetex/luatex tidak menangani input seperti yang diminta dalam masalah ini, yaitu, tanpa markup tambahan seperti \text
• tidak jelas (setidaknya bagi saya) apakah ada rencana untuk menanganinya dengan cara ini
• sebuah solusi dapat dimulai dengan pendekatan sederhana yang diuraikan David C atau berpotensi dibangun di atas pemecah grafem (terima kasih @hartman!)

Untuk menambah itu,

• Di sisi lain, tes cepat dengan LaTeXML dan pandoc menunjukkan bahwa mereka menangani karakter seperti yang diminta di sini, yaitu, tidak seperti xetex/luatex.

Jadi menurut saya solusi tidak bisa di input TeX inti tetapi perlu ekstensi. Itu bukan masalah, tentu saja, karena itu mungkin akan berakhir dengan perpanjangan.

Akan lebih baik untuk mendengar dari komunitas MediaWiki/WMF jika mereka benar-benar ingin menggambarkan dari mesin TeX di sini.

Sekali lagi akan lebih baik untuk mendapatkan lebih banyak umpan balik.

• Di TeX, apakah menangani karakter dalam mode matematika tanpa markup tambahan adalah arah masa depan xetex/luatex/etc?
• Di MediaWiki / WMF orang: apakah perilaku TeX non-standar benar-benar diinginkan oleh komunitas yang relevan?

Tanpa lebih banyak umpan balik, saya pikir kita harus melakukan ini / memindahkannya dari tonggak 2,6.

Biarkan saya memahami masalahnya di sini, orang ingin melakukan hal-hal seperti $x+y=<complex character>$ di mana <complex character> mungkin merupakan grafem titik multi-kode, dan <complex character> diperlakukan sebagai pengenal matematika, kan ? Jika demikian, maka saya pikir itu adalah harapan yang masuk akal dan jika mesin Unicode TeX saat ini tidak menanganinya dengan benar (mungkin tidak) kemungkinan itu adalah bug atau fitur yang hilang, bukan sesuatu yang dirancang.

Atau apakah orang ingin melakukan hal-hal seperti $<complex text string>$ , di mana <complex text string> adalah string teks multi-karakter yang mungkin memerlukan tata letak teks yang rumit, dan mendapatkan tata letak teks yang tepat (bidi, membentuk, dll.)? ? Saya tidak berpikir itu adalah harapan yang masuk akal dan semacam markup diperlukan di sini untuk menunjukkan bahwa ini adalah string teks biasa yang perlu diperlakukan seperti itu.

Terima kasih, @khaledhosny!

[...] orang ingin melakukan hal-hal seperti $x+y=$ dimanamungkin merupakan grafem titik multi-kode, dan memilikidiperlakukan sebagai pengidentifikasi matematika, bukan?

Ya, begitulah saya juga memahaminya. (Agak sulit untuk mengatakannya karena ini awalnya merupakan permintaan dari ujung Wikipedia).

Saya pikir itu adalah harapan yang masuk akal

Terima kasih!

jika mesin Unicode TeX saat ini tidak menanganinya dengan benar (mungkin tidak) kemungkinan besar ada bug atau fitur yang hilang, bukan karena desain.

Terima kasih untuk itu juga. Bagian "mereka mungkin tidak" sedikit mengkhawatirkan saya, tetapi jika Anda dan @davidcarlisle setuju bahwa itu adalah perilaku yang diinginkan di mesin Unicode TeX, maka itu cukup bagi kami, saya pikir.

Masih berharap pihak MediaWiki/WMF/Wikipedia akan ikut serta.

Sesuai F2F, kami menghapus ini dari Milestone v2.6 (yaitu, rilis mendatang).

Tidak jelas apa pendekatan yang tepat, khususnya, dalam hal kompatibilitas dengan TeX/LaTeX (atau lebih tepatnya XeTeX/LuaTeX). Juga tidak jelas apa yang sebenarnya diinginkan oleh WMF dan komunitas Wikipedia di sini.

Untuk lebih jelasnya, kami tidak menutup masalah ini dan kami masih tertarik untuk mencari tahu bagaimana tata letak yang rumit dapat bekerja di input TeX.

Ledakan dari masa depan: ada proposal TC39 "segmentasi Unicode" untuk memungkinkan (antara lain) untuk membagi string dengan grapheme https://github.com/tc39/proposal-intl-segmenter. Repositori menyertakan tautan ke polyfill (dan tampaknya ada juga fitur Chrome non-standar).

Dingin. Terima kasih @pkra.

Tidak masalah. Sayangnya, polyfill tidak berguna -- hanya mencakup Enligsh. Namun bagi yang ingin mencobanya mungkin chrome build-in ini bisa bermanfaat.