eptex (100201) | 2010-02-01 07:10 |
eptex-test (110315) | 2011-03-15 08:56 |
ptex-qtrip (110227) | 2011-02-27 22:32 |
日本語ファイル名でエラー | 2018-05-20 23:30 |
日本語のファイル名でエラーが起こることがあります。 ptex2pdf -l -ot "-synctex=1 -file-line-error" 名称未設... | (无) |
\pdfsavepos と \mag | 2016-12-20 02:32 |
TeX & LaTeX Advent Calendar 2016 の VoD氏の記事に詳細が報告されていますように,\mag が用いられたときの \pdfsavep... | (无) |
TeX Live 2022 には pTeX p4.0.0 と e-pTeX 220214 が収録されています. 本ページでは昨年の TeX Live 2021 (pTeX p3.9.0, e-pTeX 210218) からの変更点についてざっと説明します.
詳細は上記の「関連文書」を見てもらうことにして,ここでは概要のみ説明します.
TeX では入力をトークン単位で処理することが基本になっていますが,
と,文字列化の処理が絡むことがあります.
さて,pTeX ではトークンの段階で「和文文字トークン」「欧文文字トークン」の区別がありますが,p3.9.0 以前では文字列化の過程で「和文文字」「欧文文字」の区別がありませんでした.これにより,以下のソースのように 8-bit 欧文文字(を表すバイト列)が和文文字に化けてしまうという症状がありました*1:
また,制御綴の名称についても,文字列化と類似の現象が見られ,p3.9.0 以前では
の 4 つの制御綴はいずれも同じものを指し,\expandafter\string\csname ſ\endcsname は \顛 を返しました.
pTeX p4.0.0 以降では,文字列化において「このバイト列は欧文由来」「このバイト列は和文由来」という区別をつけるようにしました.これにより,以下のソースのように「顛」「ſ」が区別されるようになりました.
上記の変更に伴い,TeX Live 2022 以降の upTeX では「ソース中の見た目は同じなのに違う制御綴を指す」ことが起こります.例を以下に示します:
この例において,8 行目では「ぁ」は和文文字扱いされないため,8 行目の \ぁ は \^^e3^^81^^81 と同じ制御綴を指します.一方,4 行目の \ぁ と 8 行目の \ぁ は違う制御綴です.
\write18 を使って外部コマンドを実行させることができます(shell-escape, *2).
この \write18 の引数は,pTeX p3.9.0 以前では pTeX の内部コードのままシェルに渡されるようになっていました. 一方,非 Windows 環境の pTeX p4.0.0 では,常に UTF-8 に変換されるようになります.この際,JIS X 0208 で表されないバイト列は {{{^^xy}} 形式に直されます.
以下に例を示します.次のファイルを -shell-escape 付きで(つまり制限なし shell-escape で)実行させます:
すると,以下のような出力が得られます:
■p3.9.0,内部コードは EUC 0000000 a4 a2 c5 bf c3 9f 2e e2 91 a0 2e c5 bf 0a 244 242 305 277 303 237 . 342 221 240 . 305 277 \n 0000016 ■p3.9.0,内部コードは SJIS 0000000 82 a0 93 5e c3 9f 2e e2 91 a0 2e c5 bf 0a 202 240 223 ^ 303 237 . 342 221 240 . 305 277 \n 0000016 ■p4.0.0,内部コードは EUC/SJIS どちらでも 0000000 e3 81 82 e9 a1 9b 5e 5e 63 33 5e 5e 39 66 2e 5e 343 201 202 351 241 233 ^ ^ c 3 ^ ^ 9 f . ^ 0000020 5e 65 32 5e 5e 39 31 5e 5e 61 30 2e 5e 5e 63 35 ^ e 2 ^ ^ 9 1 ^ ^ a 0 . ^ ^ c 5 0000040 5e 5e 62 66 0a ^ ^ b f \n 0000045
pTeX では,JIS X 0208 の範囲のファイル名しか扱うことはできません.JIS X 0208 範囲外の文字がファイル名に含まれた場合(たとえば「あſßa.tex」),
となります.
ファイル名の扱いにはまだ荒削りのところがあります.また,「既定の内部コード」*3でない状態で pTeX を動作させることも可能です
が,その場合,コマンドラインに渡すファイル名は ASCII の範囲に留めるべきです(JIS X 0208 の範囲内であっても和文文字は使えません).
pTeX 系列で「和文文字の直後の改行は何も発生しない」ということはよく知られていますが,「和文文字の直後に 1 つ以上のグループ境界 ({, }) がある」状況で行が終わっても,改行は何も発生させない(空白文字が発生しない)ことが知られています.
これに関連して,
→pTeX p3.8.1 以前では改行から空白文字が発生したが,pTeX p3.8.2 (TeX Live 2019) から何も発生しなくなった
→pTeX p3.9.0 (TeX Live 2021) 以前では改行から空白文字が発生したが,pTeX p4.0.0 (TeX Live 2022) からは既定では何も発生しなくなった
のように,和文文字と改行の扱いについては近年(今年も含め)変更が加えられています.
一方で,今回の変更の過程で,最初に述べた
という従来の挙動も自然とはいえないのではないか,という話が出てきました.結果的にはこの挙動は p4.0.0 の既定としては残りましたが,ユーザ側で挙動を変更できるように,pTeX p4.0.0 では \ptexlineendmode というプリミティブを追加しました.
\ptexlineendmode は 0--7 の値を取る(それ以外の値も代入できますが,下位 3 ビットの値しか見ません)内部整数です. 各ビットは,それぞれ以下の状況で行が終わった場合に,改行が空白文字を発生させるかを制御します(0: 発生させない,1: 発生させる):
pTeX p4.0.0 での既定値は 0(すべて発生させない)です.また
でそれぞれ再現できます.
例として,以下のソースをタイプセットした結果が \ptexlineendmode の値でどうなるかを載せておきます:
\ptexlineendmode の値 | 結果 |
0 | ◆漢字◆漢字◆あ◆い◆あ◆い◆ |
1 | ◆漢字◆漢字◆あ◆い◆あ◆い ◆ |
2 | ◆漢字◆漢字◆あ ◆い◆あ ◆い◆ |
3 | ◆漢字◆漢字◆あ ◆い◆あ ◆い ◆ |
4 | ◆漢字◆漢字 ◆あ◆い◆あ ◆い◆ |
5 | ◆漢字◆漢字 ◆あ◆い◆あ ◆い ◆ |
6 | ◆漢字◆漢字 ◆あ ◆い◆あ ◆い◆ |
7 | ◆漢字◆漢字 ◆あ ◆い◆あ ◆い ◆ |
どちらも (e-)(u)pTeX, pdfTeX, XeTeX, LuaTeX 共通に実装されたプリミティブです.
TeX では \par という名称のプリミティブは
等の特殊な役割があります.
\partokenname プリミティブは,この「特殊な役割」を持つプリミティブの名称を変更します.使用例を以下に示します.
\partokencontext プリミティブは,「特殊な役割」を持つプリミティブ(標準だと \par)の挿入箇所を制御します.
既定値は 0(つまり従来通りの動作)です.
もともと upTeX にUnicode から内部コード値への変換を行う \ucs プリミティブ がありましたが,pTeX でも取り入れました.逆の
も追加しています.pTeX では,これらは(\euc 他と同様に)JIS X 0208 の範囲のみ扱えます.
コード変換プリミティブ (\euc, \jis, \sjis, \kuten) に引数として不正な値を与えた場合,pTeX p3.9.1 以前では
など返り値が不統一でした. \ucs, \toucs 追加に伴い,\euc, \jis, \sjis, \kuten ともども
と統一しました.
欧文文字トークンと異なり,和文文字トークンについては一般に
という挙動になっています.
さて,和文文字トークンを \let したトークンについて, TeX Live 2019 リリース後のリビルド において
という変更を行いましたが,\ifx においてはそうなっておらず,不統一な状態になっていました.
\ifx についても和文カテゴリーコードを再計算するように変更することもできますが,その方針では pTeX と upTeX の差異が大きくなることから,
という以前の挙動に戻すことにしました.
TeX Live 2018 における pTeX, e-pTeX 変更点まとめ にも記述したように,pTeX 3.8.0 以降では,グローバルに,もしくは最外グループ ( \currentgrouplevel = 0) で禁則ペナルティに 0 を設定した場合は,禁則テーブルから削除するようになっています.
この禁則テーブルはハッシュテーブルの形で実装されており,たとえば \prebreakpenalty`あ=1000 という設定においては,
という順序で処理が行われています. しかし,TeX Live 2021 (p3.9.0) 以前では
という部分にバグがあり,
という現象が起こっていました.
報告元の表現を少し変えると,次のソースが segmentation fault して落ちるというものです:
欧文文字(の連続)の周囲には pTeX が自動で disp_node を補いますが,段落の行分割を行う際に「余計な末尾の disp_node を消去する」という処理があります.しかし,上記のソースを処理すると,
ことになってしまい,これが segmentation fault の元になっていました.
128--255 番の文字に対して \mathcode の値の設定はされているものの,実際の数式モードではその値が反映されなかったという問題です.たとえば,以下のソースが例になります:
日本語化パッチの該当部分が TeX 2(7 ビット入力のみ対応していた)の頃のままになっており,数式モードで入力された 128--255 番の文字が「\mathcode はその文字の文字コードの値」のように扱われていたのが原因です.
e-(u)pTeX, pdfTeX, XeTeX, LuaTeX 共通に実装されたプリミティブで,以下の \show... 系プリミティブ
の出力先を端末・ログファイルから別ファイルに変更するためのものです.
TeX は,同時に 0--15 の 16 個の入出力ストリームを持つことができます.TeX からファイルに入出力を行う際は,
のように行います*4.
今回の \showstream にストリーム番号を指定することで,\show... 系プリミティブの結果の出力先がその番号のストリームになります.ただし,0--15 以外の値や,(\show... 実行時に)その番号のストリームが出力ストリームとしてオープンされていなかった場合は,既定の「端末に出力する」挙動に戻ります. 以下が使用例です.
- \def\cs{foo\tenrm testあいう}
- \scrollmode
- \show\cs %==> macro:->foo\tenrm testあいう
- \showthe\baselineskip %==> 12.0pt
- \message{OPENIN}
- \openin1=sst2.txt
- \showstream=1 % 入力ストリームなので効力なし
- \show\cs\showthe\baselineskip
- \closein1
- \message{OPENOUT}
- \immediate\openout1=sst.txt
- \showstream=1
- \show\cs\showthe\baselineskip% sst.txt に出力される
- \immediate\closeout1
- \message{18.}
- \showstream18 % デフォルトの挙動に戻る
- \show\cs\showthe\baselineskip
- \message{-1.}
- \showstream-1 % デフォルトの挙動に戻る
- \show\cs\showthe\baselineskip
- \bye
\vadjust{ vertical material } プリミティブを使うことで「現在の行の直後」に vertical material を挿入することができることはよく知られています.
さらに pdfTeX, XeTeX, LuaTeX では \vadjust pre{ vertical material } とすることで「現在の行の直前」にvertical material を挿入することができるようになっていますが,これが e-pTeX にも追加されました. なお,前の行に \vadjust が,次の行に \vadjust pre があった場合は
の順序で組まれます.
LuaTeX に実装されている次のエラー抑止のためのプリミティブを実装しました:
既定値はいずれも 0(つまり従来通りの動作)です.
詳しくは TeX & LaTeX Advent Calendar 2021 の私の記事「e-(u)pTeX をいじってみた話」前半部の「ネタ 1」を参照してください.
文字コードと同様に,「最後の和文文字のフォント」を知る方法は現時点ではなく,新たに \lastnodefont とでもいう命令を作る以外にないでしょう
と書きましたが,(e-)upTeX においては「文字コードが 256 未満の和文文字ノード」が存在する関係で,\lastnodechar の値だけでは最後の文字が和文か欧文か判別できませんでした.これを解決するため,e-pTeX の段階で \lastnodefont が追加されました.
数式モードにおいては,e-TeX 拡張の「現在構築中のリストの最後のノードの種別」を与える \lastnodetype の値はみな 15 (math mode nodes) であり,ほとんど意味をなしていませんでした. e-pTeX では \lastnodetype を補完する \lastnodesubtype プリミティブがありますが,数式モードではこれもほぼ役に立ちませんでした.
e-pTeX 210701 以降では,数式モードにおいて \lastnodesubtype が「意味のある」情報を返すようにしました. 詳細は e-pTeX のマニュアルを見てもらうことにして,一部を述べると以下のようになります:
値 | 意味 |
1 | \mathchoice |
2 | \mathord |
3--5 | \mathop(\displaylimits, \limits, \nolimits で異なる値) |
6 | \mathbin |
7 | \mathrel |
8 | \mathopen |
9 | \mathclose |
10 | \mathpunct |
11 | \mathinner |