From e7ae872926eddb0de09ecfe1c578e0680033955a Mon Sep 17 00:00:00 2001
From: Norbert Preining <norbert@preining.info>
Date: Sun, 26 Feb 2023 03:02:12 +0000
Subject: CTAN sync 202302260302

---
 info/ptex-manual/ptex-manual.tex | 359 ++++++++++++++++++++++++++++-----------
 1 file changed, 258 insertions(+), 101 deletions(-)

(limited to 'info/ptex-manual/ptex-manual.tex')

diff --git a/info/ptex-manual/ptex-manual.tex b/info/ptex-manual/ptex-manual.tex
index 2b11bd6e95..d60664c459 100644
--- a/info/ptex-manual/ptex-manual.tex
+++ b/info/ptex-manual/ptex-manual.tex
@@ -51,7 +51,6 @@
 
 \frenchspacing
 \begin{document}
-\catcode`\<=13
 \title{\emph{\pTeX マニュアル}}
 \author{日本語\TeX 開発コミュニティ\null
 \thanks{\url{https://texjp.org},\ e-mail: \texttt{issue(at)texjp.org}}}
@@ -115,7 +114,7 @@ EUC-JP，Shift-JIS，ISO-2022-JPのどれか一つのファイルしか処理で
 % これも最初からではなく p2.1.5 (1997年) 以降のようで，
 % それまではスタイルファイルも EUC や SJIS にしておく必要があったようです．
 |-kanji| オプションが追加され，一つの\pTeX バイナリで複数の文字コードを
-選択処理できるようになったのは\pTeX~p3.0.1とp3.0.4の間（2002年10月頃）である．
+選択処理できるようになったのは\pTeX~3.0.1と3.0.4の間（2002年10月頃）である．
 % http://tutimura.ath.cx/ptexlive/?ptexenc%2FDetails
 % の土村さんのコメント (2008-02-23) より
 
@@ -147,7 +146,7 @@ ptetex\footnote{土村展之さんによって2004年から2009年まで開発
    利用可能な<encoding>の値：\code{euc}, \code{sjis}
   \end{quotation}
 \end{itemize}
-このとおり，\pTeX への入力を仮にUTF-8としても，
+この通り，\pTeX への入力を仮にUTF-8としても，
 必ずEUC-JPかShift-JISのいずれかの内部コードに変換されるため，
 \emph{\pTeX はJIS~X~0208外の文字をサポートしない}．
 
@@ -180,7 +179,7 @@ virtual modeでは，起動直後にバナーを表示してから，フォー
 内部コードの整合性が確認される．ここでもし合致しなかった場合は，\pTeX は
 警告を表示してフォーマットに合った内部コードを選択し，以降の処理を行う．
 ログファイルはこの後にオープンされるため，そこには正しい内部コード
-（フォーマットと同じ内部コード）が書き込まれる\cite{build55}．
+（フォーマットと同じ内部コード）が書き込まれる\cite{tjb55}．
 
 このようなウソは，\pTeX に限らず\code{(preloaded format=***)}でも見られる．
 \end{dangerous}
@@ -230,13 +229,17 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
   EMダーシ(\code{U+2014})は同一視され，内部的にはJISコード\code{"213D}と
   して扱われ，ファイルに書き出される時は\code{U+2015}になる．}
  \item BOMの無視（ファイル先頭に限らず）
- \item 濁音・半濁音の合字処理
+ \item 結合濁点(\code{U+3099})・半濁点(\code{U+309A})の合字処理
  \item JISに変換できない文字を|^^ab|形式に変換
   \footnote{例えば，ソースファイル中にçのような欧文文字を直接書くと，
   これは和文文字の内部コードに変換できないため|^^c3^^a7|に変換される．}
 \end{itemize}
 なお，UTF-8ファイル出力時にはこのような加工の逆変換は行わない（入力時に
 加工されたままで出力される）．
+% 注意：結合濁点・結合半濁点は TL2015 までは pTeX のみ合字処理されていたが，
+% TL2016 以降は内部 Unicode の upTeX でも合字処理するようになった．
+% https://zrbabbler.hatenablog.com/entry/20151006/1444134044
+% https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=1701
 
 このように\emph{\pTeX は入力を内部コードに変換する処理を含むため，
 オリジナルの\TeX や\pdfTeX などの欧文\TeX とは入力に関して必ずしも
@@ -289,20 +292,32 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
 \end{description}
 
 \section{和文文字と\.{kcatcode}}
-\TeX82では，各文字に0--15のカテゴリーコードを割り当てており，
+\TeX82では各文字に0--15のカテゴリーコードを割り当てており，
 \TeX82の入力プロセッサは「どのカテゴリーコードの文字が来たか」で状態が遷移する
 有限オートマトンとして記述できる(\cite{topic})．
-\pTeX では，和文文字には
+\pTeX においても同様であり，和文文字には
 16~($\mathit{kanji}$), 17~($\mathit{kana}$), 18~($\mathit{other\_kchar}$)の
-カテゴリーコードのいずれかが割り当てられている，
+カテゴリーコードのいずれかを割り当てることで拡張している．
 
-また，\pTeX~p4.0.0での入力プロセッサは
-\ref{sec:ptex_input}節で述べるように\TeX82のそれを拡張したものになっている．
-後の\autoref{fig:ptex_input}を見れば分かるように，
-（欧文文字直後の改行は空白文字扱いされるのと対照的に）
-\emph{和文文字直後の改行は何も発生しない}．
-これは，日本語の原稿内では自由な箇所で改行が行えたほうが便利なためである．
-% jtexdoc.tex に記載あり
+\begin{cslist}
+  \csitem[\.{kcatcode} <character code>=<16--18>]
+  コミュニティ版\pTeX では，和文文字のカテゴリーコード(|\kcatcode|)は
+  DVI中の上位バイトごと（すなわち，JISコードでいう区ごと）に値が設定可能である
+  \footnote{%
+    オリジナルのアスキー\pTeX では，内部コードの上位バイトごとに値が設定可能であった．
+    すなわち，内部コードがEUC-JPのときは区ごとに設定可能であったが，
+    内部コードがShift-JISのときは
+    $2n-1$区・$2n$区($1\leq n\leq 47$)は同一のカテゴリーコードを持つことになる．
+  }．初期状態では，
+  1,~2, 7--15, 85--94区の文字の|\kcatcode|は18，3--6区の文字は17，
+  16--84区の文字は16に設定されている\footnote{初期値はアスキー\pTeX を踏襲している．}．
+\end{cslist}
+\begin{dangerous}
+  |\kcatcode|では欧文文字の文字コード(0--255)も指定することができるが，
+  その場合「0区扱い」として扱われる．
+  \pTeX の処理でこの「0区」の|\kcatcode|が使われることはないので，
+  事実上は「16--18のどれかを格納可能な追加レジスタ」程度の使い方しかない．
+\end{dangerous}
 
 和文文字のカテゴリーコードの値による動作の違いは次のようになる：
 \begin{itemize}
@@ -314,7 +329,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
     \footnote{「|\】|」のような和文のコントロールシンボルで行が終わった場合，
     「|\!|」のような欧文コントロールシンボルと同様に改行由来の空白が追加されてしまい，
     和文文字直後の改行は何も発生しないという原則に反していたが，
-    これは\TeX~Live 2019の\pTeX~p3.8.2で修正された(\cite{build37})．}．
+    これは\TeX~Live 2019の\pTeX~3.8.2で修正された(\cite{tjb37})．}．
   \item 後で説明する|\jcharwidowpenalty|は，カテゴリーコードが16,~17の和文文字の前にのみ
     挿入されうるもので，カテゴリーコードが18の和文文字の前には挿入されない．
   \item 欧文文字は\TeX82と同様に1つの文字トークンはカテゴリーコード$c$と文字コード$s$の組
@@ -324,59 +339,45 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
     含まれるようになった．}．
 \end{itemize}
 
-\begin{cslist}
-  \csitem[\.{kcatcode} <character code>=<16--18>]
-  コミュニティ版\pTeX では，和文文字のカテゴリーコード(|\kcatcode|)は
-  DVI中の上位バイトごと（すなわち，JISコードでいう区ごと）に値が設定可能である
-  \footnote{%
-    オリジナルのアスキー\pTeX では，内部コードの上位バイトごとに値が設定可能であった．
-    すなわち，内部コードがEUC-JPのときは区ごとに設定可能であったが，
-    内部コードがShift-JISのときは
-    $2n-1$区・$2n$区($1\leq n\leq 47$)は同一のカテゴリーコードを持つことになる．
-  }．初期状態では，
-  1,~2, 7--15, 85--94区の文字の|\kcatcode|は18，3--6区の文字は17，
-  16--84区の文字は16に設定されている．
-
-  \pTeX においては，|\kcatcode|を上記の初期状態から変更することは想定されていない．
-  また，変更したとしても，（先に述べた通り）和文文字トークンにカテゴリーコードの情報は
-  保存されず，和文文字が処理対象となるたびにカテゴリーコードの値が再取得される．
-  ただし，|\let\CS=あ| などとして和文文字トークンを|\let|すると，|\CS|には
-  その時のカテゴリーコード(|\kcatcode|)が保存される\footnote{コミュニティ版\pTeX では，
-  一時的に「和文文字トークンを|\let|した|\CS|においても，それが処理対象となるたびに
-  カテゴリーコードの値を再取得する」という挙動に変更しようとした(r51021)．
-  しかし，この変更が不完全で「|\ifcat|では再取得するが，|\ifx|では再取得しない」という
-  不統一な状態となってしまったため，r59699で従来の挙動に戻した（アスキー版と同じ）．
-  結果的に，\TeX~Live 2019--2021では「ただし，…」が当てはまらない(\cite{man4})．}．
-  % 不統一な挙動になっているのは以下のバージョン．
-  %   * TeX Live 2019 rebuild 2019-05-30 (p3.8.2)
-  %   * TeX Live 2020 (p3.8.3)
-  %   * TeX Live 2021 (p3.9.0)
-\end{cslist}
+\pTeX においては，|\kcatcode|を上記の初期状態から変更することは想定されていない．
+また，変更したとしても，和文文字トークンにカテゴリーコードの情報は保存されず，
+和文文字が処理対象となるたびにカテゴリーコードの値が再取得される（この点が
+\upTeX との実装上の最大の差異である．
+ただし，\pTeX でも |\let\CS=あ| などとして和文文字トークンを|\let|すると，|\CS|には
+その時のカテゴリーコード(|\kcatcode|)が保存される\footnote{コミュニティ版\pTeX では，
+一時的に「和文文字トークンを|\let|した|\CS|においても，それが処理対象となるたびに
+カテゴリーコードの値を再取得する」という挙動に変更しようとした(r51021)．
+しかし，この変更が不完全で「|\ifcat|では再取得するが，|\ifx|では再取得しない」という
+不統一な状態となってしまったため，r59699で従来の挙動に戻した（アスキー版と同じ）．
+結果的に，\TeX~Live 2019--2021では「ただし，…」が当てはまらない(\cite{man4})．}）．
+% 不統一な挙動になっているのは以下のバージョン．
+%   * TeX Live 2019 rebuild 2019-05-30 (p3.8.2)
+%   * TeX Live 2020 (p3.8.3)
+%   * TeX Live 2021 (p3.9.0)
 \begin{dangerous}
-  例えば，以下のコードで定義される|\X|, |\Y|で引数終端を示す「あ」には
-  カテゴリーコードの情報は格納されない．
-  そのため，\pTeX では|\X|,~|\Y|は全く同じ動作となる．
+  例えば，\pTeX では以下のコードで定義される|\X|,~|\Y|で引数終端を示す「あ」には
+  カテゴリーコードの情報は格納されないため，|\X|と|\Y|は全く同じ動作となる．
+  一方，同じコードを\upTeX で実行すると，|\X|と|\Y|は異なる動作となる．
 \begin{verbatim}
   \kcatcode`あ=16
   \def\X#1あ{\message{X: #1}}
   \kcatcode`あ=17
   \def\Y#1あ{\message{X: #1}}
 \end{verbatim}
-  なお，\upTeX では|\kcatcode|は大きく仕様変更されており，
-  |\X|と|\Y|は異なる動作となる．
 \end{dangerous}
 
-\begin{dangerous}
-  |\kcatcode|では欧文文字の文字コード(0--255)も指定することができるが，
-  その場合「0区扱い」として扱われる．
-  \pTeX の処理でこの「0区」の|\kcatcode|が使われることはないので，
-  事実上は「16--18のどれかを格納可能な追加レジスタ」程度の使い方しかない．
-\end{dangerous}
+和文カテゴリーコード\.{kcatcode}の値は一応，
+16が「漢字」，17が「かな」，18が「その他の和文記号」を意図している．
+ただし区の中身を見れば分かる通り，\pTeX では特に
+全角数字・アルファベット（3区）とギリシャ文字（6区）も17であり，
+キリル文字（7区）は18となっている．
+すなわち\emph{\pTeX の既定では
+コントロールワードに全角数字・アルファベット・ギリシャ文字を含めることができるが，
+キリル文字は不可（コントロールシンボルのみ）である}（\upTeX の既定では全て不可）．
+% upTeX の既定では，全角数字とアルファベット(Halfwidth and Fullwidth Forms)・
+% ギリシャ文字・キリル文字の全てが18である．
 
 \subsection{\pTeX の入力プロセッサ【\pTeX~4.0.0での改修を含む】}\label{sec:ptex_input}
-\TeX82の入力プロセッサは有限オートマトンとして記述できる．\pTeX においてもその点は
-変わらないが，和文文字絡みで拡張されたものになっている．
-
 \begin{figure}[tb]
 \small
 \[
@@ -423,11 +424,12 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
     ``$5\tpar$''のような下付き添字は「挿入するトークン」を表す．\\
     但し，``$9\tign$'', ``$10\tign$''はその文字を無視することを示している．
   }
-  \caption{\pTeX~p4.0.0（既定）の入力プロセッサの状態遷移図}
+  \caption{\pTeX~4.0.0（既定）の入力プロセッサの状態遷移図}
   \label{fig:ptex_input}
 \end{figure}
 
-\autoref{fig:ptex_input}は\emph{\pTeX~p4.0.0既定時}における入力プロセッサの状態遷移図である．
+先に述べた通りであるが，\pTeX の入力プロセッサは\TeX82のそれを拡張したものになっている．
+\autoref{fig:ptex_input}は\emph{\pTeX~4.0.0既定時}における入力プロセッサの状態遷移図である．
 \TeX82から拡張された点，および説明が必要な点を以下に述べる．
 \begin{description}
   \item[内部状態の追加] \TeX82 では状態\textit{N} (new line)，状態\textit{M} (middle of line)，
@@ -449,6 +451,11 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
   \end{itemize}
 \end{description}
 
+図を見れば分かる通り，（欧文文字直後の改行は空白文字扱いされるのと対照的に）
+\emph{和文文字直後の改行は何も発生しない}．
+これは，日本語の原稿内では自由な箇所で改行が行えたほうが便利なためである．
+% jtexdoc.tex に記載あり
+
 実際には以下に説明する\.{ptexlineendmode}プリミティブによって，\pTeX の入力プロセッサの挙動は
 ある程度ユーザが制御できる．
 
@@ -474,7 +481,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
     和文文字の直後にグループ開始・終了が1つ以上
   \end{description}
 
-  このプリミティブは\pTeX~p4.0.0で追加された．既定値は0（つまり$x=y=z=0$）．
+  このプリミティブは\pTeX~4.0.0で追加された．既定値は0（つまり$x=y=z=0$）．
 \end{cslist}
 \begin{dangerous}
   「和文文字からなるコントロールシンボルの直後にグループ開始・終了が1つ以上ある」状態で行が終了した場合，
@@ -656,10 +663,10 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
 
   なお，以前の\pTeX の入力プロセッサの挙動は
   \begin{itemize}
-    \item \pTeX~p3.8.1以前（アスキー版も同じ）の挙動は|\ptexlineendmode=3|~($(x,y,z)=(1,1,0)$)
-    \item \pTeX~p3.8.2以降p3.10.0まで挙動は|\ptexlineendmode=1|~($(x,y,z)=(1,0,0)$)
+    \item \pTeX~3.8.1以前（アスキー版も同じ）の挙動は|\ptexlineendmode=3|~($(x,y,z)=(1,1,0)$)
+    \item \pTeX~3.8.2以降3.10.0までの挙動は|\ptexlineendmode=1|~($(x,y,z)=(1,0,0)$)
   \end{itemize}
-  としてそれぞれ再現できる(\cite{build87})．
+  としてそれぞれ再現できる(\cite{tjb87})．
 
 % * 欧文文字直後の改行では空白文字を発生させる
 %     * コントロールワードや「\ 」の直後の改行は何も発生しない
@@ -684,7 +691,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
     \footnote{「|\】|」のように和文文字からなるコントロールシンボルを文字列化する際に，
       バージョンp3.7.2以前の\pTeX では「|\】 |」と後ろに余計な空白文字を補ってしまう
       という問題があった．
-      \TeX~Live 2018の\pTeX~p3.8.1でこの問題は修正された(\cite{build37})．}．
+      \TeX~Live 2018の\pTeX~3.8.1でこの問題は修正された(\cite{tjb37})．}．
   \item 和文文字はそのカテゴリーコードによらず，|\meaning|すると
     \begin{itemize}% すべて "kanji character " になる
       \item \the\kcatcode`漢:\quad \texttt{\meaning 漢}
