(a place holder—not yet completed)
(Could someone please translate this page into English?) → TeX Wiki の英訳
CJK パッケージは FreeType プロジェクトのオリジナルの著者の一人で現メンテナーである Werner Lemberg 氏によって書かれた LaTeX 用のマクロパッケージです。 オリジナルの TeX に修正を加えずとも動作し、pdfLaTeX で CJK 文書を作成するために使えます。
TeX Live は CJK パッケージ, ipaex-type1, BXjscls & BXcjkjatype が最初からインストールされています.
ipaex-type1, BXjscls & BXcjkjatype を使用すると pdfLaTeX で日本語の文書が作成できます.
ipaex-type1 を参照.
BXjscls & BXcjkjatype を参照.
以下の様な文書を作成して UTF-8 で保存します.
\documentclass[pdflatex,ja=standard]{bxjsarticle} \begin{document}
吾輩は猫である。名前はまだ無い。
どこで生れたかとんと見当がつかぬ。 何でも薄暗いじめじめした所で ニャーニャー泣いていた事だけは記憶している。 吾輩はここで始めて人間というものを見た。
\end{document}
pdfLaTeX を実行します.
pdflatex neko.tex
! Package keyval Error: pdflatex undefined. のエラーが発生する場合は BXjscls を最新版にアップデートします.
KOMA-Script classes と組み合わせて使用する場合は以下のようにします.
\documentclass{scrartcl} \usepackage[whole]{bxcjkjatype} \begin{document}
吾輩は猫である。名前はまだ無い。
どこで生れたかとんと見当がつかぬ。 何でも薄暗いじめじめした所で ニャーニャー泣いていた事だけは記憶している。 吾輩はここで始めて人間というものを見た。
\end{document}
日本語を処理できる TeX としては、国内では日本語 (e-)pTeX が広く使われていますが、TeX コンパイラ・DVI ウェア共に独自拡張を施しています。 このため、dvipng のように (e-)pTeX に対応してないツールがあります。
ここでは、コンパイラ等には手を加えず、マクロで日中韓文字を処理する CJK パッケージを紹介します。 周辺ツールも含めてオリジナルの TeX 環境がそのまま使えます。 縦書や日本語の禁則処理等は苦手ですが、 UTF-8 等を用いて中国韓国文字も処理できます。 海外では、pdfLaTeX で英文中にほんの少し漢字を書きたい場合によく使われているようです。
CJK パッケージは inputenc パッケージなどと同じく、8-bit 目(最上位bit)の立った文字のカテゴリー コードを変更して、多バイト文字の LaTeX ソースを標準的な 8-bit 版の pdfLaTeX でコンパイル可能にするマクロ集です。 当然、8-bit目(最上位bit)の立った文字がマクロとして処理される前に多バイト文字として、コンパイラに解釈されてしまう拡張が施された pLaTeX では使用できません。
基本的な使い方は
\usepackage{CJK} ... \begin{CJK}{encoding}{family} ... \end{CJK}
です。 encoding には UTF-8, EUC-JP, Shift_JIS, GB2312, Big5, EUC-KR, x-EUC-TW (CNS 11643) などさまざまなものが使えます。 以下は代表的なものです。
名前 | ユーザーコード | TFM エンコーディング |
Big5 | Bg5 | c00 |
GB2312 | GB | c10 |
EUC-JP | JIS | c40 |
Shift_JIS | SJIS | c40 |
JIS X 0212 (EUC-JP) | JIS2 | c50 |
EUC-KR | KS | c60 |
UTF-8 | UTF8 | c70 |
ユーザーコードは LaTeX のソースコードの encoding に書き込む文字列、TFM エンコーディングは fd ファイルの作成に必要です。 この説明から見当がつくと思いますが、LaTeX のソースコードに様々なエンコーディングが混じっていても、問題なくコンパイルできます。 しかし、編集の手間を考えると、複数のエンコーディングを用いて原稿を用意する時は別ファイルにしておいて、\input するのが良いでしょう。 特に、Big5 と Shift_JIS は2バイト目に “\”, “{”, “}” と言った LaTeX にとって特別な意味を持つ文字が使われることがあるので、プリプロセッサーをかける必要があるため、別ファイルにするメリットが大きいです。
\begin{CJK}{JIS}{} \input{euc-jp-text1}% \CJKenc{Bg5}% \ifx\VTeXversion\undefined% \immediate\write18{bg5conv < big5-text.raw > big5-text.tex}% \fi\input{big5-text}% \input{euc-jp-text2} \end{CJK}
一方、family はフォントの指定です。 ここを空白にしておくと、デフォルトの song (宋體)が使われます。 デフォルトを変更するには \CJKfamily や \CJKencfamily を使います。 実際に TeX がアクセスするフォントは NFSS に従い "(TFM エンコーディング)(ファミリー名).fd" で指定します。 つまり、様々なエンコーディングに対して、ファミリーは共通に song であっても、UTF-8 の文書は c70song.fd で指定された cyberbXX.tfm が、EUC-JP の文書は c40song.fd で指定された jsso12XX.tfm が、等々のフォントが使われます。
CJK パッケージの配布には、様々な拡張とそのサンプルが同梱されています。 そのうち、最も重要と思われる CJKutf8 について説明します。
中国語と日本語(そして、いくらかは韓国語[한국어]も)は禁則対象の文字の前後を除きどこでも改行できると言う、他の言語にはなかなか見出しがたい、特徴的な組版規則を持っています。 CJK パッケージでは TeX 上にそのような規則を実現するための実装がなされているため、CJK 環境内でそれ以外の言語を使用すると望ましからぬ組版処理が行われてしまいます。 丁度、pTeX でも全角の英数字を使って英文を書いたのでは正しいハイフネーションが行われないのと同じ事です。 そこで CJK と他の言語を併用するには、他の言語の部分を CJK 環境の外部に書かなければなりません。 更に、TeX のハイフネーションやカーニング、リガチャーはフォントエンコーディングに依存しているため、正しいフォントエンコーディングが CJK 環境外部ではロードされるようにしなければなりません。 そのような問題を解決してくれるのが CJKutf8 パッケージです。 仕組みを説明するために、まず inputenc パッケージについて解説します。
LaTeX2e と LaTeX2.09 の大きな違いは NFSS2 の採用です。 それに伴い、使用するフォントエンコーディングはその他のフォントの属性とは独立にユーザーが指定するものとなりました。 同時に、ソースファイルの記述に使うエンコーディングもユーザーが指定するものとなりました。 その結果、LaTeX2e の作法に則った最小の TeX ソースは(実際には fontenc のオプション指定は babel 等の他のパッケージを用いて間接に行う方が便利でしょうけれども、)
\documentclass{...} \usepackage[...]{fontenc} \usepackage[...]{inputenc} \begin{document} ... \end{document}
となります。 過去のバージョンである LaTeX2.09 との互換性から、もし fontenc を指定しなければテキストでは OT1 が使用され、もし inputenc を指定しなければソースファイルのエンコーディングはフォントエンコーディングと同じものが使用されます。 もし、それが自分の用途に適うものであったとしても、これらのパッケージをロードしない事が LaTeX2e の作法に則ったソースの書き方とは言えないでしょう。
ところで、inputenc.sty が実際に行っている事は、8-bit目(最上位bit)の立った文字をアクティブにし、ソースコード中でこれらの文字を使用しようとするとエラーを発効するだけに過ぎません。 もし、8-bit目(最上位bit)の立った文字をソースコード中で使用したいのならば、アクティブにされた文字をマクロとして再定義して、適切なフォントエンコーディング中の適切な文字コードに対応させてやる必要があります。 inputenc に与えるオプションは、そう言った再定義の記載されたファイルです。 2004年2月9日以降の LaTeX2e では、inputenc パッケージは UTF8 オプションが使用可能です。
\usepackage[UTF8]{inputenc}
しかし、このようにプリアンブルに書いたからと言って、すべての UTF-8 でエンコードされた文字がソースコード中で使える訳ではありません。 実は inputenc パッケージの UTF8 オプションは、本文が始まるまでにプリアンブルでロードされたすべてのフォントエンコーディングを走査し、各エンコーディング XXX に対し、XXXenc.dfu を読み込み、そこで定義された UTF-8 文字の再定義のみを有効にするだけです。 それ以外の文字を使用しようとすると処理不可能のエラーがでます。
現在、標準的に配布されている dfu ファイルは
です。 utf8enc.dfu はこれらの内容を一覧にしたファイルです。 これらに対応するフォントエンコーディングで記述できる言語に関しては、ソースファイルに UTF-8 を使っても、それ以外のエンコーディングを使った時と全く同じにハイフネーション、カーニング、リガチャーは処理され、同じ仕上りにタイプセットされます。
何もパッケージを追加しない LaTeX 標準でのユニコードサポートに関する現在の状況をまとめると、
このパッケージは内部的には複雑な事をやっていますが、提供する機能は単純です。 要するに、裏で inputenc パッケージを読み込み、CJK 環境ではまず inputenc で処理を試み、処理できない文字が出て来たら CJK 環境として処理を試みる。 ただそれだけです。
\documentclass{article} \usepackage[T1]{CJKutf8} % フォントエンコーディングをオプションで指定しても良い。
\begin{document} \begin{CJK}{UTF8}{min} UTF-8で何か文章を書く。babel等でハイフネーションの言語を指定すれば、正しく組版される。 \end{CJK} \end{document}
まず、LaTeX が動作する環境が必要です。 その他に CTAN:languages/japanese/CJK/ にある配下のマクロファイル(cjk-4.x.x/という名前のディレクトリ。zipやtarballで圧縮されている場合もあり)と、更には TFM ファイル(フォントメトリック)が必要です。 CJK にデフォルトで付属するフォントの設定は dvips や pdflatex での使用も可能なようになっているので、dvipdfmx で使うには最適なものではありません。 ここではカスタムなフォント定義を行なう方法を説明します。
pTeX や Aleph のように独自の拡張を施していない TeX が使用する TFM には、ファイル一つにつき、一応、最大256の文字グリフに関する情報しか収納できません。 もちろん、これでは漢字などは扱えないので、CJK では本来一つのフォントを裏側では複数のサブフォントに分割して取り扱っています。 何やら恐ろしげですが、実際は TFM ファイルは TTF フォントがあれば ttf2tfm で簡単に作成できます。
ttf2tfm [TTF名] [TFM 名ステム]@[SFD 名]@
TTC ファイルならば、-f オプションでどのフェイスを使用するのか指定もできます。 ここで、[TFM 名ステム] とは、前節での cyberbXX.tfm ならば cyberb、jsso12XX.tfm ならば jsso12 のことです。 そして、[SFD 名] がサブフォントへの分割方法を決めるものです。 どの SFD を使うかは、TTF フォントの持つ CMap のエンコーディングとTeX のソースコードのエンコーディングで決まりますが、最近の TTF フォントならば、“U” で始まる [SFD 名] を使えば良いでしょう。 もし全角文字しか使わないのであれば、既存の TFM ファイルを名前を変えてコピーすることでもしのげます。 (以下のサンプルに同梱の TFM ファイルは事実そのようにして作ったもので、これを使ってアルファベットの類をタイプセットすると悲惨な結果を招きます。)
自分で作った TFM ファイルを使うには fd ファイルを書く必要もあります。 例えば、EUC-JP/Shift_JIS で書かれた原稿を処理するために foo をステムに持つ TFM ファイルを作って、TeX ファイルでは bar と言うファミリー名でユニコードの CMap を持った baz.ttf フォントのデザインを使いたいならば、
ttf2tfm baz foo@UJIS@
で、まず foo01.tfm–foo35.tfm を作ります。 それから c40bar.fd を作らなければなりませんが、その最低限の内容は
\DeclareFontFamily{C40}{bar}{} \DeclareFontShape{C40}{bar}{m}{n}{<-> CJK * foo}{}
です。 テキストエディタで作成してください。 こうしてできたファイルを LaTeX が見つけられるようにしてやれば、無事に LaTeX のコンパイルは通る筈です。
\documentclasss{article} \usepackage{CJK}
\begin{document} \begin{CJK}{JIS}{bar} ここにEUC-JPで日本語の文章を書きます。 \end{CJK} \begin{CJK}{SJIS}{bar} ここにShift_JISで日本語の文章を書きます。% しかし、もしかすると、このブロックだけ% プリプロセッサーを通さないと% \LaTeX のコンパイルが通らないかも知れません。 \end{CJK} \end{document}
Shift_JIS と Big5 の原稿を処理するにはプリプロセッサー sjisconv, bg5conv もインストールしなければなりません。
現在の pdflatex は CJK パッケージが使用できます. pdflatex 以外で CJK パッケージを使ってまともな PDF を作成するには dvipdfmx と VTeX (商用)の選択肢があります. ここでは dvipdfmx についてのみ扱います。
ここで、dvips や旧バージョンの pdflatex の生成する PDF がまともでないと言う意味は、これらの DVI ドライバーでは TFM の分割に従って、PDF が使用する実フォントも分割したフォント (Type 1, PK) にしなければならないからです。
設定する必要があるのは DVI ファイル内の TFM と PDF ファイル内のフォントとの対応だけです。
背景を説明しておくと、DVI ファイルには文字の形に関する情報は何も入っていません。 大きさと位置、そしてそれがどの TFM に由来するかの情報だけしか入っていません。 DVI ドライバーの仕事はその大きさと位置にフォントから取得した文字の形に関する情報を当てはめていくことにあります。 従って、TFM とフォントとの対応が必要になってくる訳です。 この対応が与えられていない場合、大抵の DVI ドライバーはビットマップフォントを生成して、それを利用しようとします。 現在の pTeX の場合、ここでビットマップフォントの生成に失敗してエラーで止まってしまうので、誰でもインストールの失敗に気がつきます。 ところが CJK パッケージをフルインストールしていると、デフォルトのフォントに対してはビットマップフォントの生成に成功してしまうため、インストールの失敗に気がつかずに使い続けてしまうケースが多いようです。 以下のサンプルではいずれも新たなフォント (TFM) を定義して使っていますので、実フォントの対応についても方法を例示しています。
dvipdfmx で TFM と PDF ファイル内のフォントとの対応を指定するファイル (map file) は多数ありますが、その大部分は dvipdfm と共有なので、dvipdfm でも理解できる 8-bit フォントしか扱えません。 そこで、この対応は dvipdfmx 専用のマップファイルである kanjix.map に書きます。(Details will be added later.)
dvipdfmx は以下のフォントを「知って」います。
言語 | 文字集合 | フォント名 |
---|---|---|
日本語 | Adobe-Japan1 | Ryumin-Light |
GothicBBB-Medium | ||
HeiseiMin-W3 | ||
HeiseiKakuGo-W5 | ||
Adobe-Japan1-2 | HeiseiMin-W3-Acro | |
HeiseiKakuGo-W5-Acro | ||
Adobe-Japan1-4 | KozMinPro-Regular-Acro | |
KozGoPro-Medium-Acro | ||
Adobe-Japan1-6 | KozMinProVI-Regular | |
簡体中文 (簡化字中文) | Adobe-GB1 | STSong-Light |
Adobe-GB1-2 | STSong-Light-Acro | |
Adobe-GB1-4 | AdobeSongStd-Light-Acro | |
繁體中文 (正體中文) | Adobe-CNS1 | MSung-Light |
MHei-Medium | ||
Adobe-CNS1-0 | MSung-Light-Acro | |
MHei-Medium-Acro | ||
Adobe-CNS1-4 | AdobeMingStd-Light-Acro | |
韓国語 (한국어) | Adobe-Korea1 | HYSMyeongJo-Medium |
HYGoThic-Medium | ||
Adobe-Korea1-0 | HYSMyeongJo-Medium-Acro | |
HYGoThic-Medium-Acro | ||
Adobe-Korea1-2 | AdobeMyungjoStd-Medium-Acro |
そこで、これらのフォント名を kanjix.map のエントリー
[TFM 名ステム]@[SFD 名]@ [CMap 名] [フォントファイル名]
で指定すると、それらのフォントが dvipdfmx の検索パスに存在しなくても、フォントが埋め込まれていない PDF ファイルができあがります。 ただし、[CMap 名] は SFD を適用した結果のエンコーディングから上の表の文字集合に記された CID の並び順への対応表です。 [SFD 名] には普通 TFM を作成する時に ttf2tfm の引数として指定したのと同じものを使います。 しかし、次のようなこともできます。
jsso12@UJIS@ UniJIS-UCS2-H HeiseiMin-W3-Acro
これは単純に jsso12XX.tfm のエンコーディングを集めてユニコードに復元し、Adobe-Japan1 のグリフに標準的に対応させます。
jsso12@SJIS@ RKSJ-H HeiseiMin-W3-Acro
これも単純ですが、jsso12XX.tfm のエンコーディングを集めて Shift_JIS に復元し、Adobe-Japan1 のグリフに標準的に対応させます。
jsso12@SJIS@ 90ms-RKSJ-H HeiseiMin-W3-Acro
これも Shift_JIS を経由しますが、 Windows-31J (Microsoft Windows 標準日本語文字セット)の対応を使用します。 一部、上とは微妙に違う字形が使われます。
jsso12@SJIS@ 78-RKSJ-H HeiseiMin-W3-Acro
これは表外漢字の新字体、旧字体が入れ替わったりしている JIS C 6226-1978 (JIS X 0208:1978) での例示字形が使われます。
フォントを埋め込んでいない PDF では表示、印刷環境により、異なる代替フォントが 使われることがあります。
上と殆ど同じですが、[フォントファイル名] には dvipdfmx の検索パスに存在するフォントを指定しなければなりません。
デフォルトではフォントが埋め込まれますが、[フォントファイル名] の先頭に “!” を付けると、埋め込まれなくなります。 また、[フォントファイル名] の後に “,Bold”、“,Italic”、または “,BoldItalic” を付けた場合もフォントは埋め込まれません。 これらは、フォントを PDF ヴューアーが機械的に太らせたり、ひしゃげさせたりして、表示することを指示します。
TTF フォントでは内部的なグリフの並び順に何の決まりもありません。 従って、フォントファイル内のグリフにアクセスするにはフォントファイルが持つ CMap テーブルが使われますが、[CMap 名]に指定された CMap ファイルの文字集合が Adobe の標準文字集合の時は、標準的なユニコードからの対応により、TrueType フォントを CID フォントとして、埋め込む事ができます。 但し、ユニコードの割り振られていないグリフなどは元々 TTF フォントには存在しない場合が多いですし、たとえ存在してもアクセスできません。 [CMap 名] に指定された CMap ファイルの文字集合が Adobe の標準文字集合と異なっていても、TTF フォント名の後ろに “/AJ14” 等と付けてやれば、Adobe-Japan1 の supplement 4 を偽装できます。 TrueType フォントを埋め込まずに使用する場合、原則として、この方法を使って下さい。
CMap テーブルを使用して TTF フォントにアクセスするには、kanjix.map のエントリー
[TFM 名ステム]@[SFD 名]@ unicode [フォントファイル名] [オプション]
を使います。ここで SFD は TFM のエンコーディングをユニコードに対応させる、“U” で始まるものでなければなりません。
-w オプションTrueType フォントを縦書きフォントとして使う時に使います。
-w 0横書き(デフォルト)
-w 1縦書き
-p オプションUnicode の BMP (Basic Multilingual Plane) に入っていないコードポイントを持つ文字にアクセスするために使用します。
-p 0BMP の文字にアクセスします(デフォルト)。つまり、0x0000–0xFFFF のコードポイントに同じコードポイントを持つ文字を対応させます。
-p 1SMP (Supplementary Multilingual Plane) の文字にアクセスします。 TeX で必要なのは、主に、古代文字です。 0x0000–0xFFFF のコードポイントに 0x10000 平行移動した 0x10000–0x1FFFF のコードポイントを持つ文字を対応させます。
-p 2SIP (Supplementary Ideographic Plane) の文字にアクセスします。 これは BMP に収まり切れなかった漢字です。 0x0000–0xFFFF のコードポイントに 0x20000 平行移動した 0x20000–0x2FFFF のコードポイントを持つ文字を対応させます。
何等かの事情で TTF フォントのグリフに、CMap を経由せず、その並び順で直接アクセスするには、文字集合として Adobe-Identity を持つ CMap ファイルを使用します。 しかし、この CMap ファイルの名前は “Identity-H” または “Identity-V” であってはいけません。
以下のサンプルをコンパイルするには CTAN:languages/japanese/CJK/ 配下のファイルが必要です。 サンプルはインストールして使用することも可能なようにアーカイヴされていますが、インストールせずに試してみるには空の作業用ディレクトリ(フォルダー)を用意し、すべてのファイルをそこにコピーします。 更にサンプル内の dvipdfm/config/cid-x.map-add.* をインストールせずに試してみるには kanjix.map に 改名、インストールして使用する場合はその内容をシステムの kanjix.map に追加します。
他にどのようなサンプルを作れば分かり易いか、アイデアをお寄せ下さい。 もちろん、新たなサンプルの提供と、(全体の)文章の修正も歓迎します。