Open t-tk opened 1 year ago
eqtb テーブルに格納された属性の kcatcode は… 和文文字トークンに格納された属性の kcatcode は…
どちらの言明も直接「欧文文字トークン」自体に kcatcode の情報が必要な理由には当たりませんが,これらの言明は最低限「eqtb テーブル」には catcode と kcatcode の両方の情報を持たせる必要があることは示しているので,結局『eqtb テーブル内で catcode=12 かつ kcatcode=17 な状態を許すかどうか』からは逃げられません。
原理としては「文字トークンは catcode か kcatcode のどちらか一方だけを持つ」でも可能だと思いますし,例えば「 あ
が和文扱い (kcatcode=17)の状態で \catcode`あ=13 されれば欧文扱い (catcode=13) に自動で切り替わる」とできれば自然だと思います。ただ \catcode 以外の特性値の代入(\lccode のように「和文でも欧文でもありそう」なものとか,\sfcode のように「いかにも欧文専用っぽい特性」とか)でも切り替わるべきかどうか?
現状 OTFパッケージの vf の文字コードの一時利用先として使っています。
これは「文字コード上限 U+10FFFF に落とすと,OTF パッケージは使えなくなる(改修が必要)」ということを仰っていますか?
はいそうですね。現状のvfは使えなくなります。
現状では \CID{}
, \CIDT{}
などのコード値の入力をsubfontに分けた残りのコード値を 64 x 64 = 4096文字 に写します。
その値に対しさらに pLaTeX では 64 x 64 を (16区 .. 79区) x (16点 .. 79点) (漢字の領域) のJIS→EUC/SJISに変換 (すなわち 8bit 8bitにして 0x3030 を足して \jis で内部コードに変換)します。
upLaTeX ではその代わりに 0x113030 を足した後 \kchar で内部コード (Unicodeではない値)にしています。
できれば、ディスク容量を食う subfont を使いまわしたいのでこういうコード変換にしました。
upLaTeX では pLaTeX よりも和文の文字コードの範囲がはるかに広いので、subfontの分け方を変えて内部コードも変えることで同等の動作を作り出すことは可能です。
現に、最近の japanese-otf-uptex では \UTF{}
, \UTFT{}
などはsubfontの分割をやめて Unicodeの値をそのまま使うように変えてしまいました。
\CID{}
, \CIDT{}
などは、文字幅(1/2角、1/3角、1/4角など)がいろいろあるのをちゃんと新subfontで作り直そうとすると面倒なうえ間違えてしまいそうなのと、Unicodeではない文字コード(CID)のものにUnicodeの文字コード(0x10FFFF以下, しがらみがありそう)を与えてしまった場合にどんな結果が起きるのか予見出来ず、もとの pLaTeXと同じ齋藤さんの vf, subfont を使い続けています。
ご参考: \UTFC{}, \UTFT{}, \UTFK{}の多書体化 和文vf の fallback を使った vf の軽量化
そういう事情で、仮称zpLaTeXでも多少はUnicodeではない内部コードを確保しておくことに +1 です。
上記の目的では、0x113030..0x116F6F を使っています。 IVSの漢字で使うことを考えないのであれば、max 0x1FFFFF で充分お釣りがきます。
原理としては「文字トークンは catcode か kcatcode のどちらか一方だけを持つ」でも可能だと思います
と書かれたあとですが「文字トークンがcatcode, kcatcode, is_cjkを独立に持つ」で思いついたことをかいておきます……
\catcode
の書き込みは連動してis_cjk=0(欧文)に更新する\kcatcode
の書き込みはブロックの全文字に作用し16, 17, 19ならcatcode=11かつis_cjk=1(和文)に、18ならcatcode=12かつis_cjk=1、15ならis_cjk=0に更新する(互換性のため)\meaning
は kanji character 〇
にする(①どおりなら the letter 〇
等)\ifx
はkcatcodeも比較する(①どおりなら文字コードとcatcodeのみ比較)\string
等の文字列化はcatcodeのみ12に変更する\lowercase
トリックで和文文字トークンは生成を認めるか?\Ucharcat
はどうするか?和文文字トークン⇔欧文文字トークンの変化は起こらないはずですので、 欧文文字トークンがkcatcodeを持つ意味はなさそうです。 和文文字トークンがcatcodeをもつ意味はkcatcode=16,17,19かつcatcode!=11またはkcatcode=18かつcatcode!=12を認めるかどうかによりそうです。
話の流れとは全く関係ありませんが、新しいものを作るならダメもとで無茶な提案をしてみてもいいかなと思ったので書いておきます。
和文フォントでもリガチャのようなことができないだろうというものです。
たとえば「か」+U+309Aで「か゚」とか、IVSで異体字とか、くずし字連綿とかが組めるようになるのではないかという思い付きです。
「文字トークンがcatcode, kcatcode, is_cjkを独立に持つ」で思いついたこと
ありがとうございます。情報は独立に持たせつつも,必要なところでは連動させるということですかね。それは確かに私が迷っていたところをかなり解決してくれそうです:
トークンはcatcodeに従って振る舞う(つまりcatcode=13ならkcatcode, is_cjkによらずアクティブ文字)…① \catcode の書き込みは連動してis_cjk=0(欧文)に更新する \kcatcode の書き込みはブロックの全文字に作用し16, 17, 19ならcatcode=11かつis_cjk=1(和文)に、18ならcatcode=12かつis_cjk=1、15ならis_cjk=0に更新する(互換性のため)
この辺りはなるほどと思いました。
和文文字トークン⇔欧文文字トークンの変化は起こらないはずですので、 欧文文字トークンがkcatcodeを持つ意味はなさそうです。 和文文字トークンがcatcodeをもつ意味はkcatcode=16,17,19かつcatcode!=11またはkcatcode=18かつcatcode!=12を認めるかどうかによりそうです。
そうですね。認めないことにして「和文文字トークンはcatcodeを持たない」でも良いように思えてきました(\ifcat では読替を行えば十分)。これなら「トークンは一律に 5bit(catcode/kcatcodeのどちらか)+24bit(文字コード) で表される」だけで済んでしまいますね。
名称案
でいかがでしょう。 jpTeX だと japan を強く連想させすぎる感じがしていましたが nippon ならよいかと。
(ASCIIさんが nihongo TeX という呼び方もしていたのを思い出したので nihongo pTeX を追加しました)
今のところ,いろいろ考え直して以下に傾いています。
に傾き始めています。 → 最新の頭の中を書き下したもの
もやっと思ったことを書き連ねておきます.
\1年目業績
」を考えると「①の状況は敢えて容認する」でも良いかな."xyzw
に対して,「コントロールワード内に使えるようにしたい」という目的で \catcode"xyzw=11 \kcatcode "xyzw=17
とすることができない(最初の代入で欧文扱いに固定されてしまう).
新エンジン用にディレクトリだけ作ったもの https://github.com/h-kitagawa/texlive-source/tree/kitagawa_zptex_concept
- npTeX: new pTeX, next pTeX, novel pTeX, notable pTeX でかつ nippon pTeX または nippon TeX
tex-jp-build の枠内に収まらないと不便なので,npTeX(仮称)の名称で https://github.com/h-kitagawa/tex-jp-build/tree/nptex_concept に. 名称が正式決定し次第,texjporg/tex-jp-build に移します. →(edit) 移しました.https://github.com/texjporg/tex-jp-build/tree/nptex_concept
多数の賛同いただけたようなので npTeX / npLaTeX で決定しましょう。
以下はどうしましょうか。 (u)ppltotf, (u)ptftopl, (u)pdvitype, (u)pbibtex
np???を作ってそれに一本化して従来のものを廃止? np???を作って従来の名前はaliasで残す? np???を作らず、(u)p???を継続する?
web2c/*ptexdir/ の下に無い (u)pmpost は?
upmendexは、すでにforkしてから大きく逸脱しているのでそのまま続けるつもりです。
一応 nptex, nplatexでググってみると検索結果が少し出ますが TeXエンジンやコマンド名と混同することはなさそうです。
多数の賛同いただけたようなので npTeX / npLaTeX で決定しましょう。
👍
以下はどうしましょうか。 (u)ppltotf, (u)ptftopl, (u)pdvitype, (u)pbibtex
web2c の下に無い (u)pmpost は?
これは正直イマイチ触れていないので考えないことにしたい…。
upmendexは、すでにforkしてから大きく逸脱しているのでそのまま続けるつもりです。
良いと思います。
(u)ppltotf, (u)ptftopl
ひょっとしたら
和文フォントでもリガチャのようなことができないだろうというものです。
みたいな機能拡張を行うことも考えられます.ただ,「機能拡張を使わない場合は従来と同じ jfm/jpl の結果が得られる」というのならば,up〜 のままで良いのではないかと思います.
web2c の下に無い (u)pmpost は?
(u)ppltotf を残すのであれば,これもわざわざ変える必要はないと思います.
和文フォントでもリガチャのようなこと
リガチャそのものではなくてupTeX内で合成文字の私的な内部コードを使う考え方は以前述べていました。 [upTeX+dvipdfmx] 異体字セレクタ、Unicode合成文字
普通の全角文字は jfm の 0番に対応付ければ正常に組めることを利用して、 前述のような私的な内部コードを使う代わりに npTeX の内部コードで合成で表されるUnicodeのコードポイントの列 (例えば「か」+U+309A)を一つの全角文字として扱って組むことが出来ると、漢字のIVSや鼻濁音の半濁点仮名位までは対応できそうです。 実装できるまで先が長そうですが。
最新の頭の中を書き下したもの
もやっと思ったことを書き連ねておきます.
ありがとうございます。
内部バッファからのトークン生成や \Uchar などでは,和文欧文の判定で何を最初に見るのが良いか?
is_cjk = 1 に設定する場合は catcode=11,12 以外を許容しないことにして catcode も修正するという連動も仕様に追加しましょうか。「catcode が 11,12 以外の状態で,is_cjk=1 に設定されたら,kcatcode が 16,17,19 なら catcode を 11 へ / kcatcode が 18 なら catcode を 12 へ変更する」 → 書き下しを修正
(catcode, kcatcode)=(11, 18), (12, 17)……①という状況も「コントロールワード内に使えるか」という点で欧文扱い・和文扱いで状況が異なることは確か.
これは敢えて容認でもいいかと思います。
例えば (catcode, kcatcode)=(12,18) になっている文字コード "xyzw に対して,「コントロールワード内に使えるようにしたい」という目的で \catcode"xyzw=11 \kcatcode "xyzw=17 とすることができない(最初の代入で欧文扱いに固定されてしまう).
なので,気にすることはないのではないでしょうか。
[TODO] 文字コード X ≧ 0x100 の欧文文字トークンをどうするか?
これにどれくらいの手間がかかるか,で全体の方針も決まってきそうな気がします.…
\tonoderecipe"xyzw={<token list>}
みたいなものを導入する?アクティブ化に頼らずに何らかの方法で「Unicode 値→出力命令へのマッピング」を定義できるようにしたい
LuaTeX には「仮にその文字コードがアクティブ化 (catcode=13) されたら…」を定義する \letcharcode というプリミティブがあって \def\foo{bar}\letcharcode<文字コード>=\foo
とすれば \meaning<文字コード>
が bar
になります。(lowercase / uppercase トリックを使わずに済む)
% luatex
\show X % > the letter X.
X % => X
\char`X % => X
\def\foo{Y}\letcharcode`X=\foo
\show X % > the letter X.
X % => X
\char`X % => X
\catcode`X=13
\show X % > X=macro:->Y.
X % => Y
\char`X % => X
\end
\tonoderecipe"xyzw={<token list>}
は「仮にその文字コードが is_cjk=0 だったら…」が欲しいのでちょっと似ていますが「アクティブ化は要しない(catcode=11,12 専用)」「そのトークン列を使うのは \meaning
の時ではなく \char
の時である」というのが異なります。
\tonoderecipe"xyzw={
} は「仮にその文字コードが is_cjk=0 だったら…」が欲しいのでちょっと似ていますが「アクティブ化は要しない(catcode=11,12 専用)」「そのトークン列を使うのは \meaning の時ではなく \char の時である」というのが異なります。
まだコードを見ていませんが,実装については「自動的にトークンを挿入する」という点で \XeTeXinterchartoks
が参考になったらいいな,と思っているところです.
最初に提案した \tonoderecipe"xyzw={<token list>}
だと各文字コードごとに命令を割り当てることになり面倒な気がしてきました(メモリも食う).
→(edit) アクティブ文字の意味を格納する場所 (active_base) とかを流用してよい?
\nptextonodeprefix={<token list>}
を 1 つ準備し,
\nptextonodemode=0
のとき,"100
以降の欧文文字トークンはノードを作らない(警告あり).\nptextonodemode=1
のとき,欧文文字トークン "xyzw
からノードを生成しようとする際に,\nptextonodeprefix
の中身を "xyzw
の前に前置する\nptextonodemode=2
のとき,欧文文字トークン "xyzw
からノードを生成しようとする際に, "xyzw
を \csname \nptextonodeprefix ^^AB^^CD\endcsname
(後半は UTF-8 バイト列)(がすでに定義されていれば)置き換える\nptextonodemode
≧3 でも.とかやっても良いかもしれません(npLaTeX では \nptextonodeprefix
が u8:
になる).
仕様案の書き下しではなるべく今の和文(CJK)トークンの仕様を生かそうとしたのですが,書き進めるうちに内部改修量が随分と多いように思えてきました。もちろん頑張ってもいいのですが…。
従来の「和文(CJK)トークン」のどんな特性を維持すれば,日本の大量の (u)pTeX の資産を生かすことができるのでしょうか?「1文字1トークン」?「kcatcode という値」?
確かに upTeX の \disablecjktoken 状態は「1バイト1トークン」かつ「kcatcode も関係ない」ですので,欧文 8bit TeX (pdfTeX in DVI mode) と何ら変わらず,日本では殆ど使い物にならないと思います。しかし,仮に「1文字1トークン」にさえできれば kcatcode はなくてもどうにかなる可能性はあるでしょうか。例えば XeTeX に (e-)(u)pTeX から和文組版処理を切り出した change file を当てる形で npTeX を実現することはできないか,ということを考えています。
自分の考えとしては、やっぱり、 和文文字トークンのkcatcodeは要らない (従ってnpTeXの文字トークンのkcatcodeも要らない) と思いました。
さらに、 文字のkcatcodeについての(u)pTeXとの互換性もそれほど重要でない とも考えています。
\kcatcode
の代入のよくある使用例についてアドホックに互換性が保たれれば十分だと思う。jcharwidowpenalty の判定に絞ると,upTeX は「和文文字トークンに kcatcode を持たせて和文文字ノードに波及させる」としています。ZR さんの仰るような和文文字トークンの kcatcode は存在しない(catcode のみ存在する)状態でも,jcharwidowpenalty の判定に要るのは「kcatcode が 18 かどうか」だけなので
とすれば済みそうですね。
こうなると eqtb テーブルの kcatcode も重要ではなく,is_cjk と catcode の2つの属性を持つことにして「\kcatcode 代入」のアドホックな互換性対応で
でも一見良さそうに見えます。しかしこのとき「ハングル(19)直後の改行は空白になる」が区別できない問題が残ります。
こう考えると,eqtb テーブルには 3 つの独立属性がやっぱり必要なように思います。組み合わせは
後者のように kcatcode の意味を分離するとよさそう?
現在の仕様を見るとやっぱり複雑な「連動の仕様」が異様にみえます。そもそもこれが必要になる理由は「catcode、is_cjk、kcatcodeで機能の重複がある」(このため「catcode=11、kcatcode=18」みたいな困った状態が生じる)だと考えられます。「連動無しで済ます」かつ「欧文側のみの操作を期待通りにする」ために、次のような方針を考えてみます。
kcatcodeに関する互換性を諦めて、kcatcodeを機能縮小する。特に他属性と重なる機能はそちらに譲る。
catcodeとis_cjkの関係については、 h20y6mさんの提案を採用する。
トークンはcatcodeに従って振る舞う(つまりcatcode=13ならkcatcode, is_cjkによらずアクティブ文字)・・・①
is_cjkは見ないので「catocde=13、is_cjk=1」は単純にアクティブ文字ですればいいことになります。
互換性のために「\kcatcode
への代入」で文字の属性の設定が行われるようにする。
\kcatcode
の取得」は(互換性を保つ動作ができないので)サポートしなくてよいと思う。jcharwidowpenaltyの制御は?
和文の行末空白抑止の制御(ハングルのため)は?
\kcatcode
」を用意する方がよさそう。自分の考えた仕様の概要は以下のようになります。
\kcatcode
の代入」をサポートする。\if
、\ifcat
はis_cjkを見ない。\ifx
は(文字コードを見るケースにおいては同時に)is_cjkを見る。h-kitagawa/kitagawa_nptex_sandbox_1 でいろいろ遊んでいます(まだ動きません)が,内部バッファや文字列のトークン化について考えているところです.
pTeX p4.0.0 (#81) において,文字列を格納するstr_pool を 16 bit に拡張し
今の所考えている仕様&実装案は:
^^
記法からは 1 トークンが生まれる(つまり,^^e3^^81^^82
は 3 トークンを作る)仕様は維持する→\<edit>
- x=1 のとき.U+0080 以上の欧文文字トークン由来のバイト列の一部
- x=2 のとき,和文文字トークン由来のバイト列の一部(U+0000--U+007F の和文文字トークン由来もここ)
は区別しなくても良い気がしてきました.upTeX と違い,欧文文字トークンも Unicode ですし. \</edit>
今更ですが,和文文字トークンと欧文文字トークンの区別を一切なくし,
のようにするのは互換性を考えなさすぎ?
別に「和文の特殊文字/文字トークン」が存在しても何も困ることはない。 互換性のために「\kcatcode への代入」で文字の属性の設定が行われるようにする。「\kcatcode の取得」は(互換性を保つ動作ができないので)サポートしなくてよいと思う。
これはそうだなと思いました。
今更ですが,和文文字トークンと欧文文字トークンの区別を一切なくし,…のようにするのは互換性を考えなさすぎ?
最近ようやく和文トークンと欧文トークンの区別をつけたところから逆行するので理解が追いついていません…。「ノード化の際,その時点での is_cjk の値を参照して欧文・和文組版処理を切り替える.」で大丈夫かどうかは,欧文TeX想定で書かれたマクロから意図せず和文組版されるケースが出てくるかどうかにかかると思います。
今更ですが,和文文字トークンと欧文文字トークンの区別を一切なくし,…のようにするのは互換性を考えなさすぎ?
まず気になるのが \textquotedblleft
の類のLICR系のマクロ(これは欧文が想定されている)なんだけど、これはchardefトークンに帰着されるので、考慮中の仕様では問題にならないらしい。(LuaTeX-jaではchardefも和文になりえるので対策が必要なようだが。)
いろいろ遊んでみていますが,
@d cs_token_flag=@"1FFFFFFF {amount added to the |eqtb| location in a token that stands for a control sequence; is a multiple of~@@"1000000, less~1}
この値は現在の 2^29-1 より増やすのに気が進まなくなってきました. tangle.ch で制限を緩和させればいいのでしょうけれど…….
if abs(accumulator)>=@'100000 then
begin err_print('! Value too big: ',accumulator:1); accumulator:=0;
@.Value too big@>
この制限は tangle.ch で '10000000000
= 2^30 未満と緩和されています(otangle では最初から 2^30 未満という制限).
@ @<Check the ``constant''...@>=
if cs_token_flag+undefined_control_sequence>max_halfword then bad:=21;
256 以上の欧文文字トークンのノード化(\noderecipe
とか)なども悩んでいますが,そちらは別 issue を立てようと思います.
すっかりご無沙汰です.まとまって作業できる時間がやっと取れたので,ここ二週間ぐらい一から考え直しています.
@aminophen さんが以前 Slack で,「XeTeX に pTeX の和文組版を載せる」といった趣旨の発言をされていた覚えがあります.当時は私はその方針には反対だったのですが,実際にコードを書いてみたところ,悪くない気がしてきました.
\catcode
(0--15) など,欧文 TeX のもの\cjkxcode
→後述\prebreakpenalty
, \postbreakpenalty
, \inhibitxspcode
, \xspcode
\{enable,disable,force,current}cjktoken
は不要なので未実装
\cjkxcode
c = azyx ₂ と2進表示した際の各ビットの意味は次の通り.「全文字 \cjkxcode
=0」ならばもとの XeTeX と動作は変わらないはず\jcharwidowpenalty
の挿入制御(コード中の説明は\kcatcode
は読み出しのみ可能.ご無沙汰しております。こちらも Slack で・GitHub で色々と意見だけ言っておきながらその後何も検討も動けていませんでした。もうすっかり忘れてしまったので,一から勉強し直しています。(u)pTeX 特有の重要な概念として「①和文文字トークン」「②和文文字ノード」がある中で,現在の①の挙動は expl3 とって不都合があるので,維持したい機能を残しつつ欧文文字トークンに近づけたいという話でしたね。
思いつきに過ぎなかった「XeTeX に pTeX の和文組版を載せる」を拾っていただいてありがとうございます。ざっとざっと実装を見てみましたが,整っていて綺麗だと感じました。
和文文字トークンの現在の挙動のうち,維持したいのは「(1バイト1トークンではなく)“見た目の1文字”で1トークンになる」「ノード化すると(欧文文字ノードではなく)和文文字ノードになる」ということくらい(例えば \prebreakpenalty`」=10000
のため)だと改めて思いました。実装していただいているとおり「文字トークンの段階では和文と欧文の区別はない」「\kcatcode
は実質廃止・読み出しのみ可能」「代わりに \cjkxcode
で諸々制御」で良いですね。禁則テーブルでなく文字ごとに設定可能(→ \prebreakpenalty
と \postbreakpenalty
を同時に設定できる)というのも含めて良いと思います。
e-upTeX ベースと XeTeX ベースのどちらが良いかは迷います。内部コード Unicode 固定はもう確定路線とみなすと,どちらを使っても実現はできると思えてきましたが,違いは以下くらいのことでしょうか:
(あと,XeTeX だと dvips が使えなくなって困る人も出てくるのでしょうかね)
- XeTeX ベースの場合:欧文文字ノードについて 8-bit TFM (Type1) から Unicode (OpenType) への乗換による組版変化(※ inputenc UTF-8 による 8-bit TFM 利用は XeTeX/LuaTeX では使えないんでしたよね)
styと使用例 のように,一行で「8-bit TFM の状況」,つまり
\encodingdefault
も変更の必要が?)\usepackage[utf8]{inputenc}
相当のことを \DeclareUnicodeCharacter
の再定義により実現するに戻せれば良いかな.と思いました.
XeTeX だと dvips が使えなくなって
xdv (pdf) の代わりに dvi を出力させるスイッチ -dvi
を https://github.com/h-kitagawa/texlive-source/commit/fd45512f96770163da6c7d290e1256bc22f9f829 で入れてみました.今のところは次の二点が変わるだけです:
.dvi
になり,DVI ID は(pTeX 縦組のように)preamble 側は 2,postamble 側は 3 になる\font
では 8-bit TFM(と JFM)しか使えないe-upTeX ベースと XeTeX ベースのどちらが良いかは迷います。内部コード Unicode 固定はもう確定路線とみなすと,どちらを使っても実現はできると思えてきましたが,違いは以下くらいのことでしょうか:
- e-upTeX ベースの場合:符号位置 256 以上の欧文文字ノード生成方法の用意 [nptex] 符号位置 256 以上の欧文文字トークンのノード化 #153
- XeTeX ベースの場合:欧文文字ノードについて 8-bit TFM (Type1) から Unicode (OpenType) への乗換による組版変化(※ inputenc UTF-8 による 8-bit TFM 利用は XeTeX/LuaTeX では使えないんでしたよね)
そうすると,「XeTeX ベースの npTeX + -dvi
(A)」「e-upTeX ベースの npTeX (B)」はほとんど差がないように感じます.#153 では,(B) について
そもそも \nptexnoderecipe なる仕組みを考えだしたのは,アクティブ文字 (catcode=13) がコントロールワードで使えないから.
と書いていますが,この点は (A) でも変わらない気がします.
xdv (pdf) の代わりに dvi を出力させるスイッチ
ありがとうございます。
「XeTeX ベースの npTeX +
-dvi
(A)」「e-upTeX ベースの npTeX (B)」はほとんど差がない
エンジン自体の機能およびユーザレベルでは仰る通りですね。パッケージ開発者レベルでは差があって,(A)の場合は LaTeX の随所にある「LuaTeX or XeTeX か否か」という名称判定から「Unicode フォントかどうか」という機能判定に変更して回る処置が必要と思われます。ちょうど pLaTeX が eptex から euptex -kanji-internal=euc になったことで誤判定を直して回ったばかりですが,あの時は日本側で済んだところを今度は海外に説明して回らないといけない感じはします。その点に限っては(B)に軍配が上がります。もちろん,機能的には,XeTeX ベースの npTeX の方が「-dvi
無効=欧文 Unicode フォントできる状態」も存在することの利点があるわけですが。
(A)を採る場合に「パッケージ開発者レベル〜〜〜(中略)〜〜〜海外に説明して回らないといけない」を避けるため,スイッチ -dvi
有効時に全ての \XeTeX〜 及び \Umath〜 系列プリミティブを未定義にする,というのが良さそう?
ざっと試しに動かしてみていますが,うまく動いていません。私のところでは Mac でビルドするため nptex.am をこのように改変(nptex_LDFLAGS
が肝)していますが,そのせいだとは思えず。
他,エンジンの機能上 e-upTeX との差異に気づいた点:
\documentclass{article}
\begin{document}
\tracingonline1
\showboxdepth10000
\showboxbreadth10000
和文と違って、Latinの禁則は[まだ]完全でない。
\showoutput % "[" の後の禁則ペナルティが入らない
\end{document}
今後の実装については,fam256.ch 及び \epTeXinputencoding の機能を持ってきたときに XeTeX 拡張(それぞれ \Umath〜 及び \XeTeXinputencoding)と衝突しないかが今後気になるところ。
nptex.am
- \postbreakpenalty が入らない:下記コード
確認ありがとうございます.直しました.
- 欧文 Unicode 文字ノード (whatsit) に対して
- \lastnodechar, \lastnodefont が動かない (-1, \nullfont)
こっちは一筋縄ではなさそうです.Latin\typeout{\the\lastnodechar}
のように「Unicode 文字ノードの生成が終わっている」状態だとうまく行くのですが,Latin\the\lastnodechar
のような「生成途中」だと動かないですね.
なお,同じこと \lastnodetype にも当てはまっています,
\postbreakpenalty の修正ありがとうございます。
他,不具合がおきる例は作っていませんが
@d ita_kern=3 {|subtype| of kern nodes from \.{\\/}}
@d space_adjustment=3 {|subtype| of kern nodes from \.{\\XeTeXinterwordspaceshaping} adjustment}
ここの subtype 値はずらした方が良さそうです。
あと,nptexdir/memo.txt に書かれていませんが \readpapersizespecial は未実装ですね。それと \pdfsavepos の組方向対応。
test02.tex の結果: test02-230820-hy.zip
~この理由がまだわかりません…。~
→ [edit] 2023-08-22: 何度か rebuild / fmt 再生成したらいつの間にか治りました。
欧文ノード生成途中の \the\lastnodechar が -1 の件ですが,\ifnum\lastnodechar〜も同様になります。多分 \relax 前置で生成打ち切りするのが筋でしょうけども。
[edit] 気づいたことを書いていきます。2023-08-24
$c_i\in C_i$ \bye
で Segmentation fault: 11(https://github.com/h-kitagawa/texlive-source/commit/1942650063daa1a21786b9035dd1af6d77ac196d, https://github.com/h-kitagawa/texlive-source/commit/3234f2b8c8a2bed27230799bbec0d75a7b8598e2 の両方で発生確認)ようやく動かしてためしはじめました。(Windowsは諦めてUbuntu 22.04 on WSL2)
気になったことを書いておきます。
\kcatcode`α=15
のようにkcatcode=15で欧文扱いにするみたいなことをしているコードはそこそこある気がするので互換性のためにあったほうがよいかも
\disablecjktoken
のような和文を一括で無効にする機能があると「見出しだけotfフォントを直接使ってプロポーショナル組み」みたいなことができて面白いかも
- upLaTeXで
\kcatcode`α=15
のようにkcatcode=15で欧文扱いにするみたいなことをしているコードはそこそこある気がするので互換性のためにあったほうがよいかも
自分で言っておいてなんですが、あまり意味がないような気がしてきました。 TeX Wikiのこのページの欧文の例のようなものを想定してだったのですが、cjkxcode=0にして欧文扱いするだけでは組めるようにはならないみたいなので、結局xllegacyenc.styのような追加のパッケージが必要になるのならそのパッケージで必要な文字をcjkxcode=0にする機能を提供できれば十分な気がします。
早速実装していただいたのにすみません……
* `$c_i\in C_i$ \bye` で Segmentation fault: 11([h-kitagawa/texlive-source@1942650](https://github.com/h-kitagawa/texlive-source/commit/1942650063daa1a21786b9035dd1af6d77ac196d), [h-kitagawa/texlive-source@3234f2b](https://github.com/h-kitagawa/texlive-source/commit/3234f2b8c8a2bed27230799bbec0d75a7b8598e2) の両方で発生確認)
後で調べます.
* ajmacros.sty (otf.sty) など ISO-2022-JP なファイルをそのままでは読めない * 要確認:ptexenc による文字コード変換(内部 Unicode な upTeX でも濁点・半濁点の結合文字列は合成されていたはず)が npTeX でどうなるか
XeTeX では input_line が XeTeX_ext.c で定義されていますが,ここで行われる XeTeX による Unicode 正規化やコード変換の前に)ptexenc の input_line2 に通してしまう,というのはどうでしょうか.
こういう点を見ると,e-upTeX ベースの方が「後から発覚する」トラブルが少なくなる気がしており,悩みます.TeXConf2023 で何かは(「悩んでいる」ということでもいいので)報告したいところですが…….
いろいろな検討をありがとうございます。悩ましいです。
XeTeX ベースはどうかと提案した理由は,あまり深く考えずに
という期待でしたが,安直でしたかね…。確かに,後から発覚するトラブルが少ないのは e-upTeX かもしれません。
悩みつつ要件と論点の整理中…。
`あ
」できるのに「\catcode`あ
」できない),欧文文字は「1バイト1トークン」なのに対し和文文字は「1文字1トークン」であり単位が異なる。\prebreakpenalty`」=10000
などが通る)。トークン時点での和文/欧文の区別は必須でないが,組版で生成するノードには和文/欧文の区別が必要(フォント切替)。そのとき,0x100 以上の欧文文字ノード生成方法は別途準備が必要。TeXConf2023 で何かは(「悩んでいる」ということでもいいので)報告したいところですが…….
何かしら話すきっかけになればありがたいです。
こちらこそ,整理をどうもありがとうございます.
\sys_if_xetex
= T でよい?)
\XeTeXinputencoding
, \XeTeXinputnormalization
)との折り合いが必要.ptexenc との二者択一とする?\kchar
の引数としては許されないと意味がない.adjust_hlist
のことも考えると,和文文字ノード中の「文字コード」としても許容することになるだろう.\kchardef
としては?自己レスです.
otf パッケージで使われる「0x110000 以上の文字」をどこまで許すか.
e-upTeX の main_loop において chardef トークンや \char の処理方法を見てみると,
hmode+char_given:
if check_echar_range(cur_chr) then goto main_loop
else begin cur_cmd:=kcat_code(kcatcodekey(cur_chr)); goto main_loop_j; end;
hmode+char_num: begin scan_char_num; cur_chr:=cur_val;
if check_echar_range(cur_chr) then goto main_loop
else begin cur_cmd:=kcat_code(kcatcodekey(cur_chr)); goto main_loop_j; end;
end;
のように「kcatcode を算出し,文字トークンとして扱う」ことをしています. また,#46 も考えると,「0x110000 以上の和文文字トークン」まで考えないといけないように思いました.
0x110000 以上の文字コードに対して \catcode, \prebreakpenalty, ... を設定できるようにするのは意味がないように思います,たとえば(0x400000 が境目だったとして)次のようにすると良い?
「0x110000 以上の和文文字トークン」まで考えないといけないように思いました.
個人的には 0x110000 以上の 文字トークン は無いほうがいいと思います。 これが存在すると expl3 等に特別扱いしてもらう必要が出てきてしまいます。 (例えば文字列を UTF-16 の HEX 表記(PDF 文字列)に変換するとき 0x110000 以上の文字コードのトークンがあると困ったことになる。)
ところで 0x110000 以上の 和文文字ノード は otf パッケージの \CID コマンド等で必要になりますが、0x220000 以上の文字コードって必要なんでしょうか?
気付いたことの追加:
\tracinglostchars
>= 2 のときに Character ... cannot be typeset in JIS-encoded JFM ...
のメッセージが端末に出力されない
ところで 0x110000 以上の 和文文字ノード は otf パッケージの \CID コマンド等で必要になりますが、0x220000 以上の文字コードって必要なんでしょうか?
[upTeX+dvipdfmx] 異体字セレクタ、Unicode合成文字 https://github.com/texjporg/tex-jp-build/issues/46 で述べているような構想があるのみで、いまだに実用には至っておりません。ただ、いつかは使いたいと思っており、 "reserved" のつもりです。
XeTeXのinterchartokensと和文組版機能((x)kanjiskip等)が競合しないか
実現自体はなんとかなりそうですが, XeTeX デフォルトだと,CJK 文字は \XeTeXcharclass 1, 2, 3 のどれかに割り当てられており,xetex.ini 中で
\gdef\xtxHanGlue{\hskip0pt plus 0.1em\relax} % between ideographs
\global\XeTeXinterchartoks 1 1 = {\xtxHanGlue}
\global\XeTeXinterchartoks 1 2 = {\xtxHanGlue}
\global\XeTeXinterchartoks 1 3 = {\nobreak\xtxHanGlue}
\global\XeTeXinterchartoks 2 1 = {\nobreak\xtxHanGlue}
\global\XeTeXinterchartoks 2 2 = {\nobreak\xtxHanGlue}
\global\XeTeXinterchartoks 2 3 = {\xtxHanGlue}
\global\XeTeXinterchartoks 3 1 = {\xtxHanGlue}
\global\XeTeXinterchartoks 3 2 = {\xtxHanGlue}
\global\XeTeXinterchartoks 3 3 = {\nobreak\xtxHanGlue}
と,すでにトークン列が割り当てられていることには注意が必要です(nptex.ini からこれらの行を削除するだけでよい?).
個人的には 0x110000 以上の 文字トークン は無いほうがいいと思います。
なるほど……それはそうですね.「[upTeX+dvipdfmx] 異体字セレクタ、Unicode合成文字 (#46 )」の(e-upTeX ベースか XeTeX ベースかに関わらず)npTeX での実装方法とも絡んでくるので,引き続き考えてみます.
全然ついていけておらず、少しずつ読み返しております。シロウト質問です。
多くの LaTeX パッケージのエンジン判定が「XeTeX なら OpenType フォントが使える」と思い込んでいて,欧文 8-bit TFM 対応が弱い
そうすると、"多くのLaTeXパッケージ"は、「XeTeX ベースの npTeX + -dvi (A)」ではそもそも使用できない、ということでしょうか。 "多くのLaTeXパッケージ"は、「8bit欧文tfmが使える」ようには一応なっているので「e-upTeX ベースの npTeX (B)」は使用できるであろう、ということでしょうか。
npTeX が「Unicode 1 文字から 1 トークンができる」かつ「(本文の)欧文フォントは tfmであってUnicode フォントではない」というエンジンになったとして、\sys_if_engine_xetex:p
では「本文の欧文フォントはUnicode」という前提を要求されるので"多くのLaTeXパッケージ"は動かない、ということでしょうか。
あるいは、「XeTeX ベースの npTeX + xdv, pdf出力」で「fontspec, unicode-mathは欧文のみ」が実現できれば「和文フォントはJFM」が拡張機能として混入していても、"多くのLaTeXパッケージ"が動くようなことは可能、ということでしょうか?
「日本語pLaTeX向けパッケージ」は「欧文の本文が8bit tfm」であることを要求していてnpTeXは「欧文の本文が8bit tfm」で動かしたいので、"多くのLaTeXパッケージ"にも「Unicode 1 文字から 1 トークンができる」かつ「欧文の本文が8bit tfm」に対応してもらう必要がある、ということでしょうか?
頭の中が混乱しています。
多くの LaTeX パッケージのエンジン判定が「XeTeX なら OpenType フォントが使える」と思い込んでいて,欧文 8-bit TFM 対応が弱い
これは
多くの「LaTeX パッケージのエンジン判定」が……
としたほうが良かったでした.すみません. 実際にエンジン判定があるのは,エンジンによって OpenType か 8 bit TFM か切り替える,フォント関連のパッケージが大半だと思います.
こんな感じでしょうか:
「XeTeX ベースの npTeX + -dvi (A)」かつ「エンジン判定で XeTeX と判定される」
「XeTeX ベースの npTeX + -dvi (A)」かつ「エンジン判定で XeTeX と判定しない」 →「e-upTeX ベースの npTeX (B)」と同じことになる.
「e-upTeX ベースの npTeX (B)」
\usepackage[utf8]{inputenc}
相当の機能が読み込まれないことで,このおかげで Unicode 直接入力は現行の LaTeX ではうまくいかない.従来の \ae
, \'{e}
のような命令に頼るか,自前で処理を書く必要がある.「XeTeX ベースの npTeX + xdv/pdf 出力 (A)」かつ「エンジン判定で XeTeX と判定されない」 →パッケージ側の自動判定では「e-upTeX ベースの npTeX (B)」と同じことになる.ただし手動で OpenType フォントを読み込むことは可能.
あるいは、「XeTeX ベースの npTeX + xdv, pdf出力」で「fontspec, unicode-mathは欧文のみ」が実現できれば「和文フォントはJFM」が拡張機能として混入していても、"多くのLaTeXパッケージ"が動くようなことは可能、ということでしょうか?
私はそのように考えています.
"多くのLaTeXパッケージ"にも「Unicode 1 文字から 1 トークンができる」かつ「欧文の本文が8bit tfm」に対応してもらう必要がある、ということでしょうか?
「どこまでやってもらえるか」は未知数ですが,私は必要性を感じます.
「e-upTeX ベースの npTeX (B)」でも「XeTeX ベースの npTeX + -dvi (A),ただし XeTeX と判定されない」で問題になる事象は,pdfLaTeX 用のソース
\documentclass{article}
\usepackage{times}
\begin{document}
foobar
\end{document}
を「LuaTeX の \directlua って便利そうだな」という理由からタイプセッタを lualatex に変えても意図通りにならない(フォントが Times にならない)というものと同じことです.
upTeXにcatcodeが15以下でかつCJKのトークンを追加で導入しよう、という提案です。 [upTeX] JIS-encoded TFM https://github.com/texjporg/tex-jp-build/issues/149 とは別に扱った方がよさそうなので issue を立てます。
背景はこちら。 https://github.com/texjporg/tex-jp-build/issues/149#issuecomment-1279731866
で、私の提案はこちら https://github.com/texjporg/tex-jp-build/issues/149#issuecomment-1279757248
で @aminophen さんのリプライ https://github.com/texjporg/tex-jp-build/issues/149#issuecomment-1279778635