@@ -698,7 +705,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
 文字列化や制御綴名において和文文字と欧文文字の区別が失われてしまうケースがあった．
 % 途中の結果を一旦配列 |str_pool| に格納する処理で和欧文の区別が失われていた．
 \pTeX~4.0.0以降（\TeX~Live 2022）では，この状況でも
-和欧文の区別が維持される\cite{build81}．
+和欧文の区別が維持される\cite{tjb81}．
 \begin{dangerous}
 \TeX~Live 2021では，ファイル文字コードUTF-8，内部コードEUC-JPの場合に例えば
 \begin{verbatim}
@@ -722,7 +729,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
   「\code{\meaning\耽}」% 和欧文が区別されるので "P" になるはず
 となる．
 % メモ：上の例は「^^c5^^bf <=> 顛」でもよかったのだが，
-% マニュアルの欧文フォント newtx/newtx で表示可能な文字にした．
+% マニュアルの欧文フォント newtx/newpx で表示可能な文字にした．
 % 外部ファイル出力の変化例：
 %   \label{ß}%        % TL2021: <C3>^^9f => TL2022: ^^c3^^9f
 %   \label{^^c3^^9f}% % TL2021: <C3>^^9f => TL2022: ^^c3^^9f
@@ -815,10 +822,10 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
 \.{lastpenalty}で取得できるし，\.{unpenalty}で取り除くこともできる
 \footnote{以前の\pTeX では，\.{unpenalty}したはずの
 和文文字の後方の\.{postbreakpenalty}が復活してしまう場合があったが，
-2017-04-06のコミット(r43707)で修正された\cite{build11}．}．
+2017-04-06のコミット(r43707)で修正された\cite{tjb11}．}．
 % ただ，JFMグルーが後方に挿入される和文文字では上手くいかない．
 % https://github.com/texjporg/tex-jp-build/issues/67
