[npTeX] 欧文トークンに似せたCJKトークン #150
Comments
|
今回の私の提案は、「本格的に kcatcode 16以上をすべてcatcode15以下に移し替えよう」という前提ではありません。 「catcodeが11で文字コード 0x4E00はU+4E00で漢字の「一」でして、それをLaTeX3で処理したいです。」という風にしてそれをLaTeX3の開発チームに理解してもらえればよいです。 |
|
issue の分割と検討をありがとうございます。 まず『LaTeX3 をサポートするうえで (u)pTeX にとって最低限必要なのは何か』を把握する必要があると思います。
|
|
今はブレインストーミング的なフェーズだと思うので、外れかもしれないことを言うかもしれません。 「
(u)pTeX が欧文TeXからかけ離れている点はいろいろあると思いますが、LaTeX3開発で障害になるのはどれでしょうか。
現状
その閾値を決めるプリミティヴを導入すれば済む話のように思います。都合に合わせ設定し直せばよいです。 |
|
もう一つ。 |
|
全然追いつけていないのですが
現状どうしたらいいのかわからないのは
でしょうか。 それから欧文については8-bitエンジンだけど和文文字トークンという異質なものが入ってくるという点でしょうか。 LaTeXでは(u)pTeXは8-bitエンジンとして扱われていて、8-bitエンジンではUTF-8でエンコードされたトークン列を前提としています。この前提のもとコードポイント単位での処理は、先頭のトークンを取得して何バイトのUTF-8バイトなのか判断してそのバイト数分のトークンを1文字として処理しています。 あとupTeXの場合は0x80--0xFFの範囲に和文文字があるためUTF-8の2バイト以上を構成するはずの文字コードを持ったトークンがUTF-8バイト列の中に単独で現れるといったことが起こります。 |
latex.ltx だけを \disablecjktoken で読むだけでは足りなくて「ユーザが書く LaTeX ソースの中身に現れる和文文字トークンが悪さをする可能性がある」ということです。さらに別の問題は「ptexenc による ^^-記法 への変換」が regex の ^ による文字除外シンタックスと衝突しうるということです。
それは CJK ノードの生成であって，CJK トークンを生成しているのではありません。「CJK ノードが存在すること」は LaTeX3 と一切衝突せず，TeX 入力を解釈するうえで「CJK トークンが存在すること」が課題になっています。 |
e-upTeX なら，\Uchar, \Ucharcat でできます： \disablecjktoken
\expandafter\expandafter\let\expandafter\A\Uchar"3042\relax
\message{\meaning\A}
\bye極端なことを言えば，「和文文字ノード」（aminophen さんの言葉だと「CJK ノード」）があれば，「和文文字トークン」がなくても
だけでもなんとかなりうると思います． いくつか着地点は思いつくのですが，文章化できるほどには考えをまとめる時間がありません……（後で書きます）． |
|
あまりよく分かっていませんが |
端的に書いていただいてありがとうございます。私の理解と合っています。 |
|
雑感です。
こういう話を聞くとCJKノードが内部バッファでもUTF-8のバイトの並びでなければならない、という状況は理解します。 全く別のソフトですが、Unicode化したときの内部バッファは、upbibtex, bibtexuはUTF-8, upmendexはUTF-16でして、それを採用した事情もさまざまです。 luaLaTeX, XeLaTeX のCJKは内部バッファでUTF-8になっているのでしょうか? |
LuaTeX は内部バッファが UTF-8 です (tex/textoken.c, utils/unistring.c)． XeTeX は，ビルド時に作られる xetexd.h を見ると |
|
ありがとうございます。
XeLaTeXでは h20y6m/plexpl3#2 の問題は発生しないのでしょうか? |
これは欧文文字トークンは8-bit ASCIIのまま和文文字トークンをなくしてしまうということでしょうか？ これだと「和文文字1文字=1トークン」の前提が使えなくなるのでつらいですね……。 （それに今のLaTeXは8-bitエンジンの場合0x80--0xFFの範囲の文字はカテゴリコード13になっているのでそのままではソースに「あ」とかいても展開されて「^^e3^^81^^82」というトークン列が残らないという問題も……） 個人的には（可能かどうかは置いておいて）和文文字トークンをなくすなら欧文文字トークンはUnicodeになってほしいです。
「内部バッファ」がUTF-8かどうかというのはあまり重要ではないと思います。 pdfTeXでは文字トークンは0x00--0xFFの文字コードを持ちます。 UnicodeエンジンのXeTeXとLuaTeXの場合文字ト－クンはU+0000--U+10FFFFの文字コードを持ちます。 upTeXの場合欧文文字トークンについてはpdfTeXと同様の処理が必要になります。
発生するのはupTeXのみです。 例えば文字コード0xB1をもつトークンは 同じ文字コードで和文と欧文が重なっているupTeX特有の問題です。 |
|
どうすればいいのか私の中でいまいち見えてきません． 以下は適当に思いついた一つの案です．
Footnotes |
|
JIS X 0208で和文(全角)でかつUnicodeでU+00FF以下の文字コードが欧文の0x80..0xFFの文字コードが重なっているところが課題ということですね。upTeXの最初の頃と悩みが変わっていない。
のようにすれば、欧文と和文の文字コードの重なりが解消され、現状の upTeXとの差分は小さくて済みます。 XeTeXとLuaTeXでは JIS X 0208に加え中韓フォント対応で入れた中黒 U+00B7 も入れてリスト化しておきます。備忘録として。
|
安直ですが jpTeX に一票です。
|
|
@h-kitagawa さんの案:
を多少変更した案はどうでしょう:
|
|
まだついていけてないのですが… \catcode の話「全 Unicode 範囲について，…」は，「何バイトが1個の文字トークンになるか」とも合わせて考える必要がありますよね。
新しい仕様では？？？ 従来の upTeX での \kcatcode の切替に「Unicode 文字を直書きしてバッククオートで値取得」を使うと文字トークンの区切り変化に対応できず，16進数の値を指定するほうが安全でした。同様に，\prebreakpenalty 指定などで多用される「バッククオートによる文字コード取得」や LaTeX の |
upTeX の \kcatcode=15 をここで活かすという手もありますね．
とするとか1．ただその場合
の問題は残ることになります． 「見た目 1 文字（Unicode 1 文字） = 1 トークン」がもちろんスッキリしているのですが，「実際に欧文 Unicode フォントを使うことはできない」のが新たな火種になったら困るなあ，という思いもあります． Footnotes
|
|
名前の案について、 jpTeX は一つの有力候補だと私も思いますが、Japan を強く連想させすぎないか、気になります。CKの人もできれば招き入れたいと思います。
私としては、この中では apTeX が割と好みです。 |
|
aptex は ptex-ng の別名として既にあるんですよね…。（make すると aptex が ptex-ng のコピーとして生成する） |
|
他も書いてみます。
個人的には，今回のフォーク目的が「日本で愛されてきた (u)pLaTeX の系譜を終了させないこと」だと思っているので，新たに CK の人を取り込む発想には乗りにくいです。確かに取り込めたほうがモチベーションにはなるのですが…。 |
なるほど。それは腑に落ちます。 |
もちろんそれができればよいのですが，もし彼らが XeLaTeX, LuaLaTeX をすでにメインにしているのであれば，pTeX 系統に入ってくる可能性は少ないと思います． 実際の CK の状況は知らないのですが，ちょっと検索したところ
が出てきました． |
|
名称すら決まっていない段階ですが，新エンジン用にディレクトリだけ作ったものをhttps://github.com/h-kitagawa/texlive-source/tree/kitagawa_zptex_concept に置きました．バイナリができることだけ確認しています．
|
そうですね，まとめる方向に +1 です。過去の #32 とも絡みますが整理したいです。
|
|
名称案追加です。
個人的には結構 +1 です。→ 過去にありました。没です。 中国語: ctex のチームがおそらくxeCJK & XeTeX推し |
|
すっかりご無沙汰です．まとまって作業できる時間がやっと取れたので，ここ二週間ぐらい一から考え直しています． @aminophen さんが以前 Slack で，「XeTeX に pTeX の和文組版を載せる」といった趣旨の発言をされていた覚えがあります．当時は私はその方針には反対だったのですが，実際にコードを書いてみたところ，悪くない気がしてきました．
|
|
ご無沙汰しております。こちらも Slack で・GitHub で色々と意見だけ言っておきながらその後何も検討も動けていませんでした。もうすっかり忘れてしまったので，一から勉強し直しています。(u)pTeX 特有の重要な概念として「①和文文字トークン」「②和文文字ノード」がある中で，現在の①の挙動は expl3 とって不都合があるので，維持したい機能を残しつつ欧文文字トークンに近づけたいという話でしたね。 思いつきに過ぎなかった「XeTeX に pTeX の和文組版を載せる」を拾っていただいてありがとうございます。ざっとざっと実装を見てみましたが，整っていて綺麗だと感じました。 和文文字トークンの現在の挙動のうち，維持したいのは「(1バイト1トークンではなく)“見た目の1文字”で1トークンになる」「ノード化すると(欧文文字ノードではなく)和文文字ノードになる」ということくらい（例えば e-upTeX ベースと XeTeX ベースのどちらが良いかは迷います。内部コード Unicode 固定はもう確定路線とみなすと，どちらを使っても実現はできると思えてきましたが，違いは以下くらいのことでしょうか：
|
|
(あと，XeTeX だと dvips が使えなくなって困る人も出てくるのでしょうかね) |
styと使用例 のように，一行で「8-bit TFM の状況」，つまり
に戻せれば良いかな．と思いました． |
xdv (pdf) の代わりに dvi を出力させるスイッチ
そうすると，「XeTeX ベースの npTeX +
と書いていますが，この点は (A) でも変わらない気がします． |
ありがとうございます。
エンジン自体の機能およびユーザレベルでは仰る通りですね。パッケージ開発者レベルでは差があって，(A)の場合は LaTeX の随所にある「LuaTeX or XeTeX か否か」という名称判定から「Unicode フォントかどうか」という機能判定に変更して回る処置が必要と思われます。ちょうど pLaTeX が eptex から euptex -kanji-internal=euc になったことで誤判定を直して回ったばかりですが，あの時は日本側で済んだところを今度は海外に説明して回らないといけない感じはします。その点に限っては(B)に軍配が上がります。もちろん，機能的には，XeTeX ベースの npTeX の方が「 |
|
(A)を採る場合に「パッケージ開発者レベル〜〜〜(中略)〜〜〜海外に説明して回らないといけない」を避けるため，スイッチ |
|
ざっと試しに動かしてみていますが，うまく動いていません。私のところでは Mac でビルドするため nptex.am をこのように改変（
他，エンジンの機能上 e-upTeX との差異に気づいた点：
\documentclass{article}
\begin{document}
\tracingonline1
\showboxdepth10000
\showboxbreadth10000
和文と違って、Latinの禁則は[まだ]完全でない。
\showoutput % "[" の後の禁則ペナルティが入らない
\end{document}今後の実装については，fam256.ch 及び \epTeXinputencoding の機能を持ってきたときに XeTeX 拡張（それぞれ \Umath〜 及び \XeTeXinputencoding）と衝突しないかが今後気になるところ。 |
確認ありがとうございます．直しました．
こっちは一筋縄ではなさそうです． |
|
\postbreakpenalty の修正ありがとうございます。 他，不具合がおきる例は作っていませんが ここの subtype 値はずらした方が良さそうです。 あと，nptexdir/memo.txt に書かれていませんが \readpapersizespecial は未実装ですね。それと \pdfsavepos の組方向対応。 |
→ [edit] 2023-08-22: 何度か rebuild / fmt 再生成したらいつの間にか治りました。 |
|
欧文ノード生成途中の \the\lastnodechar が -1 の件ですが，\ifnum\lastnodechar〜も同様になります。多分 \relax 前置で生成打ち切りするのが筋でしょうけども。 [edit] 気づいたことを書いていきます。2023-08-24
|
|
ようやく動かしてためしはじめました。（Windowsは諦めてUbuntu 22.04 on WSL2） 気になったことを書いておきます。
|
自分で言っておいてなんですが、あまり意味がないような気がしてきました。 早速実装していただいたのにすみません…… |
後で調べます．
XeTeX では input_line が XeTeX_ext.c で定義されていますが，ここで行われる XeTeX による Unicode 正規化やコード変換の前に）ptexenc の input_line2 に通してしまう，というのはどうでしょうか． こういう点を見ると，e-upTeX ベースの方が「後から発覚する」トラブルが少なくなる気がしており，悩みます．TeXConf2023 で何かは（「悩んでいる」ということでもいいので）報告したいところですが……． |
|
いろいろな検討をありがとうございます。悩ましいです。 XeTeX ベースはどうかと提案した理由は，あまり深く考えずに
という期待でしたが，安直でしたかね…。確かに，後から発覚するトラブルが少ないのは e-upTeX かもしれません。
悩みつつ要件と論点の整理中…。 npTeX / npLaTeX の目標：(u)pLaTeX ユーザが自然に使える npLaTeX を実現すること
何かしら話すきっかけになればありがたいです。 |
|
こちらこそ，整理をどうもありがとうございます．
|
|
自己レスです．
e-upTeX の main_loop において chardef トークンや \char の処理方法を見てみると， のように「kcatcode を算出し，文字トークンとして扱う」ことをしています． 0x110000 以上の文字コードに対して \catcode, \prebreakpenalty, ... を設定できるようにするのは意味がないように思います，たとえば（0x400000 が境目だったとして）次のようにすると良い？
|
個人的には 0x110000 以上の 文字トークン は無いほうがいいと思います。 ところで 0x110000 以上の 和文文字ノード は otf パッケージの \CID コマンド等で必要になりますが、0x220000 以上の文字コードって必要なんでしょうか？ 気付いたことの追加：
|
[upTeX+dvipdfmx] 異体字セレクタ、Unicode合成文字 #46 で述べているような構想があるのみで、いまだに実用には至っておりません。ただ、いつかは使いたいと思っており、 "reserved" のつもりです。 |
実現自体はなんとかなりそうですが， と，すでにトークン列が割り当てられていることには注意が必要です（nptex.ini からこれらの行を削除するだけでよい？）．
なるほど……それはそうですね．「[upTeX+dvipdfmx] 異体字セレクタ、Unicode合成文字 (#46 )」の（e-upTeX ベースか XeTeX ベースかに関わらず）npTeX での実装方法とも絡んでくるので，引き続き考えてみます． |
|
全然ついていけておらず、少しずつ読み返しております。シロウト質問です。
そうすると、"多くのLaTeXパッケージ"は、「XeTeX ベースの npTeX + -dvi (A)」ではそもそも使用できない、ということでしょうか。 npTeX が「Unicode 1 文字から 1 トークンができる」かつ「（本文の）欧文フォントは tfmであってUnicode フォントではない」というエンジンになったとして、 「日本語pLaTeX向けパッケージ」は「欧文の本文が8bit tfm」であることを要求していてnpTeXは「欧文の本文が8bit tfm」で動かしたいので、"多くのLaTeXパッケージ"にも「Unicode 1 文字から 1 トークンができる」かつ「欧文の本文が8bit tfm」に対応してもらう必要がある、ということでしょうか? 頭の中が混乱しています。 |
これは
としたほうが良かったでした．すみません． こんな感じでしょうか：
私はそのように考えています．
「どこまでやってもらえるか」は未知数ですが，私は必要性を感じます． 「e-upTeX ベースの npTeX (B)」でも「XeTeX ベースの npTeX + -dvi (A)，ただし XeTeX と判定されない」で問題になる事象は，pdfLaTeX 用のソース を「LuaTeX の \directlua って便利そうだな」という理由からタイプセッタを lualatex に変えても意図通りにならない（フォントが Times にならない）というものと同じことです． |
|
ありがとうございます。
1は日本語 XeTeX として、XeTeX互換性が高く、海外LaTeXパッケージが通りやすいところを目指す。2はpTeXの後継として従来の日本語pLaTeX用パッケージが通りやすいことを目指す。 |
|
upTeX の IVS関連 #45 で kcatcode周りをいじっている最中に思いついた案です。 kcatcode latin_ucs 14番 を新設。 この状態でほぼ plain uptex入力に対し、 %#!uptex
\parindent=0pt
\font\ec=ecrm1000
\ec
\jfont\jpy=umin10
\jpy
\def\pick#1{=#1=}
%default
1 Æ \kchar"C6 \char"C6
\wlog{Æ}
\message{\expandafter\pick\string Æ}
\kcatcode"C6=15 % not_cjk: not cjk characters
2 Æ \kchar"C6 \char"C6
\wlog{Æ}
\message{\expandafter\pick\string Æ}
\kcatcode"C6=18 % other_kchar: cjk symbol codes
3 Æ \kchar"C6 \char"C6
\wlog{Æ}
\message{\expandafter\pick\string Æ}
\kcatcode"C6=14 % latin_ucs: not cjk in ucs code
4 Æ \kchar"C6 \char"C6
\wlog{Æ}
\message{\expandafter\pick\string Æ}
%default again
\kcatcode"C6=15 % not_cjk: not cjk characters
5 Æ \kchar"C6 \char"C6
\wlog{Æ}
\message{\expandafter\pick\string Æ}
\bye
logはこんなのが出ました。
|
upTeXにcatcodeが15以下でかつCJKのトークンを追加で導入しよう、という提案です。
[upTeX] JIS-encoded TFM #149
とは別に扱った方がよさそうなので issue を立てます。
背景はこちら。
#149 (comment)
で、私の提案はこちら
#149 (comment)
で @aminophen さんのリプライ
#149 (comment)
The text was updated successfully, but these errors were encountered: