diff options
author | Norbert Preining <norbert@preining.info> | 2023-09-03 03:01:00 +0000 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2023-09-03 03:01:00 +0000 |
commit | 59b528f442538943e1d34291a905464d987035ee (patch) | |
tree | 0fb48c2b46c38d12136b50e9d94d612ad46669d3 /info/ptex-manual/ptex-manual.tex | |
parent | 98a037aca7cbdaf681bc3fa10cbcdbbe52570599 (diff) |
CTAN sync 202309030300
Diffstat (limited to 'info/ptex-manual/ptex-manual.tex')
-rw-r--r-- | info/ptex-manual/ptex-manual.tex | 1420 |
1 files changed, 991 insertions, 429 deletions
diff --git a/info/ptex-manual/ptex-manual.tex b/info/ptex-manual/ptex-manual.tex index d60664c459..bf968264c7 100644 --- a/info/ptex-manual/ptex-manual.tex +++ b/info/ptex-manual/ptex-manual.tex @@ -15,11 +15,11 @@ \usepackage{newpxmath} \usepackage[hyperfootnotes=false]{hyperref} \usepackage{pxjahyper} -\usepackage{hologo} \usepackage{makeidx}\makeindex % common \usepackage{ptex-manual} +\def\size#1{\mathit{#1}} \def\code#1{\texttt{#1}} %%%%%%%%%%%%%%%% @@ -49,17 +49,21 @@ \def\_{\leavevmode\vrule width .45em height -.2ex depth .3ex\relax} +\def\Pver{p\the\ptexversion.\the\ptexminorversion\ptexrevision} +\def\UPver{\Pver-u\the\uptexversion\uptexrevision} + \frenchspacing \begin{document} \title{\emph{\pTeX マニュアル}} \author{日本語\TeX 開発コミュニティ\null \thanks{\url{https://texjp.org},\ e-mail: \texttt{issue(at)texjp.org}}} -\date{version p\the\ptexversion.\the\ptexminorversion\ptexrevision,\today} +\date{\pTeX: version \Pver \\ \upTeX: vesrion \UPver \\[1ex] \today} \maketitle 本ドキュメントは,日本語\TeX 開発コミュニティ版の -\pTeX~p\the\ptexversion.\the\ptexminorversion\ptexrevision -(以下,「コミュニティ版\pTeX 」)についてまとめたものである. +\pTeX~\Pver(以下,「コミュニティ版\pTeX 」)および +\upTeX~\UPver についてまとめたものである. + \pTeX はもともとアスキー株式会社によって開発された\footnote{最新版は p3.1.11 (2009/08/17).\url{https://asciidwango.github.io/ptex/}}ので, しばしば「アスキー\pTeX 」または「ASCII \pTeX 」と呼ばれる. @@ -67,6 +71,17 @@ p3.1.11 (2009/08/17).\url{https://asciidwango.github.io/ptex/}}ので, 国際的なディストリビューション(かつてのte\TeX や現在の\TeX~Live)へ 導入するにあたって幾つかの改良を加えたものであり,オリジナルとは 動作が異なる点もあるので注意されたい. + +\upTeX は田中琢爾氏による\pTeX の拡張版であり, +\epTeX および\eupTeX は北川弘典氏によりそれぞれ\pTeX と\upTeX に +\eTeX がマージされた拡張版である. +これらはいずれもコミュニティ版\pTeX をベースに開発されており, +総称して「\pTeX 系列」と呼ばれる. + +本ドキュメント(\jobname.pdf)では,\pTeX 系列における共通機能と +\upTeX による拡張を説明する.% 和文文字トークンの扱いが異なる +\epTeX による拡張についてはeptexdoc.pdfを参照されたい. + \begin{itemize} \item コミュニティ版\pTeX の開発元:\\ \url{https://github.com/texjporg/tex-jp-build/} @@ -74,67 +89,225 @@ p3.1.11 (2009/08/17).\url{https://asciidwango.github.io/ptex/}}ので, \url{https://github.com/texjporg/ptex-manual/} \end{itemize} -なお,本ドキュメントで述べる\pTeX のプリミティブや拡張機能は, -一般に「\pTeX 系列」と呼ばれる\epTeX, \upTeX, \eupTeX でも -そのまま利用可能である.\upTeX, \eupTeX については -文字コードや和文文字トークンの扱いが異なるので,簡単に注記してある. - \newpage \tableofcontents \newpage %%%%% +\section*{表記について} +\pTeX 系列については,以下のようにまとめた表記もしばしば用いられる. +\begin{itemize} + \item \pTeX, \upTeX → (u)\pTeX + \item \pTeX, \epTeX → (\eTeXpre)\pTeX + \item \upTeX, \eupTeX → (\eTeXpre)\upTeX + \item \epTeX, \eupTeX → \eTeXpre(u)\pTeX + \item \pTeX, \upTeX, \epTeX, \eupTeX → (\eTeXpre)(u)\pTeX +\end{itemize} + +本ドキュメントでは,特に断らない限り単に\pTeX と表記すれば +(\eTeXpre)(u)\pTeX の4種類全てを指すこととする. +また\upTeX と表記すれば(\eTeXpre)\upTeX の2種類を指すこととする. + +ただし,節タイトルで\emph{【\pTeX の場合】【\upTeX の場合】}の +ように分割した箇所については, +それぞれ(\eTeXpre)\pTeX と(\eTeXpre)\upTeX を指すこととする. +また,(すぐ下のように)列挙する形で記す場合は +それぞれ単独のエンジンを指す. + +\section*{\TeX~Liveにおける配布} +\def\MODEext{{\tiny 拡張モード}} +\the\year 現在,\TeX~Liveで配布されている主要なエンジンと +\pTeX 系列の関係性は以下の図で表される. +独立したプログラム(バイナリ)として配布されているものを +\fbox{枠}で囲んである.\par\vskip-35pt +\[ +\xymatrix@ur{ + \text{\fbox{\TeX}} \ar[r]\ar[d] & \text{\eTeX} \ar[r]\ar[d]\ar[rd] + & \text{\fbox{\pdfTeX}} \ar[rd] & \\ + \text{\pTeX} \ar[r]\ar[d] & \text{\fbox{\epTeX}} \ar[d] + & \text{\fbox{\hologo{XeTeX}}} & \text{\fbox{Lua\TeX}} \\ + \text{\upTeX} \ar[r] & \text{\fbox{\eupTeX}} & & %\\ &&& +} +\] + +\TeX~Live 2022までは +\pTeX, \upTeX, \epTeX, \eupTeX の4種類のエンジンが +独立したプログラムとして配布されていたが, +\TeX~Live 2023では素の\pTeX と\upTeX の配布が停止され, +それぞれ\epTeX と\eupTeX の互換モード(\code{-etex}スイッチ無効, +すなわちextended modeでない状態)に置き換えられた +\footnote{例えば,2022年まではコマンド\code{ptex}で +\code{This is pTeX, Version ...}が起動していたが,2023年は +\code{This is e-pTeX, Version ...}が起動する. +ここだけ見るとコマンド\code{eptex}と似ているが,\code{eptex}では +直後に\code{entering extended mode}と拡張モードに入るのと異なり, +\code{ptex}では拡張モードに入らないので,\eTeX 特有の +機能およびプリミティブは無効化された状態となる.}. +\begin{table}[ht] + \centering + \begin{tabular}{ccc} + \code{コマンド名} & \TeX~Live 2022まで & \TeX~Live 2023 \\ + \code{ptex} & \pTeX & \epTeX の互換モード \\ + \code{uptex} & \upTeX & \eupTeX の互換モード \\ + \code{eptex} & \epTeX\MODEext & →変更なし \\ + \code{euptex} & \eupTeX\MODEext & →変更なし \\ + \end{tabular} +\end{table} + +\section*{\pTeX 系列における\LaTeX} +(\eTeXpre)\pTeX で動くように調整された\LaTeX を\pLaTeX, +(\eTeXpre)\upTeX で動くように調整された\LaTeX を\upLaTeX と呼ぶ. + +\pLaTeX はもともとアスキー株式会社によって\pTeX と一体で +開発されていた\footnote{最新版は2006/11/10.これを +「アスキー版\pLaTeX」と呼ぶことにする.}. +2010年にコミュニティ版\pTeX が\TeX~Liveに収録されて以降, +そこで独自の改良や仕様変更が加えられるようになり, +またベースである\LaTeX も更新が進んでいる. +特に2020年以降は,\LaTeX は素の\TeX では動作せず, +拡張モードの\eTeX~``$+\alpha$''が動作条件となっており, +したがって素の(u)\pTeX では動作しない. +そうした流れに合わせてアスキー版\pLaTeX からforkしたのが +「コミュニティ版\pLaTeX」である. +\upLaTeX はもともとアスキー版\pLaTeX を元に\upTeX と一体で +開発されていたが,現在はコミュニティ版\pLaTeX をベースにしている. + +\begin{itemize} + \item コミュニティ版\pLaTeX の開発元:\\ + \url{https://github.com/texjporg/platex/} + \item コミュニティ版\upLaTeX の開発元:\\ + \url{https://github.com/texjporg/uplatex/} +\end{itemize} + +\TeX~Liveでのエンジン利用状況は以下の通りである. +ここで,2023-06-01以降は\code{platex}で\epTeX ではなく +「\eupTeX の内部処理をレガシーなEUC-JP/Shift-JISに変更した状態」 +が起動することに注意\footnote{(\eTeXpre)\upTeX は +通常のコマンド名\code{uptex}や\code{euptex}で起動されると +内部処理をUnicodeで行うが, +コマンド名\code{ptex}や\code{eptex}で起動されると +内部処理を(\eTeXpre)\pTeX 同様のレガシーエンコーディングで行う. +内部コードの差異だけであり,その他の(\eTeXpre)\upTeX 特有の +機能およびプリミティブは利用可能な状態である. +本文中\code{-kanji-internal}の説明も参照.}. +\begin{table}[ht] + \centering + \begin{tabular}{ccc} + \code{コマンド名} & \TeX~Live 2012から2023初期まで & \TeX~Live 2023の2023-06-01以降 \\ + \code{platex} & \epTeX\MODEext & \eupTeX\MODEext の内部レガシー \\ + \code{uplatex} & \eupTeX\MODEext & →変更なし \\ + \end{tabular} +\end{table} + +\clearpage + + +%%%%% \part{\pTeX の日本語組版と追加プリミティブ} -ここでは,\pTeX の日本語組版の概略と,それを実現するために導入された +ここでは,\pTeX 系列の日本語組版の概略と,それを実現するために導入された プリミティブを説明する. -\section{\pTeX で利用可能な文字} +\section{\pTeX 系列で利用可能な文字} \label{sec:ptexchar} % このマニュアルを英語化する際は以下も参照. % http://tutimura.ath.cx/ptexlive/?ptexenc%2FDetails % http://ajt.ktug.org/assets/2008/5/1/0201tsuchimura_kuroki.pdf -% https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=460 +% https://okumuralab.org/tex/mod/forum/discuss.php?d=460 \TeX82で扱える文字コードの範囲は0--255であった. -\pTeX ではこれに加えてJIS~X~0208の文字も利用可能になっており, -入力ファイルの文字コードはISO-2022-JP (jis),EUC-JP (euc), -Shift-JIS (sjis)またはUTF-8 (utf8)に対応している. +\pTeX 系列では,日本語の文字を(\LaTeX の\code{inpuenc}のようなアクティブ化 +によらず)直接扱えるように,文字コードとして有効な範囲を拡張している. +以降では,従来の枠組みで扱える文字を\emph{欧文文字}, +それ以外を\emph{和文文字}と呼ぶ. + +なお,本節(\ref{sec:ptexchar}節)全体を通して +\epTeX は\pTeX と同じ,\eupTeX は\upTeX と同じである. + +\subsection{ファイルのエンコードと内部コード} +\pTeX 系列は,\emph{入出力ファイルのエンコード}として +ISO-2022-JP (jis),EUC-JP (euc),Shift-JIS (sjis)またはUTF-8 (utf8)に対応している. +ただし,入力はそのままのエンコードで扱われるとは限らず, +各行は\emph{内部コード}に変換されてから内部処理に回され, +ファイル出力時にもやはり内部コードからの変換が行われる. +ファイルのエンコードと内部コードが異なる場合は +\code{ptexenc}ライブラリに従ってエンコード変換が発生することとなる. +\TeX の入力プロセッサに実際に渡るのは入力各行の変換結果である. + +\pTeX の内部コードはWindowsではShift-JIS,それ以外ではEUC-JPが既定であり, +\upTeX の内部コードは既定でUnicodeであるが, +起動時のオプション|-kanji-internal|(INIモード時のみ有効:後述)に +よって制御できる. + +\pTeX/\upTeX の入出力ファイルのエンコードは, +\TeX~Live 2018以降は全てのプラットフォームでUTF-8が既定である +\footnote{\TeX~Live 2017以前では\pTeX に限り, +WindowsではShift-JIS,それ以外ではUTF-8であった. +\upTeX は当初から全てのプラットフォームでUTF-8であった.}が, +個別の入力ファイルのエンコードは次の順番で決まる(\code{ptexenc}による). +この決定手続きはファイルの先頭行を読むときに行われる. +% 注:|PTEX_IN_FILTER| が定義されている場合は別. +\begin{enumerate} + \item ファイル先頭にUTF-8のBOM\footnote{正確には,最初の4byteが + \code{0xEF 0xBB 0xBF 0x7E}以下.}を見つけたらUTF-8(BOM付き)とみなす. + \item エンコード推測機能が有効ならば推測を行い,成功すれば + それを採用する\footnote{\TeX~Live 2022以前はWindows専用の機能であったが, + \TeX~Live 2023で全てのプラットフォームで利用可能となった\cite{tjb142}. + kpathsearchライブラリ変数|guess_input_kanji_encoding|によって制御でき, + 値が1ならば有効,0ならば無効である.}. + \item 起動時のオプション|-kanji|(後述)による指定があればそれを使う. + \item 環境変数|PTEX_KANJI_ENC|が定義されていればそれを使う. + \item 以上で決まらない場合は既定のエンコードを使う. +\end{enumerate} +% 以上の記述は阿部さんのブログを基に作成. +% http://abenori.blogspot.com/2016/02/e-ptexeptexinputencoding.html +% なお LaTeX2e 2018-04-01 での inputenc UTF-8 既定化に合わせて +% Windows (W32TeX) でも Shift-JIS から UTF-8 に変更されている. +% https://okumuralab.org/tex/mod/forum/discuss.php?d=2396 + +なお,ISO-2022-JPでエンコードされた文字は現在のエンコードによらず正しく読まれる. +% ISO-2022-JP (JIS) でエンコードされたバイト列は 7 ビットであって, +% 他の 3 つのエンコードと明らかに区別ができるため。 +% 実際には,他のエンコードのファイルの途中に JIS の文字列が混ざっていても +% 全て正常に読み込まれる。 +% https://qiita.com/zr_tex8r/items/beda5a7702b84409436e +また,\eTeXpre(u)\pTeX の|\epTeXinputencoding|を使用すればその次の行から +新しいエンコードで読まれる(\texttt{./eptexdoc.pdf}を参照). \begin{dangerous} ここでは,歴史に興味のある読者への情報として,アスキー\pTeX から -現在のコミュニティ版\pTeX に至る文字コードの扱いの変遷を述べる. +現在のコミュニティ版\pTeX に至るエンコードの扱いの変遷を述べる. 初期のアスキー\pTeX は「EUC版\pTeX 」「SJIS版\pTeX 」「JIS版\pTeX 」の -3つのプログラムを別々に用意しており,一つの\pTeX バイナリでは文字コードが +3つのプログラムを別々に用意しており,一つの\pTeX バイナリではエンコードが EUC-JP,Shift-JIS,ISO-2022-JPのどれか一つのファイルしか処理できなかった. % JIS のファイルなら EUC/SJIS どちらの ptex でも読み込めますが, % これも最初からではなく p2.1.5 (1997年) 以降のようで, % それまではスタイルファイルも EUC や SJIS にしておく必要があったようです. -|-kanji| オプションが追加され,一つの\pTeX バイナリで複数の文字コードを +|-kanji| オプションが追加され,一つの\pTeX バイナリで複数のエンコードを 選択処理できるようになったのは\pTeX~3.0.1と3.0.4の間(2002年10月頃)である. % http://tutimura.ath.cx/ptexlive/?ptexenc%2FDetails % の土村さんのコメント (2008-02-23) より コミュニティ版\pTeX は,UNIX向け日本語\TeX ディストリビューション -ptetex\footnote{土村展之さんによって2004年から2009年まで開発. +pte\TeX\footnote{土村展之さんによって2004年から2009年まで開発. その後継のptexliveは,2010年に\pTeX が\TeX~Liveに取り込まれる際のベースに なった.}の開発過程で誕生した. -2006年頃から文字コードがUTF-8のファイル入力への対応が進められ,2007年には -文字コード変換を担う関数群が\code{ptexenc}というライブラリに切り出された. +% コミュニティ版という呼称は2004年当初からのものではなく +% 2016年頃に生じたものであるが,系譜上ptetexと一体で +% 開発されてきたものをコミュニティ版と後から呼ぶことにする. +2006年頃からエンコードがUTF-8のファイル入力への対応が進められ,2007年には +エンコード変換を担う関数群が\code{ptexenc}というライブラリに切り出された. 現在の\TeX~Liveでも\code{ptexenc}は種々のプログラムで利用されている. \end{dangerous} -\subsection{ファイルの文字コードと内部コード} -\pTeX への入力は,ファイルの文字コードそのままで扱われるとは限らず, -\emph{内部コード}に変換されて内部処理に回される.ファイルの文字コードと -内部コードは,それぞれ起動時のオプションによって制御できる. +\paragraph{\pTeX 系列の起動時のオプション} \begin{itemize} \item |-kanji=|<encoding> \begin{quotation} - 入出力テキストファイルの文字コードを指定する.\\ + 入出力テキストファイルのエンコードを指定する.\\ 利用可能な<encoding>の値:\code{euc}, \code{sjis}, \code{jis}, \code{utf8} \end{quotation} \item |-kanji-internal=|<encoding> @@ -144,13 +317,19 @@ ptetex\footnote{土村展之さんによって2004年から2009年まで開発 virtual modeでは読み込んだフォーマットファイルと同じ内部コードで 動作するように固定している.\pTeX\ p3.8.2以降の仕様.}).\\ 利用可能な<encoding>の値:\code{euc}, \code{sjis} + \quad (\upTeX のみ:\code{uptex}も利用可能) \end{quotation} \end{itemize} -この通り,\pTeX への入力を仮にUTF-8としても, -必ずEUC-JPかShift-JISのいずれかの内部コードに変換されるため, -\emph{\pTeX はJIS~X~0208外の文字をサポートしない}. - -\pTeX の入出力ファイルの文字コードと内部コードは起動時のバナーから分かる. +\pTeX で利用可能な内部コードは\code{euc} (EUC-JP)か +\code{sjis} (Shift-JIS)のいずれかであるため, +入力を仮にUTF-8としても必ず内部コードへの変換が起こる. +\upTeX では既定状態の内部コードが\code{uptex} (Unicode)なので, +入力をUTF-8とすれば変換は“ほとんど”起こらない\footnote{例外は +\code{ptexenc}による基底文字と濁点に分解された形(結合文字列)の +合成など:後述.}. + +\paragraph{\pTeX 系列の起動時のバナー} +入出力ファイルのエンコードと内部コードは起動時のバナーから分かる. 例えば \begin{verbatim} This is pTeX, Version 3.14159265-p3.8.0 (utf8.euc) (TeX Live 2018) @@ -158,16 +337,15 @@ This is pTeX, Version 3.14159265-p3.8.0 (utf8.euc) (TeX Live 2018) \end{verbatim} というバナーの場合は,|(utf8.euc)| から \begin{itemize} - \item 入出力ファイルの(既定)文字コードはUTF-8(但し,JIS~X~0208の範囲内) + \item 入出力ファイルの(既定)エンコードはUTF-8(但し,JIS~X~0208の範囲内) \item \pTeX の内部コードはEUC-JP \end{itemize} -という情報が見て取れる.入出力ファイルの文字コードと内部コードが同じ場合は, +という情報が見て取れる.入出力ファイルのエンコードと内部コードが同じ場合は, \begin{verbatim} This is pTeX, Version 3.14159265-p3.8.0 (sjis) (TeX Live 2018) (preloaded format=ptex) \end{verbatim} -のように表示される.この例は,入出力ファイルの文字コードと内部コードが -ともにShift-JISであることを示す. +のように表示される(入出力ファイルのエンコードと内部コードがともにShift-JISである例). \begin{dangerous} 上にはこのように書いたが, @@ -184,15 +362,25 @@ virtual modeでは,起動直後にバナーを表示してから,フォー このようなウソは,\pTeX に限らず\code{(preloaded format=***)}でも見られる. \end{dangerous} -\subsection{和文文字と欧文文字の区別} -\pTeX への入力は\emph{「7ビットASCII文字集合」に「あるファイルの文字コードで -エンコードされたJIS~X~0208の文字集合」を加えたもの}として解釈される. -そして,以下の規則により欧文文字と和文文字に区別して取り扱われる. +\subsection{有効な文字コードの範囲【\pTeX の場合】}\label{sec:ptex_code} +\pTeX では,JIS~X~0208すなわちJIS第1, 2水準の文字を利用可能である. +入力は\emph{「7ビットASCII文字集合」に「あるファイルのエンコードで +表現されたJIS~X~0208の文字集合」を加えたもの}として解釈される. +そして,以下の規則により和文文字と欧文文字に区別して取り扱われる. \begin{itemize} - \item 7ビットASCII文字集合は欧文文字として扱われる. - \item 最上位ビットが1の場合,\pTeX はそのバイトで始まる列について - ファイルの文字コードからEUC-JPまたはShift-JISのいずれかの - 内部コードへの変換を試みる. + \item 7ビットASCII文字集合は\emph{欧文文字}として扱われる. + また,\TeX82互換の「|^^|記法」という間接的な入力法 + \footnote{|^^ab|のようにカテゴリーコード7の文字2つに続いて + |0|--|9|, |a|--|f|のいずれかが2つ続くと, + それを16進文字コードとする文字入力がなされたのと同じ処理に回る.}も + \emph{常に欧文扱い}される\footnote{|^^|記法の欧文扱いは + アスキー\pTeX~3.1.4以降. + \pTeX~3.1.8で制御綴内での扱いが改善された.また, + コミュニティ版\pTeX~4.0.0で文字列化においても常に欧文扱いするように改修した. + これについては\ref{sec:printkanji16bit}節を参照.}. + \item 最上位ビットが1の場合,そのバイトで始まる列について + ファイルのエンコードから内部コード(EUC-JPまたはShift-JIS)への + 変換を試みる(同一コードなら恒等変換). 和文文字の内部コードとして許される整数は $256c_1+c_2$,但し$c_i\in C_i$であり,ここで \begin{description} @@ -202,44 +390,56 @@ virtual modeでは,起動直後にバナーを表示してから,フォー $C_1=\{\hex{81},\dots,\hex{9f}\}\cup\{\hex{e0},\dots,\hex{fc}\}$,\\ $C_2=\{\hex{40},\dots,\hex{7e}\}\cup\{\hex{80},\dots,\hex{fc}\}$. \end{description} - である.この内部コードのパターンに合えば和文文字として扱われ, - 合わなければ8ビット欧文文字のバイト列として扱われる\footnote{例えば, - 入力ファイルの文字コードがUTF-8の場合,JIS~X~0208にない文字は - UTF-8のバイト列として読み込まれる.}. + である.この内部コードのパターンに合えば + 「変換後の文字コードを持つ一つの\emph{和文文字}」 + として扱われ,合わなければ一旦|^^ab|形式への変換(後出の★)を経て + 「\emph{8ビット欧文文字}のバイト列」として扱われる. \end{itemize} -% 参考:kanji.c の |is_char_kanji| の実装 +% TeX の行入力処理 +% https://www.ma.ns.tcu.ac.jp/Pages/TeX/line.input.html +% アスキー pTeX 3.1.4 における ^^ 記法の改修 +% https://www.ma.ns.tcu.ac.jp/Pages/TeX/hat.hat.a.b.html -なお,\TeX82には「|^^|記法」という間接的な入力法があり,|^^ab|のように -カテゴリーコード7の文字2つに続いて|0|--|9|, |a|--|f|のいずれかが2つ続くと -それを16進文字コードとする文字入力がなされたのと同じ処理に回るが, -\pTeX 系列ではこれは\emph{常に欧文扱い}される(アスキー\pTeX~3.1.4以降 -\footnote{\pTeX~3.1.8で制御綴内での扱いが改善された.また, -コミュニティ版\pTeX~4.0.0で文字列化においても常に欧文扱いするように改修した. -これについては\ref{sec:printkanji16bit}節を参照.}). +\begin{dangerous} +一遍に書いているが, +入力ファイルを一行読み込んで必要なエンコード変換を行った結果を +バッファに格納するところまでが\code{ptexenc}による前処理である. +そのバッファを\TeX の入力プロセッサが読み, +文字のカテゴリーコードに従って(和文と欧文の区別を付けながら) +トークン列を生成する,という流れである. +\code{ptexenc}による前処理には +「内部コードに変換できない入力のバイト列を|^^ab|形式に変換」も +含まれるが,この時点ではカテゴリーコードについて知らないため, +文字|^|の|\catcode|が7かどうかは関係なく|^^|が用いられる. +\end{dangerous} -最近(2010年代以降)では,\pTeX でもファイルの文字コードをUTF-8とする +\pTeX における有効な文字コードの範囲は +「欧文文字として有効な文字コード(0--255)」と +「和文文字として有効な文字コード(内部コードとして許される整数値)」の和集合であり, +前者は1バイト・後者は2バイトなので互いに重ならない. +% 内部コードの範囲:kanji.c の |is_char_kanji| の実装 + +最近(2010年代以降)では,\pTeX でもファイルのエンコードをUTF-8とする 利用が増えてきた. -コミュニティ版\pTeX では,\code{ptexenc}ライブラリによって -UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する際に -以下の特殊な加工を行っている. +コミュニティ版\pTeX はUTF-8ファイル入力に対応しているが, +先述の通り内部コードはEUC-JPまたはShift-JISのいずれかであるため, +\emph{\pTeX はJIS~X~0208外の文字をサポートしない}. +なお,\code{ptexenc}による前処理に以下の特殊な加工を含めてある. % http://tutimura.ath.cx/ptetex/?UTF-8%C2%D0%B1%FE%282%29 \begin{itemize} - \item Unicodeでのバラツキを同一視する多対一変換 + \item Unicodeでのバラツキを同一視する多対一変換(表\ref{table:jis_uni_var}) \footnote{例えば,ソースファイル中の全角ダーシ(\code{U+2015})と EMダーシ(\code{U+2014})は同一視され,内部的にはJISコード\code{"213D}と して扱われ,ファイルに書き出される時は\code{U+2015}になる.} \item BOMの無視(ファイル先頭に限らず) \item 結合濁点(\code{U+3099})・半濁点(\code{U+309A})の合字処理 - \item JISに変換できない文字を|^^ab|形式に変換 - \footnote{例えば,ソースファイル中にçのような欧文文字を直接書くと, - これは和文文字の内部コードに変換できないため|^^c3^^a7|に変換される.} + \item JIS外のため変換できない文字を|^^ab|形式に変換 + \footnote{例えば,ソースファイル中にçのようなJIS~X~0208外の文字を直接書くと, + これは和文文字の内部コードに変換できないため|ç|に変換されて欧文扱いされる.}% => ^^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 とは入力に関して必ずしも @@ -251,13 +451,13 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する JIS~X~0213で規定された「85区1点」の位置の文字を入力ファイル中に書いた場合, \begin{description} - \item[文字コードがEUC,~Shift-JISの場合] DVIには29985~(\texttt{"7521})%" + \item[エンコードがEUC,~Shift-JISの場合] DVIには29985~(\texttt{"7521})%" 番の文字として出力される. - \item[文字コードがJISの場合] 「\verb+! Missing $ inserted.+」というエラーが発生する. + \item[エンコードがJISの場合] 「\verb+! Missing $ inserted.+」というエラーが発生する. これは,\pTeX がJIS~X~0213の1面を指示するエスケープシーケンス \texttt{1B 24 28 4F} (JIS2000), \texttt{1B 24 28 51} (JIS2004)を認識せず, \texttt{24}~(\texttt{\$})を数式モード区切りと解釈してしまうためである. - \item[文字コードがUTF-8の場合] UTF-8のバイト列\texttt{E6 93 84}として読み込まれる. + \item[エンコードがUTF-8の場合] UTF-8のバイト列\texttt{E6 93 84}として読み込まれる. \end{description} なお,\.{char}により「\verb+\char\kuten"5521+」%" のようにして区点コードを指定した場合は,DVIには29985~(\texttt{"7521})%" @@ -266,14 +466,129 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する 意図通りに出力されるかは全くの別問題である. \end{dangerous} -\subsection{文字コードの取得と指定} -\pTeX でも\TeX82と同様に, -バッククオート(|`|)を使って「|`あ|」のようにして和文文字の内部コードを -内部整数として得ることができる.欧文文字については,1文字の制御綴を -代わりに指定することができた(例えば,「|`b|」と「|`\b|」は同じ意味だった)が, -同じことを和文文字に対して「|`\あ|」などと行うことはできない. +\subsection{有効な文字コードの範囲【\upTeX の場合】}\label{sec:uptex_code} +\upTeX は\pTeX と事情が異なるので,ここで説明する. +\pTeX との違いを\emph{強調}してある. +\begin{itemize} + \item 文字集合は内部コードにより範囲が異なる. + \begin{itemize} + \item 内部レガシー(EUC-JPまたはShift-JIS)の場合: + 「7ビットASCII文字集合」に「あるファイルのエンコードで + 表現されたJIS~X~0208の文字集合」を加えたもの. + つまり\pTeX となんら変わらない. + \item \emph{内部Unicodeの場合:Unicode全体.} + \end{itemize} + \item 和文文字と欧文文字の区別は以下の規則による: +% +\begin{itemize} + \item 7ビットASCII文字集合は欧文文字として扱われる. + また,\TeX82互換の「|^^|記法」という間接的な入力法も + 常に欧文扱いされる.(\pTeX と同様) + \item 最上位ビットが1の場合,そのバイトで始まる列について + ファイルのエンコードから内部コードへの変換を試みる(同一コードなら恒等変換). + 内部コードのパターンに合えば + 「変換後の文字コードを持つ一つの\emph{一文字}」 + として扱われ,\emph{それが和文扱いか欧文扱いかは + \.{kcatcode}に依存する(詳細は\ref{sec:uptex_kcat}節).} + 合わなければ一旦|^^ab|形式への変換(後出の★)を経て + 「8ビット欧文文字のバイト列」として扱われる. + % + % pTeX で和文固定の文字(例えば "あ")も + % upTeX -kanji-internal=euc/sjis なら \kcatcode=15 で欧文扱いできる. + % ただし入力ファイルのエンコードによらず内部コードにより + % 結果は ^^a4^^a2 (euc) / ^^82^^a0 (sjis) になる. + % +\end{itemize} +% + \item \code{ptexenc}ライブラリによる前処理も\pTeX と類似だが, + 変換方向によって少々異なる. +% +\begin{itemize} + \item Unicode多対一変換:内部レガシーの場合は\pTeX と同様. + \emph{内部Unicodeの場合は,入出力UTF-8に対しては変換を行わず, + 入力EUC-JP/Shift-JISからの変換について一対多対応があれば + Unicodeへの変換は表\ref{table:jis_uni_var}に従う.} + \item BOMの無視は行う.(\pTeX と同様) + \item 結合濁点・半濁点の合字処理は行う(\TeX~Live 2016以降 + \footnote{結合濁点・半濁点は\TeX~Live 2015までは\pTeX でのみ + 合字処理され,\upTeX では行っていなかった.}).(\pTeX と同様). + \item 範囲外の文字の|^^ab|形式への変換:内部レガシーでは\pTeX と同様. + \emph{内部Unicodeでは,文字集合がUnicode全体なので範囲外の文字は + 存在せず,従って}|^^ab|\emph{形式への変換は基本的に起こらない} + \footnote{不正なUTF-8入力などに限り|^^ab|形式に変換される.}.…★ +\end{itemize} +% 結合文字列(基底文字+合成用濁点・半濁点)→合成文字 +% https://zrbabbler.hatenablog.com/entry/20151006/1444134044 +% https://okumuralab.org/tex/mod/forum/discuss.php?d=1701 +% +\end{itemize} + +\upTeX における有効な文字コードの範囲は +「欧文文字として有効な文字コード(0--255)」と +「和文文字として有効な文字コード」の和集合である. +内部レガシーの場合は\pTeX と全く同じであり, +前者は1バイト・後者は2バイトなので互いに重ならない. +内部Unicodeの場合は後者がUnicode全体(0以上0x10FFFF以下 +\footnote{実は上限が0x10FFFFというのは嘘である:24bit整数値が +有効であり,0x110000以上0x1000000未満は特殊な用途で利用される. +内部コードUnicode (\code{uptex})の +\upTeX では,和文文字トークンおよび和文文字ノードにおいて +文字コードをUTF-32の下位24bitで格納する. +DVI出力時には「文字コード mod 0x110000」で書き込まれる. +これはUnicodeの正規の文字コード(0x10FFFF以下)のカテゴリーコードや +禁則ペナルティのしがらみの影響を受けない目的でOTFパッケージで使われる.}の +整数値)となるので,\emph{0--255の範囲は重なっており +和文・欧文どちらの文字コードとしても有効である}ことに注意. +% 内部コードの範囲:kanji.c の |is_char_kanji| の実装 +% 0x110000 以上の扱い:0x1000000 以下は otf で意図的に利用. +% https://okumuralab.org/~okumura/texfaq/qa/50036.html +% [TODO] 実装上「0..0x1000000」よりも広い「TeX が扱える 0 以上の整数値全体」が有効? +% https://gist.github.com/aminophen/43b5f7f8592fc66210935f67d4d88391 + +いずれの場合も,\upTeX は +オリジナルの\TeX や\pdfTeX などの欧文\TeX とは入力に関して必ずしも +互換でない(内部UnicodeへのUTF-8入力に限っても「BOMの無視」と +「結合濁点・半濁点の合字処理」だけは起こる)が, +\pTeX と比較すれば幾分差異が軽減されている. -\pTeX では「文字コードを引数にとるプリミティブ」といっても,状況によって +\begin{table}[tbp] +\caption{JIS⇔Unicode一対多変換.Unicode→JIS変換では複数の文字が同一視 +される.JIS→Unicode変換では複数候補のうち\emph{太字}が選択される.} +\label{table:jis_uni_var} +% ptexenc/unicode-jp.c の variation[] にて定義. +% http://www.t-lab.opal.ne.jp/tex/jis_uni_variation_uptex.html +% 下記ZRは https://github.com/texjporg/jsclasses/issues/49 で言及あり +\centering\small +\begin{tabular}{cccc} +\toprule +区点 & Character Name & JIS~X~0208 & Unicode \\ +\midrule +1-17 & \code{OVERLINE} + & \code{0x2131} & \code{U+203E}, \emph{\code{U+FFE3}} \\ +1-29 & \code{EM DASH} + & \code{0x213D} & \code{U+2014}, \emph{\code{U+2015}} \\ %ZR +1-33 & \code{WAVE DASH} + & \code{0x2141} & \emph{\code{U+301C}}, \code{U+FF5E} \\ %ZR +1-34 & \code{DOUBLE VERTICAL LINE} + & \code{0x2142} & \emph{\code{U+2016}}, \code{U+2225} \\ %ZR +1-36 & \code{HORIZONTAL ELLIPSIS} + & \code{0x2144} & \emph{\code{U+2026}}, \code{U+22EF} \\ +1-61 & \code{MINUS SIGN} + & \code{0x215D} & \emph{\code{U+2212}}, \code{U+FF0D} \\ %ZR +1-79 & \code{YEN SIGN} + & \code{0x216F} & \code{U+00A5}, \emph{\code{U+FFE5}} \\ +1-81 & \code{CENT SIGN} + & \code{0x2171} & \code{U+00A2}, \emph{\code{U+FFE0}} \\ %ZR +1-82 & \code{POUND SIGN} + & \code{0x2172} & \code{U+00A3}, \emph{\code{U+FFE1}} \\ %ZR +2-44 & \code{NOT SIGN} + & \code{0x224C} & \code{U+00AC}, \emph{\code{U+FFE2}} \\ %ZR +\bottomrule +\end{tabular} +\end{table} + +\subsection{文字コードの取得と指定}\label{sec:getcode} +(u)\pTeX では「文字コードを引数にとるプリミティブ」といっても,状況によって \begin{itemize} \item 欧文文字の文字コード0--255をとる(例:|\catcode|) \item 和文文字の内部コードをとる(例:|\inhibitxspcode|) @@ -291,65 +606,129 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する \item[<16-bit number>] 0--65535の範囲内の整数 \end{description} -\section{和文文字と\.{kcatcode}} -\TeX82では各文字に0--15のカテゴリーコードを割り当てており, -\TeX82の入力プロセッサは「どのカテゴリーコードの文字が来たか」で状態が遷移する -有限オートマトンとして記述できる(\cite{topic}). -\pTeX においても同様であり,和文文字には -16~($\mathit{kanji}$), 17~($\mathit{kana}$), 18~($\mathit{other\_kchar}$)の -カテゴリーコードのいずれかを割り当てることで拡張している. +和文文字の文字コードを数値で指定するには,内部コードで表現する必要がある. +この方法として,(u)\pTeX では以下が利用できる. +\begin{itemize} + \item \TeX82と同様に, + バッククオート(|`|)を使って「|`あ|」のようにして和文文字の内部コードを + 内部整数として得ることができる.欧文文字については,1文字の制御綴を + 代わりに指定することができた(例えば,「|`b|」と「|`\b|」は同じ意味だった)が, + 同じことを和文文字に対して「|`\あ|」などと行うことはできない. + \item 数値で直接表現するために,異なるエンコードから内部コードへの + 文字コード変換を行うプリミティブが用意されている. + \ref{sec:convert}節を参照. +\end{itemize} + +\section{和文カテゴリーコードと\TeX の入力プロセッサ} + +\TeX の処理は以下のような段階を踏み,\pTeX 系列でもこれは共通である. +% https://blog.wtsnjp.com/2016/11/24/tex-by-topic1/ +% https://blog.wtsnjp.com/2017/03/31/tex-by-topic2/ +\begin{itemize} + \item 入力を一行単位で読み込む(改行文字はCR,~LFいずれも可). + \item (\code{ptexenc}によるエンコード変換) + \item \emph{入力プロセッサ}がカテゴリーコードに従って「順に」トークン化 + しつつ,その過程で + \begin{itemize} + \item \emph{展開プロセッサ}:マクロやアクティブ文字など + 展開可能トークンの展開 + \item \emph{実行プロセッサ}:代入やマクロ定義,出力リスト構築など + 展開不能トークンの実行 + \end{itemize} + も介入する\footnote{例えば,実行プロセッサの結果により + カテゴリーコードが変更されれば, + 行内でも入力プロセッサの動作に影響を及ぼし,以降の展開・実行結果も変化する. + ただし,順に一度トークン化されたもののカテゴリーコードは固定である.}. + % e-TeX の \scantokens を除く. + \item \emph{ビジュアルプロセッサ}が受け取った出力リストを元に + 行分割・ページ分割などを行い,ページをDVIに出力する. +\end{itemize} + +\TeX82では各文字に0--15のカテゴリーコード(\.{catcode})を割り当てており, +入力プロセッサは「どのカテゴリーコードの文字が来たか」で状態が遷移する +有限オートマトンとして記述できる\cite{topic}. +\pTeX 系列においても同様であり,和文文字には欧文文字とは異なる +専用のカテゴリーコード(\.{kcatcode})を割り当てることで拡張している. +\.{kcatcode}の仕様は\pTeX と\upTeX で異なるので,別々に説明する. +% [TODO] 和文トークンの話は以下も参照しながら ptex-guide-en を整備 +% https://gist.github.com/zr-tex8r/629b5334d19cbcfc3fe58728b81b1c80 + +\subsection{和文カテゴリーコード【\pTeX の場合】} +\label{sec:ptex_kcat} +\pTeX が欧文\TeX と大きく異なるのは以下の点である. +\begin{itemize} + \item 文字コードによって和文文字(2バイト)と欧文文字(1バイト)を区別する. + \item 和文文字直後の改行は(欧文文字直後の改行と異なり)空白とみなさない. + \item 和文文字には役割に応じて16~($\mathit{kanji}$), 17~($\mathit{kana}$), + 18~($\mathit{other\_kchar}$)の和文カテゴリーコードのいずれかを割り当てる. + 初期状態では,JISの1,~2, 7--15, 85--94区の文字は18,3--6区の文字は17, + 16--84区の文字は16に設定されている. + \item 和文文字トークンは文字コードのみで表現され,そのカテゴリーコードは + 随時算出されるようになっている. + 欧文文字トークンが\TeX82と同様にカテゴリーコード$c$と文字コード$s$の + 組み合わせ($256c+s$)で表現されているのとは対照的である. +\end{itemize} +和文カテゴリーコードの値は一応, +16が「漢字」,17が「かな」,18が「その他の和文記号」を意図している. +ただし区の中身を見れば分かる通り,\pTeX では特に +全角数字・アルファベット(3区)とギリシャ文字(6区)も17であり, +キリル文字(7区)は18となっている. +和文カテゴリーコードの値による動作の違いは次のようになる +(16と17は\pTeX の内部処理においては全く等価で,18だけが異なる). +\begin{itemize} + \item \TeX82では,「複数文字からなる命令」(コントロールワード)には + カテゴリーコードが11~($\mathit{letter}$)の文字しか使用できないことになっていたが, + \pTeX ではカテゴリーコードが16,~17の和文文字も合わせて使用することができる. + \item 一方,カテゴリーコードが18の和文文字はコントロールワード中には使用できない. + 「|\】|」のように一文字命令(コントロールシンボル)に使用することはできる + \footnote{「|\】|」のような和文のコントロールシンボルで行が終わった場合, + 「|\!|」のような欧文コントロールシンボルと同様に改行由来の空白が追加されてしまい, + 和文文字直後の改行は何も発生しないという原則に反していたが, + これは\TeX~Live 2019の\pTeX~3.8.2で修正された\cite{tjb37}.}. + \item 後で説明する|\jcharwidowpenalty|は,カテゴリーコードの値が16,~17の + 和文文字の前にのみ挿入されうるもので,値が18の和文文字の前には挿入されない. + \item いずれにせよ,和文文字は決して“アクティブ”(欧文文字における + カテゴリーコード13のような状態)にはならない. +\end{itemize} +従って,\emph{\pTeX の既定では +コントロールワードに全角数字・アルファベット・ギリシャ文字を含めることができるが, +キリル文字は不可(コントロールシンボルのみ)である}ことがわかる +(\upTeX の既定では全て不可). +% upTeX の既定では,全角数字とアルファベット(Halfwidth and Fullwidth Forms)・ +% ギリシャ文字・キリル文字の全てが18である. + +\medskip + +和文カテゴリーコードを取得・設定するプリミティブが\.{kcatcode}である. \begin{cslist} \csitem[\.{kcatcode} <character code>=<16--18>] - コミュニティ版\pTeX では,和文文字のカテゴリーコード(|\kcatcode|)は + コミュニティ版\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} + }.\end{cslist} \begin{dangerous} |\kcatcode|では欧文文字の文字コード(0--255)も指定することができるが, その場合「0区扱い」として扱われる. \pTeX の処理でこの「0区」の|\kcatcode|が使われることはないので, 事実上は「16--18のどれかを格納可能な追加レジスタ」程度の使い方しかない. \end{dangerous} - -和文文字のカテゴリーコードの値による動作の違いは次のようになる: -\begin{itemize} - \item \TeX82では,「複数文字からなる命令」(コントロールワード)には - カテゴリーコードが11~($\mathit{letter}$)の文字しか使用できないことになっていたが, - \pTeX ではカテゴリーコードが16,~17の和文文字も合わせて使用することができる. - \item 一方,カテゴリーコードが18の和文文字はコントロールワード中には使用できない. - 「|\】|」のように一文字命令(コントロールシンボル)に使用することはできる - \footnote{「|\】|」のような和文のコントロールシンボルで行が終わった場合, - 「|\!|」のような欧文コントロールシンボルと同様に改行由来の空白が追加されてしまい, - 和文文字直後の改行は何も発生しないという原則に反していたが, - これは\TeX~Live 2019の\pTeX~3.8.2で修正された(\cite{tjb37}).}. - \item 後で説明する|\jcharwidowpenalty|は,カテゴリーコードが16,~17の和文文字の前にのみ - 挿入されうるもので,カテゴリーコードが18の和文文字の前には挿入されない. - \item 欧文文字は\TeX82と同様に1つの文字トークンはカテゴリーコード$c$と文字コード$s$の組 - み合わせ($256c+s$)で表現されていた.\pTeX では和文文字トークンは文字コードのみで表現さ - れ,そのカテゴリーコードは随時算出されるようになっている - \footnote{\upTeX では和文文字トークンについてもそのカテゴリーコードの情報が - 含まれるようになった.}. -\end{itemize} - -\pTeX においては,|\kcatcode|を上記の初期状態から変更することは想定されていない. -また,変更したとしても,和文文字トークンにカテゴリーコードの情報は保存されず, -和文文字が処理対象となるたびにカテゴリーコードの値が再取得される(この点が -\upTeX との実装上の最大の差異である. +しかし, +\pTeX においては,|\kcatcode|を文書の処理途中で変更することは想定されていない. +というのも,\pTeX では(\upTeX と異なり)和文文字トークンに +カテゴリーコードの情報は保存されず, +和文文字が処理対象となるたびにカテゴリーコードの値が随時算出されるためである. ただし,\pTeX でも |\let\CS=あ| などとして和文文字トークンを|\let|すると,|\CS|には その時のカテゴリーコード(|\kcatcode|)が保存される\footnote{コミュニティ版\pTeX では, 一時的に「和文文字トークンを|\let|した|\CS|においても,それが処理対象となるたびに カテゴリーコードの値を再取得する」という挙動に変更しようとした(r51021). しかし,この変更が不完全で「|\ifcat|では再取得するが,|\ifx|では再取得しない」という 不統一な状態となってしまったため,r59699で従来の挙動に戻した(アスキー版と同じ). -結果的に,\TeX~Live 2019--2021では「ただし,…」が当てはまらない(\cite{man4}).}). +結果的に,\TeX~Live 2019--2021では「ただし,…」が当てはまらない\cite{man4}.}. % 不統一な挙動になっているのは以下のバージョン. % * TeX Live 2019 rebuild 2019-05-30 (p3.8.2) % * TeX Live 2020 (p3.8.3) @@ -366,19 +745,77 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する \end{verbatim} \end{dangerous} -和文カテゴリーコード\.{kcatcode}の値は一応, -16が「漢字」,17が「かな」,18が「その他の和文記号」を意図している. -ただし区の中身を見れば分かる通り,\pTeX では特に -全角数字・アルファベット(3区)とギリシャ文字(6区)も17であり, -キリル文字(7区)は18となっている. -すなわち\emph{\pTeX の既定では -コントロールワードに全角数字・アルファベット・ギリシャ文字を含めることができるが, -キリル文字は不可(コントロールシンボルのみ)である}(\upTeX の既定では全て不可). -% upTeX の既定では,全角数字とアルファベット(Halfwidth and Fullwidth Forms)・ -% ギリシャ文字・キリル文字の全てが18である. +\subsection{和文カテゴリーコード,和文文字と欧文文字の区別【\upTeX の場合】} +\label{sec:uptex_kcat} +\upTeX においては\.{kcatcode}が\pTeX から大きく仕様変更されている +\footnote{\upTeX の正式用語としては,和文文字トークン(和文トークン)は +CJK文字トークン(CJKトークン)と呼ぶべきだが,本文書では単純化のため +\pTeX と同じ用語を用いる.}: +\begin{itemize} + \item |\kcatcode|プリミティブに和文文字の役割の分類だけでなく, + トークン列生成における和文文字と欧文文字の区別という機能も付与する. + 具体的には,\emph{\.{kcatcode}に特別な値として15~}($\mathit{not\_cjk})$\emph{を + 設定すると,それは8ビット欧文文字のバイト列として扱われ,和文扱いされなくなる}. + \item 和文文字に可能なカテゴリーコードとして19~($\mathit{hangul}$)を追加する. + \emph{カテゴリーコード19の和文文字は,直後の改行を欧文同様に空白とみなす} + という点が特別であり,それ以外の点ではカテゴリーコード16,~17の和文文字と同様である + (例えば,コントロールワード中にも使用できる). + \item \emph{和文文字トークンについてもカテゴリーコード}(\.{kcatcode})\emph{の情報を含む}. + 欧文トークンをcatcode 4bit + charcode 8bitで, + 和文トークンをkcatcode 5bit + charcode 24bitで表す. +\end{itemize} -\subsection{\pTeX の入力プロセッサ【\pTeX~4.0.0での改修を含む】}\label{sec:ptex_input} -\begin{figure}[tb] +\begin{cslist} + \csitem[\.{kcatcode} <character code>=<15--19>] + 内部レガシーの\upTeX では,\pTeX と同様に + JISコードでいう区ごとに値が設定可能. + 内部Unicodeの\upTeX では,和文カテゴリーコード(|\kcatcode|)は + 概ねUnicodeのブロックごと(※一部のブロックは分割してある)に値が設定可能である. + % 分割状況: https://github.com/texjporg/tex-jp-build/issues/43 +\end{cslist} + +なお\ref{sec:uptex_code}節で述べた通り,\upTeX では内部コードによらず +0--127の7ビットASCII文字集合は常に欧文文字トークンとして扱うこととしている. +裏を返せば\emph{和文文字トークンで文字コードが0--127という状況は +起こりえない}\footnote{和文文字ノードとしては文字コード0--127も可能: +\ref{sec:kchar}節で出てくる\.{kchar}で生成される.}し, +このブロックの|\kcatcode|を15以外に設定しても和文扱いはされない. +\begin{dangerous} +例えば\upTeX の既定(内部Unicode)から |\kcatcode`あ=15| を実行すると, +以降の「|あ|\relax」は |^^e3^^81^^82| を入力したとみなされる +\footnote{内部EUC-JPでは |^^a4^^a2|,内部Shift-JISでは |^^82^^a0|になる.}. +この状況で続けて |\kcatcode`あ=17| を実行しても, +それは |\kcatcode`^^e3^^81^^82| の入力とみなされるので元には戻らない: +代わりに |\kcatcode\ucs"3042=17| と実行する必要がある. +\end{dangerous} + +既定ではこのように和文と欧文が\.{kcatcode}の値(16--19か,15か)に従って +区別されるが,以下のプリミティブによって変更可能である. + +\begin{cslist} + \csitem[\.{enablecjktoken}] + 和文文字と欧文文字の区別について\.{kcatcode}の設定に従い, + 15なら欧文扱い,16以上なら和文扱いにする. + \upTeX の既定はこの状態である. + + \csitem[\.{disablecjktoken}] + 全てのUnicode文字を(\.{kcatcode}にかかわらず)欧文扱いにする(単なるバイト列として扱う). + 入力に関して(\code{ptexenc}ライブラリによる前処理を除き)8-bit欧文\TeX と互換になる. + + \csitem[\.{forcecjktoken}] + ASCII文字以外のUnicode文字を(\.{kcatcode}にかかわらず) + 強制的に和文扱いにする. + このとき,\.{kcatcode}が15の文字は「その他和文」(18)扱いになる. +\begin{verbatim} +\forcecjktoken\kcatcode`西=15 +\message{\the\kcatcode`@ % ==> 18 +\ifcat 西@ T\else F\fi}% ==> T +\end{verbatim} +\end{cslist} + +\subsection{\pTeX の入力プロセッサ}% \pTeX~4.0.0での改修を含む +\label{sec:ptex_input} +\begin{figure}[b] \small \[ \entrymodifiers={++[o][F-]} @@ -427,6 +864,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する \caption{\pTeX~4.0.0(既定)の入力プロセッサの状態遷移図} \label{fig:ptex_input} \end{figure} +% [TODO] カテゴリーコード 19 を図に入れていない 先に述べた通りであるが,\pTeX の入力プロセッサは\TeX82のそれを拡張したものになっている. \autoref{fig:ptex_input}は\emph{\pTeX~4.0.0既定時}における入力プロセッサの状態遷移図である. @@ -666,7 +1104,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する \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{tjb87}). + としてそれぞれ再現できる\cite{tjb87}. % * 欧文文字直後の改行では空白文字を発生させる % * コントロールワードや「\ 」の直後の改行は何も発生しない @@ -677,9 +1115,8 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する % ref. https://qiita.com/h-kitagawa/items/de963380bd3e576ab4e3 \end{dangerous} - - -\subsection{和文文字の文字列化の挙動【\pTeX~4.0.0での改修を含む】}\label{sec:printkanji16bit} +\subsection{和文文字の文字列化の挙動}% \pTeX~4.0.0での改修を含む +\label{sec:printkanji16bit} |\string|や|\meaning|などの文字トークン列生成については以下の通りである. \begin{itemize} \item 欧文文字は\TeX82と同様で,(文字コード32の空白を除き) @@ -691,7 +1128,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する \footnote{「|\】|」のように和文文字からなるコントロールシンボルを文字列化する際に, バージョンp3.7.2以前の\pTeX では「|\】 |」と後ろに余計な空白文字を補ってしまう という問題があった. - \TeX~Live 2018の\pTeX~3.8.1でこの問題は修正された(\cite{tjb37}).}. + \TeX~Live 2018の\pTeX~3.8.1でこの問題は修正された\cite{tjb37}.}. \item 和文文字はそのカテゴリーコードによらず,|\meaning|すると \begin{itemize}% すべて "kanji character " になる \item \the\kcatcode`漢:\quad \texttt{\meaning 漢} @@ -704,10 +1141,10 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する さて,\pTeX~version 3系列(\TeX~Live 2021まで)では|\meaning|,|\string|等の 文字列化や制御綴名において和文文字と欧文文字の区別が失われてしまうケースがあった. % 途中の結果を一旦配列 |str_pool| に格納する処理で和欧文の区別が失われていた. -\pTeX~4.0.0以降(\TeX~Live 2022)では,この状況でも +\emph{\pTeX~4.0.0以降}(\TeX~Live 2022)では,この状況でも 和欧文の区別が維持される\cite{tjb81}. \begin{dangerous} -\TeX~Live 2021では,ファイル文字コードUTF-8,内部コードEUC-JPの場合に例えば +\TeX~Live 2021では,ファイルのエンコードUTF-8,内部コードEUC-JPの場合に例えば \begin{verbatim} \def\fuga{^^c3^^bf 耽}\fuga \meaning\fuga @@ -737,9 +1174,376 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する % \label{^^c3^^bf}% % TL2021: 耽 => TL2022: ^^c3^^bf \end{dangerous} +\section{和文文字の出力}\label{sec:outchar} + +\TeX の実行プロセッサは展開不能トークンを実行し, +組版結果を出力リストとして構築していく. +このとき,文字トークンは\emph{文字ノード}に変換される. +また,文字コードの数値から文字ノードを生成できる +\.{char} <character code>や,その短縮形<control sequence>を +定義する\.{chardef} <control sequence>=<character code>も +同様に文字ノードを生成する. +この仕組みは\pTeX 系列でも同じであり, +ただし日本語の文字を出力するために和文文字ノードを使用する. +% TeX Wiki「TeX入門/マクロの作成」より整形 +% \TeX は最初に垂直モードで始まり, +% 展開不能トークンに従って処理を進めていく. +% 垂直モードでは,処理する要素がボックスや罫線であれば +% 次々に垂直方向に積み下げながら要素の高さや深さを積算していく. +% 決まった長さになるとページ分割し,そこまでの要素を +% DVIファイルの1ページ分として出力するためのoutputルーチンを起動する. +% これは|\output|というトークンリストレジスタに保存されたトークン列を +% 命令として実行する. +% 垂直モードでの処理中に「水平方向の要素」を見つけると, +% 自動的に水平モードに移行して行の作成作業に入る. +% ここで「水平方向の要素」と,文字トークンなど行中に配置すべきものである. +% 水平モードでは,文字や罫線を水平に並べながら幅を積算していき, +% 決まった長さになると行分割し,一行分をボックスにまとめて +% 外側の垂直ボックスに並べていく. +% 行分割しても段落が続く限り次の行を作り続け, +% 段落終了を意味する|\par|命令や空行を見つけると, +% 段落最後の行を作って元の垂直モードに復帰する. + +欧文文字ノードは1つの$\size{char\_node}$に +フォントと文字コードの情報を格納している. +和文文字ノードは内部的には連続する2つの$\size{char\_node}$を用いて +\begin{itemize} + \item 1つ目にフォントと文字タイプの情報 + \item 2つ目に文字コードの情報(\upTeX ではさらに\.{kcatcode}の情報も) +\end{itemize} +を格納している\footnote{ここで, +\pTeX では(和文文字トークンと同様)和文文字ノードに +\.{kcatcode}の情報が保存されず,必要に応じて +(=後述の\.{jcharwidowpenalty}挿入時)再計算される. +\upTeX では(こちらも和文文字トークンと同様)和文文字ノードに +\.{kcatcode}の情報が保存される(=後述の\.{jcharwidowpenalty}挿入のため).}. +% jtex.tex の「TFMファイルとcharノード」を簡略化 +% [TODO] upTeX での説明は合っているか? +% eptex_resume.pdf によると TeX--XeT の upTeX 対応で +% * pTeX では和文1文字が内部では2つのノードで表現されていることを前提にした. +% * upTeX のUnicode拡張によって1文字3ノードとかになっていないか心配したが +% どうやらそのような事態は起こっていないように思えた. +% と書かれているので,合っていると思われるが…. + +\subsection{文字ノードの生成}\label{sec:kchar} +実際に文字ノードが生成する状況は以下である. +\begin{itemize} + \item 欧文文字トークンは欧文フォントを使用した\emph{欧文文字ノード}になる. + \item 和文文字トークンは和文フォントを使用した\emph{和文文字ノード}になる. + \item \.{char}, \.{chardef}は文字コード0--255からは\emph{欧文文字ノード}を, + それ以外の文字コードからは\emph{和文文字ノード}を生成する + \footnote{\.{char}/\.{chardef}は文字トークンを経由しないので + \upTeX においても\.{kcatcode}は関係ない.}. +\end{itemize} + +ここで,\upTeX では\.{char}, \.{chardef}の挙動が問題になる. +これらは文字コードの数値から直接文字ノードを生成するが, +\pTeX および\upTeX の内部レガシーでは +欧文文字と和文文字の有効な文字コードが重ならないので, +生成すべき文字ノードの種類が文字コードによって一意に定まっていた. +ところが\upTeX の内部Unicodeでは,0--255の値が +欧文文字と和文文字のいずれの文字コードとしても有効であり, +\.{char}, \.{chardef}はそのうち欧文文字ノードを選択していることを意味する. +文字トークンに限っても128--255の値はいずれも有効であるのに, +このままでは,和文文字トークンから出力できる文字コード128--255の +和文文字ノードを,文字コードの数値からは直接出力できないことになる. + +そこで,\upTeX では新たに「必ず和文文字ノードを生成するプリミティブ」を +追加している.必要に駆られた128--255のみならず,便宜のため +文字コード0--127に対しても機能する.また内部コードによらず利用可能である. + +\begin{cslist} + \csitem[\.{kchar} <character code>(\emph{\upTeX のみ})] + \.{char}の和文固定版で, + 文字コード<character code>から和文文字ノードを生成する. + + \csitem[\.{kchardef} <control sequence>=<character code>(\emph{\upTeX のみ})] + \.{chardef}の和文固定版で, + \.{kchar} <character code>の短縮形として<control sequence>を定義する. +\end{cslist} + +\subsection{和文フォント} +\label{sec:jfont} +\TeX は組版を行うとき,文字の情報をTFMファイルから参照する. +\pTeX 系列も同様で,欧文文字についてはTFMファイルを参照するが, +和文文字についてはJFMファイルを参照する. +ファイル名はどちらも\code{フォント名.tfm}である. + +TFMファイルには,大別すると +\begin{itemize} + \item それぞれの文字に関する事柄 + (各文字の幅,高さ,深さなど) + \item そのTFMファイルに収められている文字に共通する事柄 + (文字の傾き,デザインサイズ,そのフォントの基準値(em, ex)など) + \item 特定の文字の組み合わせのときの事柄 + (合字やカーニングなど) +\end{itemize} +の3種類の情報が設定されている. +JFMファイルもTFMファイルと同様の情報を持つが, +\begin{itemize} + \item 日本語の文字は数が多いので, + 文字を単位とするのではなく,共通する性質を持つ文字を + 一つにまとめてタイプ別の設定を行う + \item 横組み用と縦組み用の区別がある +\end{itemize} +という点が異なる.JFMフォーマットの詳細は, +この文書と同じディレクトリにある\cite{jfm}を参照されたい. + +% [TODO] 一つの文書で用いることができるフォント数の上限は? + +\begin{cslist} +\csitem[\.{jfont}, \.{tfont}] + 欧文フォントを定義したり,現在の欧文フォントを取得したりする|\font|の和文版である. + 一応|\jfont|が「和文の横組用フォント」の,|\tfont|が「和文の縦組用フォント」のために + 用いる命令である. +\begin{itemize} + \item フォントを定義する際は,欧文フォント・和文の横組用フォント・ + 和文の縦組用フォントのいずれも + |\font|, |\jfont|, |\tfont|のどれを用いても定義できる + (要求された実際のTFM/JFMに応じて,自動的にアサインされる). + 書式については後述. + \item |\the|等で「現在のフォント」を取得する際には, + |\jfont|で「和文の横組用フォント」を, + |\tfont|で「和文の縦組用フォント」を返す. + \item |\nullfont|は全ての文字が未定義な「空フォント」を指すが, + これは欧文フォントであり,和文版|\nullfont|という概念は存在しない. + これは,\pTeX では「全ての和文フォントには,和文文字コードとして有効な + 全ての文字が存在する」という扱いになっているためである. +\end{itemize} +\end{cslist} + +\begin{dangerous} + 細かい話をすれば,\pTeX のini modeでのフォーマット作成時に和文フォントを + 何も選択しなければ,|\fontname\jfont|が|nullfont|となり, + また和文文字を入力してもノードは作られない\footnote{ただし, + $\.{tracinglostchars}>0$でも + \code{Missing character: There is no あ in font nullfont!}のような + 警告は出ない.}ので, + 「和文版|\nullfont|が選択されている」と言えなくもない. + ただ,いったん実際の和文フォントを選択した後に + 「和文版|\nullfont|を選択する」という制御綴は作れないと思われる. + % つまり,tikzpicture 環境のように|\selectfont|を|\nullfont|に + % 再定義した状態では,和文文字だけ消えずに残る. + % https://tex.stackexchange.com/questions/18602/ + % https://twitter.com/doraTeX/status/1098584763277824000 + % 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テーブル内には +% 文字コードの昇順で収められていなければならない」という規定を前提に +% 検索最適化されているのに対し,エンコード変換が絡むと順番が崩れるためである. +なお,<in spec>のスキャン時には展開を行わない. +これは後続の<control sequence>が未定義のときに先にエラーを発するのを防ぐためである. + +\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>が和文の横組用フォントかどうか, + |\iftfont|は和文の縦組用フォントかどうかを判定する. + 2020-02-05のコミット(r53681)で追加され, + \TeX~Live 2020の\pTeX~(p3.8.3)で利用可能である. + + これにより,例えば\.{HOGE}が和文フォントか否かは +\begin{verbatim} +\ifjfont\HOGE + (和文の横組用フォント) +\else\iftfont\HOGE + (和文の縦組用フォント) +\else + (欧文フォント) +\fi +\end{verbatim} + として判定できる. +\end{cslist} + +\begin{dangerous} + 上述の通り,欧文フォント・和文の横組用フォント・ + 和文の縦組用フォントのいずれも|\font|一つで定義可能だが, + 定義したフォントが実際にどの種類だったかを知る手段は + バージョンp3.8.2までの\pTeX には存在しなかった. + % https://github.com/texjporg/tex-jp-build/pull/97 +\end{dangerous} + +\begin{dangerous} + ちなみに,\epTeX, \eupTeX には\.{iffontchar}プリミティブが存在する. + しかし,<\,font>が和文フォントか否かを判定するために + \texttt{\.{iffontchar}~<\,font>~256}などと第二引数に256以上の値を指定することはできない. + なぜなら,欧文フォントに対し第二引数に0--255以外の値を指定すると + 「\verb+! Bad character code (...).+」エラーが発生するからである. +\end{dangerous} + +\begin{cslist} +\csitem[\.{jfam}=<number>] + 現在の和文数式フォントファミリの番号を格納する + \footnote{\pTeX,~\upTeX では0--15の範囲が許される. + \epTeX, \eupTeX では欧文の|\fam|と共に0--255に範囲が拡張されている.}. + 現在の欧文数式ファミリの番号を格納する|\fam|と原理的に同じ番号を指定することは + 原理的には可能だが,数式ファミリは和文・欧文共用であるので実際には + 異なる値を指定することになる. + + 欧文フォントが設定されている数式ファミリの番号を|\jfam|に指定し, + 数式中で和文文字を記述すると +\begin{verbatim} +! Not two-byte family. +\end{verbatim} + というエラーが発生する.逆に,和文フォントが設定されているファミリの番号を + |\fam|に指定し,数式中に欧文文字を記述すると +\begin{verbatim} +! 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{\pTeX 系列の組版処理} + +和文文字を単に出力できるだけでは,日本語の組版としてまともにならない. +\pTeX 系列は,禁則を考慮した行分割処理, +和文文字と欧文文字のスペーシングといった日本語特有の組版機能を有している. + % jtex.tex の「ラインブレーク」を簡略化 -\section{禁則} +\subsection{禁則} \label{sec:kinsoku} + 欧文と和文の処理で見かけ上最も大きな違いは,行分割処理であろう. \begin{itemize} \item 欧文中での行分割は,ハイフネーション処理等の @@ -874,8 +1678,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する % また,その位置がすでにペナルティであった場合は,|\jcharwidowpenalty|の値が合算される. \end{cslist} -\section{文字間のスペース} - +\subsection{文字間のスペース} 欧文では単語毎にスペースが挿入され,その量を調整することにより行長が調整される. 一方,和文ではそのような調整ができる箇所がほぼ存在しない代わりに, ほとんどの場合は行長を全角幅の整数倍に取ることで, @@ -1067,7 +1870,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する \end{itemize} 以前の\pTeX では「この命令が実行された位置」が何を指すのか大雑把でわかりにくかったが, \TeX~Live 2019の\pTeX~3.8.2以降では,明確に\emph{新たなノードが追加されない限り},と - 定めた(\cite{tjb28,forum_2566}).すなわち, + 定めた\cite{tjb28,forum_2566}.すなわち, \begin{enumerate} \item |\inhibitglue|は,ノード挿入処理を行う命令 (|\null|,~|\hskip|, |\kern|, |\vrule|,~\dots)が後ろに来た場合は無効化される. @@ -1112,10 +1915,7 @@ UTF-8ファイル入力を内部コードEUC-JPまたはShift-JISに変換する \pTeX~3.8.2で新しく追加された. \end{cslist} - - -\section{組方向} - +\subsection{組方向} % ptexdoc.tex の「ディレクション」を簡略化 従来の\TeX では,字送り方向が水平右向き(→),行送り方向が垂直下向き(↓) に固定されていた.\pTeX では,\TeX の状態として“組方向(ディレクション)” @@ -1262,13 +2062,12 @@ DtoU方向での数式ディレクションはそれぞれ非数式の場合と バージョンp3.7までの\pTeX では,ボックスが一旦ノードとして組まれてしまうと, 通常の縦組で組まれているのか,それとも縦数式ディレクションで組まれているのか という情報が失われていた.しかし,それでは後述の「ベースライン補正の戻し量」を - 誤り,欧文の垂直位置が揃わないという問題が生じた(\cite{tatemath}). + 誤り,欧文の垂直位置が揃わないという問題が生じた\cite{tatemath}. この問題を解決する副産物として,バージョンp3.7.1で|\ifmbox|プリミティブが実装された. \end{cslist} -\section{ベースライン補正} +\subsection{ベースライン補正} \label{sec:baselineshift} - 和文文字のベースラインと欧文文字のベースラインが一致した状態で組むと, 行がずれて見えてしまう場合がある.特に縦組の状況が典型的である (\autoref{tab-dir}の「組版例」参照). @@ -1355,281 +2154,15 @@ $10\,\mathrm{pt}-7\,\mathrm{pt}=3\,\mathrm{pt}$だけ上に配置されてしま なお,|\scriptscriptbaselineshiftfactor|についても全く同様の注意が当てはまる. \end{dangerous} -\section{和文フォント} -\label{sec:ptexfont} - -\TeX は組版を行うとき,文字の情報をTFMファイルから参照する. -\pTeX も同様で,欧文文字についてはTFMファイルを参照するが, -和文文字についてはJFMファイルを参照する. -ファイル名はどちらも\code{フォント名.tfm}である. - -TFMファイルには,大別すると -\begin{itemize} - \item それぞれの文字に関する事柄 - (各文字の幅,高さ,深さなど) - \item そのTFMファイルに収められている文字に共通する事柄 - (文字の傾き,デザインサイズ,そのフォントの基準値(em, ex)など) - \item 特定の文字の組み合わせのときの事柄 - (合字やカーニングなど) -\end{itemize} -の3種類の情報が設定されている. -JFMファイルもTFMファイルと同様の情報を持つが, -\begin{itemize} - \item 日本語の文字は数が多いので, - 文字を単位とするのではなく,共通する性質を持つ文字を - 一つにまとめてタイプ別の設定を行う - \item 横組み用と縦組み用の区別がある -\end{itemize} -という点が異なる.JFMフォーマットの詳細は, -この文書と同じディレクトリにある\cite{jfm}を参照されたい. - -% [TODO] 一つの文書で用いることができるフォント数の上限は? - -\begin{cslist} -\csitem[\.{jfont}, \.{tfont}] - 欧文フォントを定義したり,現在の欧文フォントを取得したりする|\font|の和文版である. - 一応|\jfont|が「和文の横組用フォント」の,|\tfont|が「和文の縦組用フォント」のために - 用いる命令である. -\begin{itemize} - \item フォントを定義する際は,欧文フォント・和文の横組用フォント・ - 和文の縦組用フォントのいずれも - |\font|, |\jfont|, |\tfont|のどれを用いても定義できる - (要求された実際のTFM/JFMに応じて,自動的にアサインされる). - 書式については後述. - \item |\the|等で「現在のフォント」を取得する際には, - |\jfont|で「和文の横組用フォント」を, - |\tfont|で「和文の縦組用フォント」を返す. - \item |\nullfont|は全ての文字が未定義な「空フォント」を指すが, - これは欧文フォントであり,和文版|\nullfont|という概念は存在しない. - これは,\pTeX では「全ての和文フォントには,和文文字コードとして有効な - 全ての文字が存在する」という扱いになっているためである. -\end{itemize} -\end{cslist} - -\begin{dangerous} - 細かい話をすれば,\pTeX のini modeでのフォーマット作成時に和文フォントを - 何も選択しなければ,|\fontname\jfont|が|nullfont|となり, - また和文文字を入力してもノードは作られない\footnote{ただし, - $\.{tracinglostchars}>0$でも - \code{Missing character: There is no あ in font nullfont!}のような - 警告は出ない.}ので, - 「和文版|\nullfont|が選択されている」と言えなくもない. - ただ,いったん実際の和文フォントを選択した後に - 「和文版|\nullfont|を選択する」という制御綴は作れないと思われる. - % つまり,tikzpicture 環境のように|\selectfont|を|\nullfont|に - % 再定義した状態では,和文文字だけ消えずに残る. - % https://tex.stackexchange.com/questions/18602/ - % https://twitter.com/doraTeX/status/1098584763277824000 - % 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} +\section{その他の補助機能} -\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>が和文の横組用フォントかどうか, - |\iftfont|は和文の縦組用フォントかどうかを判定する. - 2020-02-05のコミット(r53681)で追加され, - \TeX~Live 2020の\pTeX~(p3.8.3)で利用可能である. - - これにより,例えば\.{HOGE}が和文フォントか否かは -\begin{verbatim} -\ifjfont\HOGE - (和文の横組用フォント) -\else\iftfont\HOGE - (和文の縦組用フォント) -\else - (欧文フォント) -\fi -\end{verbatim} - として判定できる. -\end{cslist} - -\begin{dangerous} - 上述の通り,欧文フォント・和文の横組用フォント・ - 和文の縦組用フォントのいずれも|\font|一つで定義可能だが, - 定義したフォントが実際にどの種類だったかを知る手段は - バージョンp3.8.2までの\pTeX には存在しなかった. - % https://github.com/texjporg/tex-jp-build/pull/97 -\end{dangerous} - -\begin{dangerous} - ちなみに,\epTeX, \eupTeX には\.{iffontchar}プリミティブが存在する. - しかし,<\,font>が和文フォントか否かを判定するために - \texttt{\.{iffontchar}~<\,font>~256}などと第二引数に256以上の値を指定することはできない. - なぜなら,欧文フォントに対し第二引数に0--255以外の値を指定すると - 「\verb+! Bad character code (...).+」エラーが発生するからである. -\end{dangerous} - -\begin{cslist} -\csitem[\.{jfam}=<number>] - 現在の和文数式フォントファミリの番号を格納する - \footnote{\pTeX,~\upTeX では0--15の範囲が許される. - \epTeX, \eupTeX では欧文の|\fam|と共に0--255に範囲が拡張されている.}. - 現在の欧文数式ファミリの番号を格納する|\fam|と原理的に同じ番号を指定することは - 原理的には可能だが,数式ファミリは和文・欧文共用であるので実際には - 異なる値を指定することになる. - - 欧文フォントが設定されている数式ファミリの番号を|\jfam|に指定し, - 数式中で和文文字を記述すると -\begin{verbatim} -! Not two-byte family. -\end{verbatim} - というエラーが発生する.逆に,和文フォントが設定されているファミリの番号を - |\fam|に指定し,数式中に欧文文字を記述すると -\begin{verbatim} -! 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{文字コード変換,漢数字} - -\pTeX の内部コードは環境によって異なる.そこで,異なる文字コード間で同じ文字を -表現するため,文字コードから内部コードへの変換プリミティブが用意されている. +\subsection{文字コード変換,漢数字} +\label{sec:convert} +先述(\ref{sec:getcode}節)の通り, +和文文字の文字コードを数値で指定するには内部コードで表現する必要があるが, +それはEUC-JP/Shift-JIS/Unicodeと様々である. +異なるエンコード間でも同じ文字を数値で直接表現できるように, +文字コード変換を行うプリミティブが用意されている. また,漢数字を出力するプリミティブも用意されている\footnote{% 実は|\kansuji|, |\kansujichar|プリミティブはp3.1.1でいったん削除され, p3.1.2で復活したという経緯がある.}. @@ -1697,9 +2230,9 @@ p3.1.2で復活したという経緯がある.}. % => ptexenc に従う.ただし \jis, \sjis, \euc, \kuten, \ucs, \toucs の % 返り値が 0 の場合は -1 を表示. % * uptex-m.ch の実装 -% => ptexenc 及び ptex-base.ch に従う.ただし,内部コード uptex の時の +% => ptexenc および ptex-base.ch に従う.ただし,内部コード uptex の時の % \ucs0 と \toucs0 は(ptex-base.ch が無条件に -1 を表示しようとするが, -% ここは無変換とすべきなので)0 を表示. +% ここは恒等変換とすべきなので)0 を表示. % %%% \end{dangerous} @@ -1751,7 +2284,7 @@ p3.1.2で復活したという経緯がある.}. |\kansujichar|は整数値パラメータであるが,p3.8.2までは 「代入できるが取得はできない」という挙動であった (例えば|\count255=\kansujichar1|はエラー). - \pTeX~3.8.3で取得もできるように修正された(\cite{tjb93})が, + \pTeX~3.8.3で取得もできるように修正された\cite{tjb93}が, 以前の\pTeX も考慮すると,値の取得は以下のようにするのが安全である: |\count255=\expandafter`\kansuji1| % \count123=\kansujichar45 のように \kansujichar の引数が不正な場合は, @@ -1806,8 +2339,7 @@ p3.1.2で復活したという経緯がある.}. とすれば,|\日本|という和文の制御綴をASCII文字だけで定義できる. \end{dangerous} -\section{長さ単位} - +\subsection{長さ単位} \pTeX では\TeX82に加えて以下の単位が使用可能である: \begin{cslist} \csitem[\texttt{zw}\index{zw=\texttt{zw}}] @@ -1844,8 +2376,9 @@ p3.1.2で復活したという経緯がある.}. 写植機における文字の大きさの単位であるQ数(級数)と,字送り量や行送り量の単位である歯数に由来する. \end{cslist} -\section{バージョン番号} - +\subsection{バージョン番号} +コミュニティ版の\pTeX 系列独自で,\TeX~Live 2018以降に +バージョン番号を返す機能を(\eTeXpre)(u)\pTeX に追加した. \begin{cslist} \csitem[\.{ptexversion}, \.{ptexminorversion}, \.{ptexrevision}] \pTeX のバージョン番号はp$x{.}y{.}z$の形式となっており,それらを取得するための命令である. @@ -1857,6 +2390,31 @@ p3.1.2で復活したという経緯がある.}. \end{verbatim} で取得できる.\pTeX~3.8.0で導入された. \end{cslist} +この追加と同時に,(\eTeXpre)\upTeX では以下が追加されている. +\begin{cslist} + \csitem[\.{uptexversion}, \.{uptexrevision}] + \upTeX のバージョン番号はu$x{.}y$の形式となっており, + それらを取得するための命令である. + \.{uptexversion}は$x$の値を内部整数で返し, + \.{uptexrevision}はその後ろの「${.}y$」を文字列で返す. +\end{cslist} +さらに\eTeXpre(u)\pTeX には\.{epTeXversion}プリミティブがある +(\texttt{./eptexdoc.pdf}を参照). + +\medskip + +この文書は\eTeXpre\ifx\kchardef\undefined\else u\fi\pTeX で処理しているので, +バージョン番号全体を表示すると +\begin{quote} +\texttt{This is + \ifx\eTeXversion\undefined\else e-\fi + \ifx\enablecjktoken\undefined\else u\fi + pTeX p\the\ptexversion.\the\ptexminorversion\ptexrevision + \ifx\enablecjktoken\undefined\else -u\the\uptexversion\uptexrevision\fi + \ifx\epTeXversion\undefined\else -\the\epTeXversion + -\the\eTeXversion\eTeXrevision\fi} +\end{quote} +となる. \newpage @@ -1910,11 +2468,12 @@ p3.1.2で復活したという経緯がある.}. \begin{cslist} \csitem[\.{char} <character code>, \.{chardef} <control sequence>=<character code>] + 先に\ref{sec:outchar}節でも述べた通り, 引数として0--255に加えて和文文字の内部コードも指定できる. 和文文字の内部コードを指定した場合は和文文字を出力する. \csitem[\.{font}, \.{fontname}, \.{fontdimen}] - |\font|については\ref{sec:ptexfont}節を参照. + |\font|については\ref{sec:jfont}節を参照. |\fontname|は和文フォントからもフォント名を取得でき, |\fontdimen|は和文フォントのパラメータ表(JFMで定義される\node{param}テーブル)からも 値を取得できる. @@ -1976,7 +2535,7 @@ has been |\let| equal to a non-active character token. 一方,文字コードについては,確かにtex.webは|\if|判定において コントロールシークエンスを256とみなしている.しかし,\upTeX では 文字コード256の和文文字と衝突するので,2019-05-06のコミット(r51021)で -「原理的に文字コードが取り得ない値」に変更した(\cite{tjb68}). +「原理的に文字コードが取り得ない値」に変更した\cite{tjb68}. \end{dangerous} \newpage @@ -2049,7 +2608,7 @@ has been |\let| equal to a non-active character token. \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} + \url{https://okumuralab.org/tex/mod/forum/discuss.php?d=2566} \bibitem{tjb68} aminophen, 「upTeX の |\if| と |\ifcat|」, 2019/01/17,\\ \url{https://github.com/texjporg/tex-jp-build/issues/68} @@ -2062,6 +2621,9 @@ has been |\let| equal to a non-active character token. \bibitem{tjb81} h-kitagawa, 「バイト列と和文文字トークンの区別」, 2019/06/08,\\ \url{https://github.com/texjporg/tex-jp-build/issues/81} + \bibitem{tjb142} t-tk, 「[ptexenc] 入力ファイルの文字コードの自動判定」, + 2022/06/05,\\ + \url{https://github.com/texjporg/tex-jp-build/issues/142} \bibitem{tjb149} aminophen, 「[upTeX] JIS-encoded TFM」, 2022/10/15,\\ \url{https://github.com/texjporg/tex-jp-build/issues/149} |