-しかし，上述のとおり，欧文文字に設定された\.{postbreakpenalty}は
+しかし，上述の通り，欧文文字に設定された\.{postbreakpenalty}は
 後に和文文字が連続して初めて挿入されるため，
 \.{lastpenalty}で取得できないし，\.{unpenalty}で取り除くこともできない．
 
@@ -829,10 +836,12 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
 同一の文字に対して|\prebreakpenalty|と|\postbreakpenalty|の両方を
 同時に与えるような指定はできない
 （もし両方指定された場合，後から指定されたものに置き換えられる）．
-禁則テーブルには256文字分の領域しかないので，
-禁則ペナルティを指定できる文字数は最大で256文字までである．
+禁則テーブルには1,024文字分の領域しかないので，
+禁則ペナルティを指定できる文字数は最大で1,024文字までである
+\footnote{最大1,024文字となったのは\TeX~Live 2023 (r65236--65248)以降．
+なお，\TeX~Live 2022までは256文字までの領域しかなかった．}．
 
-禁則テーブルからの登録の削除は以下の時に行われる\cite{build26,build57}：
+禁則テーブルからの登録の削除は以下の時に行われる\cite{tjb26,tjb57}：
 \begin{itemize}
  \item ペナルティ値0をグローバルに（つまり，|\global|を用いて）
   設定した場合．
