長くなってきたので、新たなトピックをたてました。
hiraginoN のオプション名を採用して、さきほど 3/2 版として公開しました。
が、実は pdvips, pxdvi を収録した段階で公開すべきだったと反省しています。というのも、hiraginoN 対応での変化が意外に大きくて、中途半端な仕上がりになっているからです。ということで、不都合・不具合がきっと山盛りです。;-(
まずは、JISX0213-2004-H/V が未収録ですので、http://homepage3.nifty.com/ttk/comp/tex/jishojo_004.tar.gz から展開して texmf/fonts/cmap/ 以下に配置して下さい。
また、OTF の開発版への入れ替えも、作業量が多いので今回は見送りました。
そして updmap-sys --setoption kanjiEmbed hiraginoN を実行した後、pdvips, pxdvi がどんな動きをするのか未検証です。
特に pxdvi は CMap を内蔵（ハードコーディング）してますので、未知の CMap には対応できません。運が良くて文字化け、最悪は起動しなくなっているはずです。
pdvips のほうは、動きはするでしょうけども、できた PS が見られるかどうかは、ghostscript の設定次第でしょうね。またこういう PS を流通させてよいかどうかは、別途考える必要があると思います。
こういう微妙な話を、pxdvips/pxdvi 登場直後に持ち出すのは、やはり失敗でした。(^^;) ですので、安定するまで hiraginoN + pdvips/pxdvi の組み合わせた話はサポートしません。(^^;;;)
フォントへのシンボリックリンクは真面目に張ったつもりです。/System の下かどうかは、どちらにあってもちゃんと見ているはずです。Pro, ProN 共存させてます。
個人的には、このシンボリックリンクと、pxdvips/pxdvi がちゃんと動いていることの確認ができれば、このバージョンの役目は果たせたことになると思っています。
遅ればせながら、私も色々と考えてみました。特に結論はありません。 ;-)
前提：（間違ってたら指摘をお願いします）
- Adobe は 83 字形と 90 字形を区別しない。90／97／2000 は「同じ」なので、 結局区別されるのは 78／83～2000／2004 の 3 つ。
- 2004 字形に完全対応するには AJ1-6 が必要。
- 字形集合：Pro = AJ1-4; ProN = AJ1-4 対応 + 2004 字形; Pr6 = Pr6N = AJ1-6。
- 既定 cmap：Pro と Pr6 は 2000 字形互換; ProN と Pr6N は 2004 字形互換。
そこから予想される結果：
- Pro フォント + 2000 字形 CMap → OK（2000 字形）
- Pro フォント + 2004 字形 CMap → NG（一部の字が欠ける）
- ProN/Pr6/Pr6N フォント + 2000 字形 CMap → OK（2000 字形）
- ProN/Pr6/Pr6N フォント + 2004 字形 CMap → OK（2004 字形）
- フォント非埋込 + 2000 字形 CMap → ほぼ確実に OK（2000 字形）
※ 次項と同じで結局は表示使用のフォントに依存、0213 の文字は AJ1-4 が必要。 - フォント非埋込 + 2004 字形 CMap → 表示に使われるフォントが AJ1-6 対応である必要あり（2004 字形）
- 非 CID フォント + 2000 字形 CMap (dvipdfmx) → フォント対応の文字の範囲で OK（フォント依存）
※ BMP 外の文字は非対応 - 非 CID フォント + 2004 字形 CMap (dvipdfmx) → フォント対応の文字の範囲で OK??（フォント依存）
6 のような PDF は一般に公開するのには向かないかも知れません。個人的に興味があるのは、8 で問題が起こらないか、つまり ToUnicode の結果が 7 と異なって日本語フォントで余り一般的でない文字になったりしないか（特に 0208 文字の範囲で）ということです。まあ、非 CID の場合は 2004 字形 CMap にする意味が全くないのは明らかなのですが。
P.S. 私のメインマシンの Windows は XP（ちなみに 32 ビット）なので MS フォントは未だに 2000 字形だったりします。ただ常用しているのは 2004 字形の IPA フォントなのですが。
作った本人がほとんど忘れかけていますが、 jishojo_004.tar.gz に含まれる JISX0213-2004-H/V は何かのCMapを参考にしつつ私が作ったものだと思います。 ほとんど文字コード表なので、著作権法的には第十条第一項第九号の「プログラムの著作物」ではなく、 第十条第三項第二号の「規約」に該当するのでは、という思いもあります。 しかし、最近AdobeからOpen Sourceを明示したCMapが出ているので、 それを基に作り直した方が著作権がクリアーでよいかもしれません。 とはいえ、ヘッダー部分を書き直すだけとほとんど結果は変わらないと思います。 また、 JISX0213-2004-H/V の注意点は、 ①JIS X 0213系のエンコーディングを前提としていること、 ②第4水準が、95区～120区に存在する「拡張JIS」になっていること、が挙げられます。 ①は、JIS第1, 2水準のみ使用している分には問題とはならないと思いますが、 第3，4水準は 『Shift_JISX0213, Shift_JIS-2004 など 一応JISの規格票に「参考」として載っているが普及しているとは言いがたい文字コード』 を前提としています。 CP932のIBM拡張、NEC拡張のつもりで使うと文字化けします。 ②は、独自規格なので、ますます広くいきわたることは望ましくないです。 したがって、そういう危うい点までコントロールできる人以外に勧めるのは、ためらわれます。 あくまでJIS第1, 2水準の範囲で、JIS2004字形を出したいだけなのなら、 第3, 4水準を削除した別のCMapを作った方が、 無理解ゆえの事故が発生するのを避けるためにはよいと思います。 もうW32TeXには JISX0213-2004-H/V が入ったのですね。さてどうしたものか…。
まだ考えがまとまっていないですが、今思っていることを書き捨てておきます。
- とりあえず「このファイルは pTeX と dvipdfmx を連携させるために CMap のように使えるものであり、CMap ではない」という建前を叫んでおくのも一つの手段かも。実際、/XUID がないと正しい CMap ではないはずだし、正しい /XUID を書こうとすると Adobe へのベンダ登録が必要でとても面倒。
- そう考えると、0213 の第 4 水準を「似非 JIS エンコーディング」の 7Fxx 以降の符号位置に置くことも正当化できる。なぜなら、pTeX で Shift_JISX0213 を扱った場合に必然的にそうなるから。勿論、Shift_JISX0213 は普及している（または、将来そうなる）とはいえないが。
- 基本的に、「2004 字形」を考えるのであれば、文字集合も 0208 でなく 0213 を考えるべきだと思う。2004 字形の利点は、出版業界の支持を得ている「表外漢字字体表」に従う字形であると考えるが、この字体に従う JIS 文字の一部で第 3 水準に置かれるものがあるらしい（多分、既存の符号位置の文字に包摂できずに新たに追加されたものだと思う）。従って、「0213 の第 2 水準まで」という字体の集合を考えるのは不適切に思える。ただし、現状では、0213 の文字集合は Unicode に移した形でのみ用いられているし、また ptexenc の UTF-8 動作は 0208 の符号位置に対応する文字だけ特別扱いするので、その意味では「0213 の第 2 水準」までの（似非）CMap は意味がある。
- ちなみに、「2004 字形をもった 0208」というのは可能（0208 に適合する）と思う。しかし、それを 0221 に定めるマッピングで移したものは Unicode の包摂規準に適合しないかも知れない。いずれにしても、現実に行われているのはそれではない。
- ところで、JISX0213-2004-H/V の CMap は 0212 の文字も持っていて、その符号位置は「0213/0212 用のパッチを当てた pTeX」の動作に対応していたと記憶している。少なくとも、その部分は、当該パッチと無関係なシステム上では存在すべきではないと思う。
- あと、CMap の命名慣習は「〈文字集合〉-〈符号化方式〉-〈書字方向〉」だから「JISX0213-2004-H/V」の名前は変だと思う。
pLaTeX で 2004 字体が簡単に扱えることは非常に重要だと思います。私だったら、多分完全な 0213 を持ったものを「似非 CMap」として用意すると思います。
P.S: ところで、JISX0213-2004-H で、「0208 の符号位置が非全角幅のグリフにマップされる」ということは起こりませんか？ 念のため聞いておきます。
> この字体(＝印刷標準字体)に従う JIS 文字の一部で第 3 水準に置かれるものがあるらしい
ええと、確か
JIS X 0213:2000で包摂分離したJIS X 0208:1997の“過去の規格との互換性を維持するための包摂基準”の“(B)に示す字体の漢字” (啞焰鷗嚙俠軀鹼麴屢繡蔣醬...) と
JIS X 0213:2004で包摂分離した“表外漢字 UCS互換” (俱剝吞噓姸屛幷瘦繫と「口偏に七」)
が第3水準にありますね。意外に沢山あります。
あくまでこだわりが印刷標準字体にあるのならば、JIS X 0208の範囲では不可能で、少なくとも第3水準までの対応が必要、ということは確かですね。
すると、pTeX (SJIS) でShift_JIS-2004などを使うか、あるいはUTF-8 + upTeX が素直な解
だと言えるのではないでしょうか?
ええと、確か
JIS X 0213:2000で包摂分離したJIS X 0208:1997の“過去の規格との互換性を維持するための包摂基準”の“(B)に示す字体の漢字” (啞焰鷗嚙俠軀鹼麴屢繡蔣醬...) と
JIS X 0213:2004で包摂分離した“表外漢字 UCS互換” (俱剝吞噓姸屛幷瘦繫と「口偏に七」)
が第3水準にありますね。意外に沢山あります。
あくまでこだわりが印刷標準字体にあるのならば、JIS X 0208の範囲では不可能で、少なくとも第3水準までの対応が必要、ということは確かですね。
すると、pTeX (SJIS) でShift_JIS-2004などを使うか、あるいはUTF-8 + upTeX が素直な解
だと言えるのではないでしょうか?
“過去の規格との互換性を維持するための包摂基準”がらみで裏に隠された(B)字体だけが目当てで、dvips + distiller などを使うなら
pTeXの文字をJIS78のつもりで使い、dvipsをSJISで使い、Adobe製のCMap Ext-RKSJ-H を使う [QA:50066] という手もあります。
これなら第三水準を使う必要もありませんし、フォントを切り替えれば(A)字体との共存も可能です。
しかし、Ext-RKSJ-H を dvipdfmx で使うことは出来たんでしたっけ??
まあ、いずれにせよ、裏技的ですね…。
pTeXの文字をJIS78のつもりで使い、dvipsをSJISで使い、Adobe製のCMap Ext-RKSJ-H を使う [QA:50066] という手もあります。
これなら第三水準を使う必要もありませんし、フォントを切り替えれば(A)字体との共存も可能です。
しかし、Ext-RKSJ-H を dvipdfmx で使うことは出来たんでしたっけ??
まあ、いずれにせよ、裏技的ですね…。
RKSJ（sjis）の CMap を dvipdfmx で用いようとすると、vf で TeX 側の符号値を sjis に変換する必要が生じます。H/V（〈83JIS〉-〈ISO-2022-JP〉）と通用できるのは 78-H/V（〈78JIS〉-〈ISO-2022-JP〉）または Ext-H/V （〈NEC文字集合〉-〈ISO-2022-JP〉）となるでしょう。
\documentclass[a4paper]{jsarticle}
% otfは既定の明朝体を hmc/m に切り替えるが、元の明朝体である mc/h
% を 78 字体として使用する
\AtBeginDvi{\special{pdf:mapline rml 78-H Ryumin-Light}}
\newcommand\OldJis[1]{{\kanjifamily{mc}\kanjiseries{m}\selectfont#1}}
\usepackage[bold]{otf}
\begin{document}
\begin{itemize}
\item \OldJis{東京都葛飾区}% 78 字形
\item 奈良県葛城市 % 83(2000)字形
\end{itemize}
\end{document}