☃、☃☃☃☃☃！
☃☃～☃☃☃～、☃☃☃☃。
☃☃☃☃～☃、☃☃～～～～～☃、☃☃☃☃☃、☃☃☃☃☃。☃☃～☃、☃～～～☃～～～☃～～～☃☃☃～、☃☃～～☃☃～～☃☃～～☃☃☃～。☃～～～～～～～～～～～～！！
☃☃☃。
☃
☃☃☃☃☃！
（☃☃☃）
メモ：Pandocでのメタデータ指定の挙動
メタデータの値の型
※Luaフィルタ特有のLuaメタテーブルをもつテーブル値のことを（マニュアルに倣って）「オブジェクト(object)」と呼ぶことにする。特に、tag値がFooであるオブジェクトを「Fooオブジェクト」と呼ぶ。
- MetaBool： 真偽値。
- Lua真偽値で表される。
- MetaString： 文字列。
- Lua文字列値で表される。
- MetaInlines： インライン要素のリスト。
- MetaInlinesオブジェクトで表される。
- 「インライン要素オブジェクト」のListオブジェクトとして機能する。
- MetaBlocks： ブロック要素のリスト。
- MetaBlocksオブジェクトで表される。
- 「ブロック要素オブジェクト」のListオブジェクトとして機能する。
- MetaList： メタデータ値のリスト。
- MetaMap： 文字列からメタデータ値への写像。
- MetaMapオブジェクトで表される。
- “連想配列としてのテーブル”として扱える。例えば、pairs関数でキー値ペアを列挙できる。
※MetaInlinesやMetaBlocksも実質的にListオブジェクトなので、Luaシーケンスとして扱える。
仕様（documentedな話）
コマンド行のオプション（--metadata/-M）で指定するメタデータは必ず真偽値か文字列として扱われる。
Values will be parsed as YAML boolean or string values. If no value is specified, the value will be treated as Boolean true.
メタデータファイル（--metadata-file）んそ指定は、Pandoc’s Markdownのメタデータブロックと同様に扱われる。（ただし入力形式がMarkdown以外でも使える。）
Generally, the input will be handled the same as in YAML metadata blocks.
既定値ファイル（--defaults/-d）のフィールドはコマンド行オプションに対応する。
FILE is a YAML file whose fields correspond to command-line option settings.
既定値ファイルでの設定は、コマンド行オプションによって上書きまたは拡張される。
Settings from the defaults file may be overridden or extended by subsequent options on the command line.
複数指定できるオプション（--metadataも含む）の場合は上書きではなく拡張になる。
Note that, where command-line arguments may be repeated (…), the values specified on the command line will combine with values specified in the defaults file, rather than replacing them.
メタデータブロック（またはメタデータファイル）で設定されるメタデータ値はリストやオブジェクトでもよい。文字列のスカラー値はMarkdownのソースとして解釈される。
Metadata will be taken from the fields of the YAML object and added to any existing document metadata. Metadata can contain lists and objects (nested arbitrarily), but all string scalars will be interpreted as Markdown.
実際の動作（undocumentedな話）
コマンド行オプション（--metadata/-M）
オプションで指定した値の文字列が、そのままMetaString型のメタデータ値となる2。ただし例外として、true/True/TRUE/false/False/FALSEは真偽値として解釈されて3MetaBool型のメタデータ値となる。また、値を省略した場合（-M フィールド）はMetaBool型のtrueとなる。
-M foo=Bar→ fooの値はMetaString["Bar"]。-M foo=42→ fooの値はMetaString["42"]（文字列）。-M foo=yes→ fooの値はMetaString["yes"]。-M foo=[42.00]→ fooの値はMetaString["[42.00]"]。-M foo=true→ fooの値はMetaBool[true]。-M foo=False→ fooの値はMetaBool[false]。-M foo=truE→ fooの値はMetaString["truE"]（文字列！）。-M foo=false,0→ fooの値はMetaString["false,0"]。-M foo→ fooの値はMetaBool[true]（値を省略）。-M foo=→ fooの値はMetaString[""]（値が空文字列）。
同じフィールドを複数回指定した場合は、各々のメタデータ値を順に並べたMetaList値として扱われる。オプションで指定したメタデータ値がMetaMapになることは恐らくない。
-M foo=Baz -M foo=Bar
→ fooの値はMetaList[MetaString["Baz"],MetaString["Bar"]]。-M foo=0 -M foo=TRUE
→ fooの値はMetaList[MetaString["0"],MetaBool[true]]。-M foo.bar=54
→ foo.barというフィールドがMetaString["54"]に設定される。fooがMetaMapになるのではない。
既定値ファイル（--defaults/-d）
既定値ファイルの内容はYAMLのマッピング値として解釈され、そのmetadataキーに対する値（これもマッピング値でないといけない）がメタデータとして解釈される。
- YAMLのスカラー値は全て（真偽値も含めて）MetaString型の値に変換される。
- 文字列値（
!!str型）はそのまま。 - 真偽値（
!!bool型）は、真（true/True/TRUE）はtrue、偽（false/False/FALSE）は空文字列になる。MetaBool値になるのではない。 - 数値（
!!int型・!!float型）は、その典型的な文字列表現になる。intの42は42、floatの42は42.0、無限大（.inf）はInfinity、等。 - Null値（
!!null型、表記は~/null等）は空文字列になる4。
- 文字列値（
- YAMLのシーケンス値はそのままMetaList型の値になる。
- YAMLのマッピング値はそのままMetaMap型の値になる。
例えば次のような内容の既定値ファイルを指定したとする。
metadata: foo1: blah foo2: "false" bar1: 0x42 bar2: 042.000 gee1: True gee2: FALSE whiz1: [true,false] whie2: - false - true whiz3: boo: ! 0x42
- foo1の値は
MetaString["blah"]。 - foo2の値は
MetaString["false"]。（" "囲いなのでYAMLで文字列型と見なされる。） - bar1の値は
MetaString["66"]。（YAMLで整数の66と見なされるので） - bar2の値は
MetaString["42.0"]。 - gee1の値は
MetaString["true"]。（MetaBoolではない。） - gee2の値は
MetaString[""]。（なぜかfalseは空になる。） - whiz1の値は
MetaList[MetaString["true"],MetaString[""]]。 - whiz2の値は
MetaList[MetaString[""],MetaString["true"]]。 - whiz3の値は
MetaMap[("boo",MetaString["0x42"])]。（!が文字列型を強制するのでYAMLで文字列の0x42と解釈されている。）
（つづけ）
メモ：xeCJKの空白関連のパラメタ
xeCJKパッケージの動作設定命令（\xeCJKsetup）のオプションキーのうち、「空白の設定」に関するものについて、チョット調べてみた。
※ただし「句読点スタイル（）」に関するもの（PunctStyleなど）は除く。
※XeTeXでは（元祖TeXと同様に）空行にならない改行は常に空白文字と同等に扱われる。(u)pTeXのような「改行を特殊に扱う規則」を実装することは不可能である1。
マニュアルの記述
……チョット日本人には解りにくいね。
日本語でおｋ
CJKspace［真偽値；省略時＝true2；既定値＝false］- false： CJK文字同士の間の空白文字を無視する。
- true： CJK文字同士の間の空白文字は欧文空白になる。
CJKglue［テキスト；既定値＝{\hskip 0pt plus 0.08\baselineskip}］ CJK文字間に挿入する空きを生成する命令を指定する。両端寄せを行うため、このオプションを設定する場合は伸縮する空きを設定すべきである。CJKecglue［テキスト；既定値＝{ }（欧文空白）］ CJK文字と欧文、およびCJK文字と数式の間の空きを生成する命令を指定する。このオプションを設定する場合は伸縮する空きを設定すべきである。注意すべき点として、この設定はxeCJKが自動的に挿入する空きにのみ影響し、CJK文字と欧文の間に明示的に入れた空白文字の出力には影響しない。空きの自動挿入はうまく機能しない場合があり、そのときは手動で空白文字を入れる必要がある。xCJKecglue［真偽値またはテキスト；省略時＝true；既定値＝false］- false： CJK文字と欧文の間に明示的に入れた空白文字をそのまま欧文空白といて出力する。
- true： CJK文字と欧文の間に明示的に入れた空白文字について、その箇所が「CJKecglueの空白」が入るべきである場合に、欧文空白でなく「CJKecglueの空白」として出力する。
- テキスト：
xCJKecglue=trueとCJKecglue=テキストを設定するのと等価になる。
BXjsclsが新しくなった（v2.0a）
2020-03-25にBXjsclsの新しいメジャーバージョンとなる2.0版がリリースされた。TeX Liveについては、2020-04-10にリリースされたTeX Live 2020の初期版が2.0版となる。現在の最新版は2.0a版である。
メジャー改版であるため後方互換性を損なう仕様変更が含まれる。注意してほしい。
※2.0→2.0a版の違いは、一部の非推奨機能への警告の追加のみである1。
【仕様変更】LuaLaTeX／XeLaTeXで既定の和文フォントが「原ノ味フォント」に変わった
TeX Live 2020において、updmapでの和文（日本語）のフォントの既定値がipaexからharanoajiに変更された2。つまり、(u)pLaTeXの標準和文フォントとして使われる物理フォントが「IPAexフォント」から「原ノ味フォント」変わることになる。これに追随する形で、LuaTeX-jaにおける既定の和文フォントも「IPAexフォント」から「原ノ味フォント」に変更された。
そこで、BXjsclsクラスもこれに追随して、LuaLaTeX／XeLaTeX上の動作における既定の和文フォントを「IPAexフォント」から「原ノ味フォント」に変更することにした3。
% LuaLaTeX文書; UTF-8 % フォント指定(jafont)が無い \documentclass[lualatex,ja=standard,a4paper]{bxjsarticle} \begin{document} ☃っ☃☃☃っ☃っ☃～～♪ \end{document}
フォント指定（jafontオプション）のない上掲の文書をlualatexでコンパイルした場合、旧版では「IPA明朝」で出力される。
対して、新版（2.0版以降）では「原ノ味明朝」で出力される。
なお、和文フォントのプリセットの種類はjafontで指定できるので、「IPAexフォント」で出力したい場合はクラスオプションにjafont=ipaexを指定すればよい。
% LuaLaTeX文書; UTF-8 %フォント指定(jafont=ipaex)がある \documentclass[lualatex,ja=standard,jafont=ipaex, a4paper]{bxjsarticle} \begin{document} ☃っ☃☃☃っ☃っ☃～～♪ \end{document}
LuaLaTeX・XeLaTeX以外の話
(u)pLaTeX上の動作の場合は、BXjsclsのクラスは和文フォント（のフォントマップ）の指定を何も行わず、従ってDVIウェアの設定（TeX Liveの場合はupdmapの設定）がそのまま適用される。従ってTeX Live 2020であれば、LuaLaTeX／XeLaTeXと同様に「原ノ味フォント」が使用される4。
pdfLaTeXで和文を扱う場合は和文フォントを「Type1形式のサブフォント」として用意する必要がある。現状では「原ノ味フォント」のType1形式サブフォントは存在しないので、従来の「IPAexのType1形式サブフォント」（ipaex-type1パッケージ）が引き続き既定値として用いられる。
【仕様変更】\ifdraft が廃止された
開発者用命令5の\ifdraftは1.2版（2016-08-01）において既に非推奨の扱いになっていたが、2.0版において廃止された。代わりの開発者用命令として\ifjsDraftが用意されているので、そちらを利用する必要がある。
※ユーザレベルで「draftモードであるかを判定したい」場合は、ifdraftパッケージの使用を推奨する。
※\ifdraftはjsclassesの機能を継承したものであるが、本家のjsclassesにおいては\ifdraftは2016年7月に（非推奨ではなく）廃止されている。「ifdraftパッケージと衝突する」という問題があったためである。
【仕様変更】geometry 4.x版のサポートを廃止した
geometry 4.x版の使用は1.2版（2016-08-01）において既に非推奨となっていたが、2.0版ではgeometryの4.x版のサポートが廃止となり、5.0版（2010-02-12）以降が必須となる。
イロイロ非推奨になった
既に1.9版のリリースのときに予告されていたように、旧版との互換のための機能の多くが2.0版で非推奨の扱いとなった。（廃止ではない。）
“ja”オプションの省略は非推奨
エンジンが(u)pLaTeX以外の場合に和文ドライバ指定（jaオプション）を省略した場合はminimalが指定されていた。
% XeLaTeX文書; UTF-8 \documentclass[xelatex,a4paper]{bxjsarticle} \usepackage{zxjatype} \setCJKmainfont{IPAexMincho} \setCJKsansfont{IPAexGothic} \begin{document} {\TeX}言語\textsf{危険}、ダメゼッタイ。 \end{document}
以前の版において既にjaオプションを明示することが“推奨”されていたが、2.0版において正式に、省略が非推奨となった。2.0a版においてはjaを省略すると以下のような警告が出る。
Class bxjsarticle Warning: The option 'ja' is MISSING!! (bxjsarticle) So 'ja=minimal' is assumed as fallback, but (bxjsarticle) such implicit setting is now DEPRECATED! (bxjsarticle) You should write 'ja=minimal' explicitly, (bxjsarticle) if it is intended.
以前の動作を保ちたい場合はja=minimalを指定すべきである。
% XeLaTeX文書; UTF-8 % 和文ドライバを明示的に指定する \documentclass[xelatex,ja=minimal,a4paper]{bxjsarticle} \usepackage{zxjatype} \setCJKmainfont{IPAexMincho} \setCJKsansfont{IPAexGothic} \begin{document} {\TeX}言語\textsf{危険}、ダメゼッタイ。 \end{document}
ただし実際には「minimalモード」ではなく「standardモード」を使う方が妥当6であることが多いはずである。今まで“ja無し”で使っていた人は「standardモード」への移行を検討してほしい。
% XeLaTeX文書; UTF-8 % standardモードの方が便利 \documentclass[xelatex,ja=standard,jafont=ipaex,a4paper]{bxjsarticle} \begin{document} {\TeX}言語\textsf{危険}、ダメゼッタイ。 \end{document}
※エンジンが(ujpLaTeXである場合はjaの既定値はstandardであり、この場合はjaの省略は非推奨ではない。
“dvipdfmx-if-dvi”オプションは非推奨 → “dvi=dvipdfmx”
現在のBXjsclsには「DVIモードでのみ適用されるドライバ指定」を行うためのdviオプションがあるが、昔はdvi=dvipdfmxに相当するdvipdfmx-if-dviというオプションが利用されていた。
% エンジン自動判別, DVIモード時はdvipdfmxドライバを指定 \documentclass[autodetect-engine,dvipdfmx-if-dvi,ja=standard]{bxjsbook}
dvipdfmx-if-dviは2.0版で非推奨の扱いとなり、2.0a版では警告が出る。
Class bxjsbook Warning: The old option 'dvipdfmx-if-dvi' is DEPRECATED (bxjsbook) and may be abolished in future! (bxjsbook) You should write 'dvi=dvipdfmx' instead.
代わりにdvi=dvipdfmxを指定すべきである。
% エンジン自動判別, DVIモード時はdvipdfmxドライバを指定 \documentclass[autodetect-engine,dvi=dvipdfmx,ja=standard]{bxjsbook}
その他もろもろ非推奨
以上に述べたものの他、以下のオプションが非推奨となる。
(no)js(→disguise-js=<真偽値>)(no)zw(→use-zw=<真偽値>)(no)precisetext(→precise-text=<真偽値>)(no)simplejasetup(→simple-ja-setup=<真偽値>)textwidth-limit=<整数>(→textwidth-limit=<整数>zw)magstyle=mag/real/xreal(→magstyle=usemag/nomag/nomag*)jadriver=<名前>(→ja=<名前>)noscale(→scale=1)
-
2.0a版においても、非推奨の全てで警告が出るわけではないので注意。↩
-
「原ノ味フォント」自体（haranoajiパッケージ）とupdmapでのサポート（ptex-fontmapsの改版）は2020年2月にCTANに登録されているため、TeX Live 2019の最終版にも含まれている。↩
-
なお、updmapの和文フォント既定値のharanoajiについては「2004JIS字形」が指定されている。従来の「IPAexフォント」はAJ1非対応のフォントであり字形選択が無効であるため自動的にフォントの既定である2004JIS字形が選ばれていたが、「原ノ味フォント」はAJ1対応のフォントであり字形選択が有効（かつ必須）になる。そこで従来の2004JIS字形を保つために「2004JIS字形」を選択している。LuaTeX-jaやzxjatype（XeTeX）では字形選択は可能であるが必須ではない。LuaTeX-jaの和文フォントの既定では字形選択を行わず、結果的に「原ノ味フォント」の既定である2004JIS字形が選ばれる。BXjsclsのLuaLaTeX／XeLaTeX上の既定設定も同様である。要するに、旧版でも新版でも既定の和文フォントは2004JIS字形となる。↩
-
なお、LuaLaTeX上の動作の場合はLuaTeX-jaの新しい既定値は既に「原ノ味フォント」であるが、XeLaTeXと動作を合わせるために「原ノ味フォント」を明示的に設定している。従って、古いLuaTeX-jaと組み合わせた場合でも既定値は「原ノ味フォント」である。↩
-
実態はTeX言語のif-トークンである。なので、ユーザレベルでもifthenパッケージを介して
\ifthenelse{\boolean{draft}}...という形で一応利用できていた。↩ -
TeX Wikiの解説をみればわかるように、BXjsclsの多くの追加機能はstandardモードでのみサポートされる。↩
zxjaﾅﾝﾁｬﾗの現状について語ってみる(2)
（前回の続き）
新しいzxjafont（1.1版）の機能を語ってみる
従来の版（0.4版以前）の情報については以下を参照。
xeCJKでもzxjafontできる話
zxjafontのプリセットの指定対象は、例えばipaの場合は以下のようになる。
- zxjatypeを読み込んだ場合： 和文の
\rmfamilyが「IPA明朝」、和文の\sffamilyが「IPAゴシック」になる。（和文サポートモード） - それ以外：
\rmfamilyが「IPA明朝」、\sffamilyが「IPAゴシック」になる。
zxjatypeがない場合は日本語組版はサポートされないしそもそもフォントに「和文と欧文」の区別もない。しかしzxjafontはそういう状況で使うことも想定されていて、その場合は（区別のない）全体のフォントが設定対象となる。
ところがこれまでzxjafontは「zxjatypeが読まれずxeCJKだけ読み込まれている」状況は想定しておらず、この状況で無理に使うと「日本語のフォントが欧文だけに設定される」という奇妙な動作になっていた。「日本語組版をやりたいならzxjatypeを使っていて当然」であればそうで構わないのであるが、前回に述べたの通り、「日本語組版機能のためのzxjatype」という地位が非常に危ういものになっている。この辺りの事情を踏まえて考慮した結果、1.0版において、「xeCJKが読み込まれた場合も、zxjatype読込時と同様に和文サポートモードを適用する」という仕様変更を行うことにした。
zxjafontで原ノ味フォントできる話
既に前回のzxjatypeの例の中に登場しているが、「原ノ味フォント」を指定するプリセットオプションharanoajiが追加された。
※BXjsclsのクラスを用いたXeLaTeX文書でクラスオプションにjafont=haranoajiを指定した場合、zxjafontが読み込まれてプリセットharanoajiが適用される。
% XeLaTeX文書; UTF-8 \documentclass[xelatex,ja=standard,jafont=haranoaji, prefercjk,a4paper]{bxjsarticle} \begin{document} ①☀っ☁☂☀～っ？\par ❷☃っ☃☃☃～っ！\par \end{document}
これで、ptex-fontmaps、pxchfon、luatexja-preset、zxjafontの全ててharanoajiが使用可能になったことになる。
XeLaTeXでも3ウェイトが使える話
zxjafontパッケージの目的は「(u)pLaTeXのpxchfonパッケージやLuaLaTeXのluatexja-presetパッケージが提供するようなプリセット指定機能をXeLaTeXで実現すること」であるが、特に多ウェイトのプリセットについてはzxjafontは他のパッケージにはない制限があった。それは「明朝・ゴシック各々2ウェイトしか使えない」ということである。
例えば、LuaLaTeXでluatexja-presetパッケージをdeluxe付きで読み込んだ場合、明朝体で細字（通常より細い）を指定する\ltseriesとゴシック体で極太を指定する\ebseriesが使えるようになる。
※(u)pLaTeXでjapanese-otfをdeluxe付きで読み込んだ場合と同じ。
% LuaLaTeX文書; UTF-8 \documentclass[a4paper]{ltjsarticle} % 源ノフォントを多ウェイトで使う \usepackage[sourcehan,deluxe]{luatexja-preset} \begin{document} % 3ウェイトが使える ☃明朝体で{\ltseries 細字}や中字や\textbf{太字}。\par \sffamily ゴシックで中字や\textbf{太字}や{\ebseries 極太}。\par \end{document}
対して、旧来のzxjafontでは、多ウェイトのプリセットを指定した場合でも、\ltseriesや\ebseriesは提供されず、またそもそもプリセット自体が中字と太字の2ウェイトしか定義されていなかった。
源ノフォントで3ウェイトしてみる話
1.0版以降のzxjafontでは、luatexja-presetやjapanese-otfと同様に「明朝・ゴシック各々3ウェイト」が使えるようになる。すなわち、\ltseriesや\ebseriesの命令が提供され、プリセットの定義も3ウェイトになる。
% XeLaTeX文書; UTF-8 \documentclass[xelatex,ja=standard,jafont=sourcehan,prefercjk, a4paper]{bxjsarticle} \begin{document} ☃明朝体で{\ltseries 細字}や中字や\textbf{太字}。\par \sffamily ゴシックで中字や\textbf{太字}や{\ebseries 極太}。\par \end{document}
この「3ウェイト定義」を有効にするオプションはthreeweightであるが、このオプションは原則的に既定で有効になっているので指定は不要である。逆に、何らかの理由（例えば\ltseriesや\ebseriesの定義がトラブルを起こす、など）でthreeweightの機能を無効にしたい場合はnothreeweightというオプションを指定1すればよい。
% XeLaTeX文書; UTF-8 \documentclass[xelatex,ja=standard,jafont=sourcehan,prefercjk, nothreeweight,a4paper]{bxjsarticle} \begin{document} ☃明朝体で中字や\textbf{太字}。\par \sffamily ゴシックで中字や\textbf{太字}。\par \end{document}
源ノフォントだけど単ウェイトしてみる話
「源ノフォント」を使いたいが、でも「明朝・ゴシック各々1ウェイトしか使わず、かつ明朝の太字をゴシックにする」という「単ウェイトの和文フォント設定」を維持したい場合は、oneweightというオプション（これは昔から存在する）を指定すればよい。
\documentclass[xelatex,ja=standard,jafont=sourcehan,prefercjk, oneweight,a4paper]{bxjsarticle} %……あとは直前の例と同じ
出力結果をみて判るように、このoneweightを指定したときに明朝とゴシックで実際に使われるウェイトは、多ウェイトプリセットにおいて「中字」のウェイトに相当するものである2。
0.7版以降ではboldというオプションが利用できる。これを利用すると、oneweightと同じく「単ウェイトの設定」が維持されるが、そこで使われるゴシックのウェイトがプリセットの「太字」に相当するものになる。これはluatexja-presetやjapanese-otfのboldオプションと同様の機能である。
\documentclass[xelatex,ja=standard,jafont=sourcehan,prefercjk, bold,a4paper]{bxjsarticle} %……あとは直前の例と同じ
まとめ
多ウェイトのプリセットの制御のオプションをまとめると以下のようになる。
threeweight： 3ウェイトを使用。これが既定。nothreeweight： 2ウェイトを使用。oneweight： 単ウェイト用設定。bold： 単ウェイト用設定3で、ゴシックを太字にする。
ただしこれらのオプションの実際の仕様は少し複雑で以下のとおりである：
threeweight、oneweight、boldにはそれぞれ無効にするオプションnothreeweight、nooneweight、noboldが存在して、独立に有効無効を切り替えられる。- フォント設定に関して、3つのオプションの優先度は
bold＞oneweight＞threeweightとなる。 threeweightが有効の場合、\ltseriesと\ebseriesが定義される。これはboldやoneweightには影響されない。boldやoneweightは既定で無効。threeweightは既定で有効であるが、fontspecの版が古い（3ウェイトの設定がサポートされない）場合は無効になる。
その他もろもろ
- たとえzxjatypeやxeCJKが読み込まれていても無視して和文サポートモードへの移行を抑止するためのオプションを追加。
ignorejatype： zxjatype/xeCJKの読込を無視し、和文サポートモードを無効にする。noignorejatype：ignorejatypeの否定。
90jisとjis2004の両方を否定して既定状態に戻すオプションnojisshapeを追加。haranoaji以外の新設プリセットオプション：nopreset： 和文フォントのプリセット設定を行わない。- Mogaフォント系のプリセットを整理した（
mogaN-90を追加）。恐らく現在はMogaフォントの需要はないと思われるので、詳細は笑楽する。
- luatexja-preset互換のオプション別名を追加。
deluxe：nooneweightの別名nodeluxe：oneweightの別名jis90：90jisの別名2004jis：jis2004の別名match： 何もしないオプションnoembed：nopresetの別名。
- ptex-fontmapsとの互換のためのプリセット別名を追加。
kozuka：kozuka-proの別名morisawa：morisawa-proの別名hiragino：hiragino-proの別名
- 0.3版で非推奨となったプリセットを0.5版で廃止した。
kozuka4、kozuka6、kozuka6n、hiragino、ms-dx、ipa-dx、hiragino-dxが廃止。
-
BXjsclsクラスの
jafontオプションによりzxjafontが読み込まれている場合、zxjafontにオプションを指定するにはクラスオプション（グローバルオプション）として指定すればよい。↩ -
厳密にいうと、プリセットの種類によってはゴシックについて「
oneweight指定時専用のウェイト」が使われる。例えば、sourcehanプリセットではゴシックの中字は「Source Han Sans Regular」であるが、oneweight指定時のゴシックは「Source Han Sans Medium」であり、これは「Regular」よりも若干太い。↩ -
luatexja-presetと異なり、zxjafontの
boldはそれ自体が単ウェイト用設定を有効化する。↩
zxjaﾅﾝﾁｬﾗの現状について語ってみる(1)
つまり、zxjatypeとzxjafontの解説であるが、その前に一つ重要な話。
はじめに：zxjatypeは（ずっと昔から）壊れている
zxjatypeの本来の主要機能は「少なくともpLaTeXと同等の品質の日本語組版をXeLaTeX上で実現すること」だった。しかし、その主要機能については
もう何年も前から“壊れている”状態
にある。詳細については以下のツイッタァーのスレッドを参照されたい。
zxjatypeパッケージの目的は
— 某ZR（ざんねん🙃） (@zr_tex8r) 2019年8月9日
「xeCJKを基にして日本語の行組版規則を実現する」
ことだけど、その肝心要の機能については現状“壊れている”んだよな。それももう7年前（0.6版）から。#TeX #LaTeX #XeLaTeX
これが意味するところは、「日本語文書用のLaTeXについて、本来ならばXeLaTeXも（pLaTeX／upLaTeX／LuaLaTeXと同列の）“主要な”エンジンの地位を得ているべきであるが、残念ながら現状はそうなっていない」ということである。
もちろん、何か理由があってどうしてもXeLaTeXで日本語文書を作る必要があるのなら、その場合の最善策としてzxjatypeは十分に機能するはずであり、その意味で現状のzxjatypeにも存在意義はあるといえる。ただ、この状況は「pdfLaTeXのbxcjkjatypeパッケージ」と同じということになる。つまり、“日本語LaTeX”としてXeLaTeXはLuaLaTeXと同じ地位を得るべきところがpdfLaTeXと同じ地位に甘んじているというわけである。
zxjatype、または“XeLaTeXで日本語”をどうにかしてほしい件
ネットを見る限りでは「XeLaTeXを日本語LaTeXの主流の選択の一つにしたい」という要望は存在する。というわけでここでお願い。
だれか「XeLaTeXでまともに日本語するやつ」をつくってください。
実装の形については、zxjatypeの改良でも新しいパッケージの作製でもよく、またxeCJKを土台にするものでもしないものでも構わない。とにかく、pTeXの品質以上で基本的な日本語の行組版ができる実装があってほしいと思う。
新しいzxjatype（0.7版）の機能を語ってみる
従来の0.6版の機能については以下の記事が参考になる。
小書き仮名で禁則する話
現状のzxjatypeの既定の設定においては、小書き仮名は行頭禁則処理の対象にならない。
\documentclass[autodetect-engine,ja=standard,a4paper]{bxjsarticle} \begin{document} \parbox{21\zw}{% 寿限無寿限無五劫の擦り切れ海砂利水魚の水行末雲来末風来末 食う寝る処に住む処藪ら柑子の藪柑子 パイポパイポパイポのシューリンガンシューリンガンのグーリンダイ グーリンダイのポンポコピーのポンポコナーの長久命の長助 } \end{document}
例えばこのソースをuplatexでコンパイルすると以下の出力が得られるのに対して：
同じソースをxelatexでコンパイルすると以下のようになる：
なりゆきで改行すると小書きの「ュ」の前に改行位置がくることになるが、upLaTeXではここで（緩い1）禁則が適用されて前の「シ」が追い出される。ところがxelatexでは禁則がないため「ュ」の直前で実際に改行が起こる。
zxjatypeにkanakinsokuオプションを指定すると、小書き仮名に対して（完全な）禁則が適用される。したがって、先ほどのソースでこのオプションを追加すれば、小書きの「ュ」の前での行分割が起こらなくなる。
% グローバルで指定したkanakinsokuがzxjatypeに渡される \documentclass[autodetect-engine,ja=standard,kanakinsoku, a4paper]{bxjsarticle} \begin{document}
この場合、結果的にuplatexのときと同一の出力が得られる。
でも小書き仮名で禁則するとアレ
しかし、このkanakinsokuオプションには重大な副作用がある。小書き仮名に対する行頭禁則は、内部で「小書き仮名を閉じ括弧類として扱う」ことで実現している。このため、小書き仮名と約物が並んでいると「約物同士が隣接している」と見なされて空きの調節が行われてしまうのである。これは慣習的な日本語の行組版規則に反していて好ましくない。
\documentclass[autodetect-engine,ja=standard,kanakinsoku, a4paper]{bxjsarticle} \begin{document} ベジエ（Bézier）曲線\par ベジェ（Bézier）曲線\par \end{document}
この不具合を回避するには、小書き仮名と約物の間に空のボックスを挿入する必要がある。
ベジェ\mbox{}（Bézier）曲線\par
kanakinsokuにはこのような副作用があり、また小書き仮名の行頭禁則は一般的に必須のものとは考えられていないという事情があるため、既定で有効にはなっていない。
まとめ：“(no)kanakinsoku”オプション
adjustcharclassが有効である（既定値）場合に以下のオプションが有効になる（0.6b版以降）：kanakinsoku： 小書き仮名に対して（完全な）行頭禁則を適用する。nokanakinsoku（既定）：kanakinsokuの否定。小書き仮名を行頭禁則から外す。
adjustcharclassが無効の場合はxeCJKの既定設定がそのまま適用される。
※xeCJKの既定における小書き仮名の禁則の設定は、昔の版ではkanakinsoku相当であったが、2016年頃にnokanakinsoku相当のものに変わっている。
“(no)useinhibitglue”オプション
現状の\inhibitglueの実装は問題があるので、0.6b版以降では既定で無効になっている。これを有効にするにはuseinhibitglueオプションの指定が必要である。
useinhibitglue：\inhibitglueの実装を提供する。nouseinhibitglue：useinhibitglueの否定。この場合、\inhibitglueは何もしない命令になる。
和文で☃とかする話
先述の通り、zxjatypeではxeCJKの“文字クラス”の設定を多少変更している。しかし、「文字が和文(CJK)か欧文か」の区別に関してはxeCJKの既定の設定をそのまま踏襲している。それに従うと、(u)pLaTeXやLuaTeX-jaよりも「欧文扱い」される文字が増えることになる。
例えば、次のような「☃」や「♪」の記号を含んだ文書ソースがあったとする。
\documentclass[autodetect-engine,ja=standard,jafont=haranoaji, a4paper]{bxjsarticle} \begin{document} ☃っ☃☃☃っ☃っ☃～～♪ \end{document}
LuaTeX-jaの既定ではこれらの記号は和文扱いになるため、和文フォント（原ノ味明朝）で出力される。
ところがxeCJKの既定ではこれらの記号は欧文扱いになる。現在の欧文フォント（Latin Modern Roman）には「♪」の字形はあるが「☃」はないため、結果的に「☃」が出力されないという由々しき事態に陥ってしまう。
xeCJKの「和文扱いの範囲」に関するトラブルを軽減する目的で、0.7版でprefercjkというオプションが導入された。このオプションを指定すると、「和文扱い」になる文字の範囲がLuaTeX-jaの既定により近いものに変更される2。
% グローバルで指定したprefercjkがzxjatypeに渡される \documentclass[autodetect-engine,ja=standard,jafont=haranoaji, prefercjk,a4paper]{bxjsarticle} \begin{document} ☃っ☃☃☃っ☃っ☃～～♪ \end{document}
まとめ：“(no)prefercjk”オプション
0.7版以降で追加された。
prefercjk：「和文扱いの文字」の範囲をLuaTeX-jaのそれに近づける。noprefercjk（既定）：prefercjkの否定。xeCJKの既定に従う。
※このオプションは実験的で、仕様は将来変更される可能性がある。
その他もろもろ
- xeCJKの2.x版の使用を非推奨とした。2.x版のサポートは将来廃止される予定。
- ちなみに、xeCJKの3.0版がリリースされたのは2012年5月。
（つづけ）
2020年のパズル年賀状
今年の年賀状。
以前に述べたとおり、年賀状にはその年の数に関連した数学パズルを載せるのが通例である1。しかし去年はパズルを作っている時間が2時間しかなかったので2、割と普通の（マジで）虫食い算で済ませた。
肝心のパズル問題の部分の文字が小さくで読みづらいが、以下のように書かれている。
以下の条件に従って、乗算の虫食い算を解きなさい。
- ■には0または2が入る。
- □には0と2以外の数字が入る。
（問題の図）
一番上にあるのはチェロキー語での新年の挨拶。
-
ぱんどっくのマニュアルを読破するのに時間を取られている人が多いためか、年を追うごとに年賀状で数学パズルを見ることが少なくなっているようで感じる。↩
-
そのうち本腰を入れて数学パズルを作りたいですね……。↩