@@ -996,7 +1005,9 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
     \item[2] 和文文字の前側にのみ|\xkanjiskip|の挿入を許可する．後側は禁止．
     \item[3] 和文文字の前側，後側ともに|\xkanjiskip|の挿入を許可する．
   \end{description}
-  この|\inhibitxspcode|の設定値の情報は256文字分のテーブルに格納されている，
+  この|\inhibitxspcode|の設定値の情報は1,024文字分のテーブルに格納されている
+  \footnote{最大1,024文字となったのは\TeX~Live 2023 (r65236--65248)以降．
+  なお，\TeX~Live 2022までは256文字分のテーブルしかなかった．}．
   未登録時は3（両側許可）であるとみなされ，またグローバルに3を代入するか，あるいは
   最も外側のグループで3を代入するとテーブルからの削除が行われる
   （禁則テーブルからの削除と同様の規則）．
@@ -1055,8 +1066,8 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
 \end{verbatim}
 \end{itemize}
   以前の\pTeX では「この命令が実行された位置」が何を指すのか大雑把でわかりにくかったが，
-  \TeX~Live 2019の\pTeX~p3.8.2以降では，明確に\emph{新たなノードが追加されない限り}，と
-  定めた(\cite{build28,forum_2566})．すなわち，
+  \TeX~Live 2019の\pTeX~3.8.2以降では，明確に\emph{新たなノードが追加されない限り}，と
+  定めた(\cite{tjb28,forum_2566})．すなわち，
   \begin{enumerate}
     \item |\inhibitglue|は，ノード挿入処理を行う命令
     (|\null|,~|\hskip|, |\kern|, |\vrule|,~\dots)が後ろに来た場合は無効化される．
@@ -1098,7 +1109,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する
 \begin{cslist}
 \csitem[\.{disinhibitglue}]
   |\inhibitglue|の効果を無効化（つまり，メトリック由来の空白の挿入を許可）する．
-  \pTeX~p3.8.2で新しく追加された．
+  \pTeX~3.8.2で新しく追加された．
 \end{cslist}
 
 
@@ -1291,7 +1302,7 @@ DtoU方向での数式ディレクションはそれぞれ非数式の場合と
  二重にベースライン補正がされる
 \end{quote}
 という問題が起きてしまう．この問題を解決するための命令が以下の3つの命令であり，
-\pTeX~p3.7\footnote{\TeX~Live 2016，厳密には2016-03-05のコミット(r39938)．}で追加された．
+\pTeX~3.7\footnote{\TeX~Live 2016，厳密には2016-03-05のコミット(r39938)．}で追加された．
 \begin{cslist}
  \csitem[\.{textbaselineshiftfactor}=<number>,
   \.{scriptbaselineshiftfactor}=<number>]\vspace{-\itemsep}
@@ -1384,6 +1395,7 @@ JFMファイルもTFMファイルと同様の情報を持つが，
        和文の縦組用フォントのいずれも
        |\font|, |\jfont|, |\tfont|のどれを用いても定義できる
        （要求された実際のTFM/JFMに応じて，自動的にアサインされる）．
+       書式については後述．
  \item |\the|等で「現在のフォント」を取得する際には，
        |\jfont|で「和文の横組用フォント」を，
        |\tfont|で「和文の縦組用フォント」を返す．
@@ -1396,7 +1408,7 @@ JFMファイルもTFMファイルと同様の情報を持つが，
 
 \begin{dangerous}
   細かい話をすれば，\pTeX のini modeでのフォーマット作成時に和文フォントを
-  何も選択しなければ，|\fontname\jfont|が|\nullfont|となり，
+  何も選択しなければ，|\fontname\jfont|が|nullfont|となり，
   また和文文字を入力してもノードは作られない\footnote{ただし，
   $\.{tracinglostchars}>0$でも
   \code{Missing character: There is no あ in font nullfont!}のような
@@ -1411,6 +1423,98 @@ JFMファイルもTFMファイルと同様の情報を持つが，
   % https://twitter.com/zr_tex8r/status/1098594165573722112
 \end{dangerous}
 
+なお，\pTeX~4.1.0以降では\.{font}, \.{jfont}, \.{tfont}のいずれも
+フォントを定義する際の書式が拡張されている．
+\begin{itemize}
+ \item \TeX82書式：
+   \.{font}<control sequence><equals><file name><at clause>
+ \item (u)\pTeX 書式：
+   \.{font} [<in spec>] <control sequence><equals><file name><at clause>
+\end{itemize}
+なお，ここで
+\begin{itemize}
+ \item <in spec> $\longrightarrow$ |in| <encoding>
+ \item <at clause> $\longrightarrow$ |at| <dimen> $\OR$ |scaled| <number> $\OR$ <optional spaces>
+\end{itemize}
+であり，追加された<in spec>は
+「和文フォントを定義したJFMがJISエンコードであるかUnicodeエンコードであるか」
+を明示的に指定する場合に用いる．指定可能な<encoding>は|jis|, |ucs|に限られる．
+この書式を用いることで，例えば
+\begin{itemize}
+ \item \pTeX（内部コード|euc|または|sjis|）でも
+   \verb|\font in ucs \myfontA=upjisr-h|により\upTeX 用JFMである
+   |upjisr-h.tfm| (UCS-encoded)を，
+ \item \upTeX（内部コード|uptex|すなわちUnicode）でも
+   \verb|\font in jis \myfontB=min10|により\pTeX 用JFMである
+   |min10.tfm| (JIS-encoded)を，
+\end{itemize}
+それぞれ（エンジン内部でJIS⇔Unicode変換を行いながら）読み込んで
+正しくグルー・カーンを挿入できるし，DVIへの出力時にも（逆変換により）
+指定されたエンコードで文字を出力する
+\footnote{この新書式を導入した目的は，
+将来\upTeX の内部コードがUnicode固定になった場合に
+字幅やグルー・カーンが定義された\pTeX 用JFM/VFセットを
+\upTeX 用に用意しなおさなくても済むようにするためである\cite{tjb149}．}．
+% 明示指定された文字コードが実際のJFMに合致するかの自動判定は行わない．
+% また，\pTeX での in jis 指定・\upTeX での in ucs 指定は冗長であると
+% ともに，現在の実装コードでは文字クラス(char\_type)の検索が遅くなる．
+% これは\pTeX の実装はJFMフォーマットの仕様の「char\_typeテーブル内には
+% 文字コードの昇順で収められていなければならない」という規定を前提に
+% 検索最適化されているのに対し，文字コード変換が絡むと順番が崩れるためである．
+
+\begin{dangerous}
+  \pTeX で\verb|\font in ucs ...|により\upTeX 用JFMを読み込んでも，
+  JIS~X~0208外の文字が出力できるわけではない．
+  また，\upTeX で
+\begin{verbatim}
+\kcatcode"D8=16\relax % JIS範囲外の文字(Latin-1 Supplement)を和文扱いに
+\font in jis\x=jis \x <文字> % 例えば U+00D8 など
+\end{verbatim}
+  のように文字コードJISのフォント指定下で範囲外の文字を使うと，
+  DVI出力中（|\shipout|時）に
+\begin{verbatim}
+Character <文字> ("D8) cannot be typeset in JIS-encoded JFM jis,
+so I use .notdef glyph instead.
+\end{verbatim}
+  という警告\footnote{この警告も\.{tracinglostchars}に従う．
+  Missing character警告と違ってノードは破棄されないのでlostという
+  名称は微妙だが…．また，JIS範囲外の警告が発生するタイミングは
+  Missing character警告（ノード生成失敗時に発生）とは異なるので，
+  \.{shipout}時の\.{tracinglostchars}の値に依ることになる．}が発生し，
+  DVIには豆腐（\verb+set2 0+）が書かれる．
+\end{dangerous}
+
+\begin{dangerous}
+  なお，\TeX82における読込済フォントの判定
+  （「同じTFMファイル名」かつ「同じサイズ」）は
+  (u)\pTeX でも変更していないため，
+  文字コード無指定・\verb+in jis+指定・\verb+in ucs+指定だけを変えて
+  複数回読み込もうとしても，新しいフォント識別子(font identifier)は
+  発行されないし，最初のエンコードが常に使われる．
+\begin{verbatim}
+%#!ptex
+\font\xA=min10
+\font in jis\xB=min10 % => min10 は無指定時のエンコードのまま
+\font in ucs\xC=min10 % => min10 は無指定時のエンコードのまま
+\end{verbatim}
+\begin{verbatim}
+%#!ptex
+\font in ucs\yA=umin10
+\font\yB=umin10 % => umin10 は Unicode のまま
+\font in jis\yC=umin10 % => umin10 は Unicode のまま
+\end{verbatim}
+\end{dangerous}
+
+\begin{dangerous}
+  欧文フォントに対する<in spec>は意味を持たないので，単に無視される．
+  また\.{font}, \.{jfont}, \.{tfont}の直後が|in|でないか
+  <encoding>が|jis|, |ucs|以外の場合は
+\begin{verbatim}
+! Missing control sequence inserted.
+\end{verbatim}
+  というエラーが発生する（\TeX82と同じ挙動）．
+\end{dangerous}
+
 \begin{cslist}
 \csitem[\.{ifjfont} <\,font>, \.{iftfont} <\,font>]
   |\ifjfont|は<font>が和文の横組用フォントかどうか，
@@ -1432,7 +1536,7 @@ JFMファイルもTFMファイルと同様の情報を持つが，
 \end{cslist}
 
 \begin{dangerous}
-  上述のとおり，欧文フォント・和文の横組用フォント・
+  上述の通り，欧文フォント・和文の横組用フォント・
   和文の縦組用フォントのいずれも|\font|一つで定義可能だが，
   定義したフォントが実際にどの種類だったかを知る手段は
   バージョンp3.8.2までの\pTeX には存在しなかった．
@@ -1447,7 +1551,6 @@ JFMファイルもTFMファイルと同様の情報を持つが，
   「\verb+! Bad character code (...).+」エラーが発生するからである．
 \end{dangerous}
 
-
 \begin{cslist}
 \csitem[\.{jfam}=<number>]
   現在の和文数式フォントファミリの番号を格納する
@@ -1468,6 +1571,59 @@ JFMファイルもTFMファイルと同様の情報を持つが，
 ! Not one-byte family.
 \end{verbatim}
   というエラーが発生する．
+
+\csitem[\.{ptextracingfonts} (integer)]
+  |\tracingoutput=1|のときに意味を持つパラメータで，
+  これは元来|\shipout|時にログに出るものであるから，
+  「|\shipout|時点での値」によって以下の情報を表示する．
+  \pTeX~4.1.0で導入された．
+ \begin{itemize}
+  \item 値を1以上に設定すると，\pdfTeX の|\pdftracingfonts|と同じ書式で
+   フォント名とサイズを表示する（font expansionには非対応）．
+   % LuaTeX にも \tracingfonts はあるが LaTeX の \tracingfonts と衝突
+   % XeTeX の \XeTeXtracingfonts は読込フォントの所在ディレクトリを返す別物
+  \item 値を2以上に設定すると，追加で(u)\pTeX 特有の以下の情報を表示する．
+   \begin{itemize}
+    \item 和文フォント(JFM)の横組(|/YOKO|)・縦組(|/TATE|)の区別
+    \item 明示的なエンコード指定（\verb+in jis+ → |+JIS| / \verb+in ucs+ → |+Unicode|）
+   \end{itemize}
+ \end{itemize}
+  書式は以下のようになる．
+ \begin{itemize}
+  \item 欧文フォントの場合
+    \footnote{サイズがTFMデザインサイズと同じ場合は|@サイズ|が省略される．}
+    $\rightarrow$ |ファイル名@サイズ|
+  \item 和文フォントの場合
+    \footnote{サイズについては欧文フォントと同様．
+      和文フォントでは|/YOKO|又は|/TATE|のいずれか一方が\emph{常に}表示される．
+      また文字コード無指定の場合は|+文字コード|が省略される．}
+    $\rightarrow$ |ファイル名@サイズ/組方向+文字コード|
+ \end{itemize}
+
+\csitem[\.{ptexfontname}]
+  \pTeX~4.1.0で導入された．
+  欧文フォントに対しては\.{fontname}と類似だが，
+  フォントサイズの表示が|... at ...pt|ではなく|...@...pt|の書式となる．
+  また，和文フォントに対しては追加情報として以下も表示する．
+   \begin{itemize}
+    \item 和文フォント(JFM)の場合は横組・縦組の情報を表示
+    \item 明示的に\verb+in jis+/\verb+in ucs+が指定された場合に限って文字コードを表示
+   \end{itemize}
+  書式は\.{ptextracingfonts}と同じであるが，その値は\.{ptexfontname}の出力に影響しない．
+  ここでは例を示そう．
+ \begin{itemize}
+  \item |\font\x=cmr10 at 7pt| → {\font\x=cmr10 at 7pt \code{\ptexfontname\x}}
+  \item |\font\x=nmin10| → {\font\x=nmin10 \code{\ptexfontname\x}}
+  \item |\font\x=min10 at 8pt| → {\font\x=min10 at 8pt \code{\ptexfontname\x}}
+  \item |\font in jis \x=ngoth10 at 6pt| → {\font in jis \x=ngoth10 at 6pt \code{\ptexfontname\x}}
+  \item |\font in ucs \x=utgoth10| → {\font in ucs \x=utgoth10 \code{\ptexfontname\x}}
+ \end{itemize}
+  これにより
+  「そのフォントがJISコードとUnicodeのどちらでDVI出力されるか」
+  を知ることができるし，
+  TFMファイル名には現れることがない|/|が含まれるかどうかで
+  「和文フォントかどうか」
+  を判定することもできる．
 \end{cslist}
 
 \section{文字コード変換，漢数字}
@@ -1490,18 +1646,15 @@ p3.1.2で復活したという経緯がある．}．
   たとえば，|\char\jis"346E|，|\char\euc"B0A5|，|\char\sjis"8A79|は，
   それぞれ「\char\jis"346E」，「\char\euc"B0A5」，「\char\sjis"8A79」である．
 
-%%% [TODO] \ucs, \toucs => pTeX version p3.10.0
-\ifx\toucs\undefined\else
-%
 \csitem[\.{ucs} <number>]
   Unicodeから内部コードへの変換を行う．
   もともと\upTeX で実装されていたが，\pTeX~3.10.0で取り入れた．
 
 \csitem[\.{toucs} <number>]
   内部コードからUnicodeへの変換を行う．\pTeX~3.10.0で追加した．
-%
-\fi
-%%%
+
+\csitem[\.{tojis} <number>]
+  内部コードからJISコードへの変換を行う．\pTeX~4.1.0で追加した．
 \end{cslist}
 
 \begin{dangerous}
@@ -1531,6 +1684,7 @@ p3.1.2で復活したという経緯がある．}．
     \item 文字コード変換が\emph{必要}なケース…
         不正な文字コードを与えると$-1$を返す．（返り値を統一）
   \end{itemize}
+  これは\pTeX~4.1.0で追加した\.{tojis}も同様である．
 %%%
 %
 % pTeX-3.10.0 での実装メモ (2021-06-29 @aminophen)
@@ -1597,7 +1751,7 @@ p3.1.2で復活したという経緯がある．}．
   |\kansujichar|は整数値パラメータであるが，p3.8.2までは
   「代入できるが取得はできない」という挙動であった
   （例えば|\count255=\kansujichar1|はエラー）．
-  \pTeX~p3.8.3で取得もできるように修正された(\cite{build93})が，
+  \pTeX~3.8.3で取得もできるように修正された(\cite{tjb93})が，
   以前の\pTeX も考慮すると，値の取得は以下のようにするのが安全である：
   |\count255=\expandafter`\kansuji1|
   % \count123=\kansujichar45 のように \kansujichar の引数が不正な場合は，
@@ -1636,7 +1790,7 @@ p3.1.2で復活したという経緯がある．}．
   用いることもでき\footnote{ただし，\upTeX で
   0--127の文字コードを|\kansujichar|で指定した場合のみ，
   |\kansuji|で生成されるトークンはカテゴリーコード12の
-  欧文文字トークンになる\cite{build36}．}，
+  欧文文字トークンになる\cite{tjb36}．}，
   これは時に“|\kansuji|トリック”と呼ばれる．例えば
 \begin{verbatim}
   \kansujichar1=\jis"2422 \edef\X{\kansuji1}
@@ -1701,7 +1855,7 @@ p3.1.2で復活したという経緯がある．}．
 \begin{verbatim}
 \number\ptexversion.\number\ptexminorversion\ptexrevision
 \end{verbatim}
-  で取得できる．\pTeX~p3.8.0で導入された．
+  で取得できる．\pTeX~3.8.0で導入された．
 \end{cslist}
 
 \newpage
@@ -1822,7 +1976,7 @@ has been |\let| equal to a non-active character token.
 一方，文字コードについては，確かにtex.webは|\if|判定において
 コントロールシークエンスを256とみなしている．しかし，\upTeX では
 文字コード256の和文文字と衝突するので，2019-05-06のコミット(r51021)で
-「原理的に文字コードが取り得ない値」に変更した(\cite{build68})．
+「原理的に文字コードが取り得ない値」に変更した(\cite{tjb68})．
 \end{dangerous}
 
 \newpage
@@ -1869,45 +2023,48 @@ has been |\let| equal to a non-active character token.
  \bibitem{tatemath} aminophen, 「縦数式ディレクションとベースライン補正」，
   2016/09/05,\\
   \url{https://github.com/texjporg/platex/issues/22}
- \bibitem{build26} h-kitagawa, 「禁則テーブル，|\inhibitxspcode| 情報テーブルからのエントリ削除」，
+ \bibitem{tjb26} h-kitagawa, 「禁則テーブル，|\inhibitxspcode| 情報テーブルからのエントリ削除」，
   2017/09/10,\\
   \url{https://github.com/texjporg/tex-jp-build/pull/26}
- \bibitem{build57} Man-Ting-Fang, \textit{[upTeX] Unexpected behaviour in kinsoku processing},
+ \bibitem{tjb57} Man-Ting-Fang, \textit{[upTeX] Unexpected behaviour in kinsoku processing},
   2018/04/13,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/57}
- \bibitem{build11} aminophen, 「pTeX の後禁則ペナルティ」，
+ \bibitem{tjb11} aminophen, 「pTeX の後禁則ペナルティ」，
   2017/04/05,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/11}
- \bibitem{build28} h-kitagawa, 「[ptex] |\inhibitglue|の効力」，
+ \bibitem{tjb28} h-kitagawa, 「[ptex] |\inhibitglue|の効力」，
   2017/09/20,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/28}
- \bibitem{build36} aminophen, 「欧文文字の|\kansujichar|，|\inhibitxspcode|」，
+ \bibitem{tjb36} aminophen, 「欧文文字の|\kansujichar|，|\inhibitxspcode|」，
   2017/11/26,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/36}
- \bibitem{build93} aminophen, 「[ptex] reading |\kansujichar|」，
+ \bibitem{tjb93} aminophen, 「[ptex] reading |\kansujichar|」，
   2019/10/14,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/93}
- \bibitem{build37} aminophen, 「和文のコントロールシンボル」，
+ \bibitem{tjb37} aminophen, 「和文のコントロールシンボル」，
   2017/11/29,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/37}
- \bibitem{build55} aminophen, 「[(u)pTeX] 内部コードの -kanji-internal オプション」，
+ \bibitem{tjb55} aminophen, 「[(u)pTeX] 内部コードの -kanji-internal オプション」，
   2018/04/03,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/55}
  \bibitem{forum_2566} aminophen, 「\TeX~Live 2019 での |\inhibitglue| の挙動変更【予定】」，
   2019/02/06,\\
   \url{https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=2566}
- \bibitem{build68} aminophen, 「upTeX の |\if| と |\ifcat|」，
+ \bibitem{tjb68} aminophen, 「upTeX の |\if| と |\ifcat|」，
   2019/01/17,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/68}
  \bibitem{man4} aminophen, 「pTeX の和文文字トークンのカテゴリーコード」，
   2019/04/22,\\
   \url{https://github.com/texjporg/ptex-manual/issues/4}
- \bibitem{build87} h-kitagawa, 「[ptex] ［和字］+［ブレース］で終わっている行の行端の扱い」，
+ \bibitem{tjb87} h-kitagawa, 「[ptex] ［和字］+［ブレース］で終わっている行の行端の扱い」，
   2019/08/05,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/87}
- \bibitem{build81} h-kitagawa, 「バイト列と和文文字トークンの区別」，
+ \bibitem{tjb81} h-kitagawa, 「バイト列と和文文字トークンの区別」，
   2019/06/08,\\
   \url{https://github.com/texjporg/tex-jp-build/issues/81}
+ \bibitem{tjb149} aminophen, 「[upTeX] JIS-encoded TFM」，
+  2022/10/15,\\
+  \url{https://github.com/texjporg/tex-jp-build/issues/149}
  \bibitem{dvistd0} TUG DVI Standards Working Group,
   \textit{The DVI Driver Standard, Level 0}.\\
   \url{https://ctan.org/pkg/dvistd}
-- 
cgit v1.2.3

