Mac の新OSである OS X 10.11 El Capitan がリリースされて，1週間が経ちました。
El Capitan では，色々と仕様が大きく変わっており，TeX 環境は大きな影響を受けました。 TeX の開発者メーリングリストでは，El Capitan リリース前後のこの数週間，対応に追われていました。
「どのような問題があるのか」を洗い出し，その一つ一つに対して対応を考える必要があって，一筋縄ではゆきませんでしたが，ようやく全ての問題の解決に向けて道筋がつく状況まで至れました。解決に至るまでには TeX エンジン側の改修も必要になるなど，かなり大掛かりな作業になりましたが，北川さん，前田さん，Norbertさんをはじめ，TeX界の開発者の方々の多大なご尽力の結果，あらゆる問題を数日間で迅速に解決することができました。
TeX側の対応の速報は，id:acetaminophen さんの一連の記事にまとめられています。
- El Capitan がもうすぐ - アセトアミノフェンの気ままな日常
- El Capitan 出ました - アセトアミノフェンの気ままな日常
- TeX で OpenType Collection フォントを扱ってみると（その1） - アセトアミノフェンの気ままな日常
- TeX で OpenType Collection フォントを扱ってみると（その2） - アセトアミノフェンの気ままな日常
- TeX で OpenType Collection フォントを扱ってみると（その3） - アセトアミノフェンの気ままな日常
- LuaTeX で一部の TTC/OTC フォントが扱えない？ - アセトアミノフェンの気ままな日常
- LuaTeX でなぜか使えない TTC/OTC フォントを無理やり埋め込む実験 - アセトアミノフェンの気ままな日常
ここでは，一通り解決の目処が立った現段階で，これまでの経緯を振り返り，改めて
- どのような問題があったのか
- 原因は何だったのか
- TeX 側はどう対応したのか
- ユーザはどう対処すればよいのか
をまとめておこうと思います。
手っ取り早く対処法が知りたい人は……
本記事の簡単な要約をご覧ください。
目次
問題1. /usr 書き込み禁止問題
問題の詳細
El Capitan では，セキュリティ強化のため，System Integrity Protection (SIP) または Rootless と呼ばれる新機能が導入されました。これは，sudo を使っても /usr や /System, /bin, /sbin 以下に書き込みができなくなるというものです。（ただし，/usr/local は例外的に書き込みが許可されます。）
Mac 環境の TeX ユーザに占めるシェアが高い TeX ディストリビューションである MacTeX では，従来，TeX 環境の各種実行バイナリへのシンボリックリンクを /usr/texbin を配置していました。そして，MacTeX にバンドルされている TeXShop などの GUI アプリケーションは，そのディレクトリを参照するよう自動で設定がなされていました。
この状態で El Capitan へアップグレードすると，/usr/texbin は /Previous System/usr/texbin へ強制移転されてしまい，GUI アプリケーションが機能しなくなってしまいます。
TeX 側の対応
今年6月の WWDC 2015 で El Capitan が発表され，直ちに開発者向けに El Capitan のβ版が発表されました。その際にこの問題が明るみに出て，直後に MacTeX は修正を行いました。現在の MacTeX 2015 のインストーラでは，TeX 環境の各種実行バイナリへのシンボリックリンクは，/usr/texbin ではなく /Library/TeX/texbin に作成されるようになっています。
ユーザの行うべき対処
最新版の MacTeX を改めてインストールするのが最も簡単な対応でしょう。GUIアプリケーションの設定については，/Library/TeX/texbin を参照するよう設定変更しましょう。
ひとこと
Rootless (SIP) によって /usr が書き込み不可になった問題は，Homebrew ユーザの一部にも影響を及ぼしたため，ネット上では大きな話題になりました。
TeX についても，「Rootless のせいで TeX が使えなくなる！」という言説が広く出回りました。
しかし，Rootless は，今回の El Capitan 騒動においては，比較的些細な問題でした。 影響を受けるのは古い MacTeX / BasicTeX を使っているユーザだけですし，内容的にはシンボリックリンクの張り直し，および GUI アプリケーションの設定変更だけで済む程度の問題だからです。
これより遙かに深刻なのは，以下の和文フォントにまつわる諸問題でした。
問題2. 和文フォントへのシンボリックリンク張り替え問題
問題の詳細
10.10 Yosemite までは，OS X 付属のヒラギノフォントは次のような構成でした。
/System/Library/Fonts/ヒラギノ明朝 ProN W3.otf /System/Library/Fonts/ヒラギノ明朝 ProN W6.otf /System/Library/Fonts/ヒラギノ角ゴ ProN W3.otf /System/Library/Fonts/ヒラギノ角ゴ ProN W6.otf /Library/Fonts/ヒラギノ明朝 Pro W3.otf /Library/Fonts/ヒラギノ明朝 Pro W6.otf /Library/Fonts/ヒラギノ角ゴ Pro W3.otf /Library/Fonts/ヒラギノ角ゴ Pro W6.otf /Library/Fonts/ヒラギノ角ゴ Std W8.otf /Library/Fonts/ヒラギノ角ゴ StdN W8.otf /Library/Fonts/ヒラギノ丸ゴ Pro W4.otf /Library/Fonts/ヒラギノ丸ゴ ProN W4.otf
10.11 El Capitan では，和文フォントが大幅に増補改訂されました。ヒラギノ角ゴシックのウエイトは，従来の W3, W6, W8 の3段階から，W0 〜 W9 の10段階へ大幅に増補されました。
El Capitan のヒラギノフォントは次のような構成になっています。
/System/Library/Fonts/ヒラギノ明朝 ProN W3.ttc /System/Library/Fonts/ヒラギノ明朝 ProN W6.ttc /System/Library/Fonts/ヒラギノ角ゴシック W0.ttc /System/Library/Fonts/ヒラギノ角ゴシック W1.ttc /System/Library/Fonts/ヒラギノ角ゴシック W2.ttc /System/Library/Fonts/ヒラギノ角ゴシック W3.ttc /System/Library/Fonts/ヒラギノ角ゴシック W4.ttc /System/Library/Fonts/ヒラギノ角ゴシック W5.ttc /System/Library/Fonts/ヒラギノ角ゴシック W6.ttc /System/Library/Fonts/ヒラギノ角ゴシック W7.ttc /System/Library/Fonts/ヒラギノ角ゴシック W8.ttc /System/Library/Fonts/ヒラギノ角ゴシック W9.ttc /Library/Fonts/ヒラギノ丸ゴ ProN W4.ttc
和文フォントが大幅に増補されたことは喜ばしいことなのですが，問題は，フォントのパスや形式が大きく変更されているという点です。 同一書体・同一ウエイトのものは ttc 形式にまとめられています。ttc 形式というと，通常は TrueType Collection を指しますが，El Capitan の和文フォントの .ttc の実態は，TrueType ではなく OpenType フォントを束ねた OpenType Collection (OTC) という形式です。 OTC は複数の OpenType フォントを一つに束ねた形式のフォントで，最近登場し始めた新しいフォント形式です。昨年の Source Han Sans（源ノ角ゴシック）のリリースにより，OTC 形式のフォントが広く一般ユーザの手に渡るようになりました。
OpenType Collection 形式のフォントファイルは，.otc という拡張子を用いた方が分かりやすいのですが，.otc という拡張子では Microsoft Office など一部のアプリケーションがフォントファイルとして認識しないため，利便性を重んじて .ttc という拡張子を用いているものと思われます。実際，OpenType Collection に対しても拡張子 .otc の代わりに .ttc を用いてよいという記述 (Microsoft, Adobe) があります。
さて，従来，日本語 TeX ユーザは，TeX ディストリビューションをインストールした後，TEXMFLOCAL 内で次のようにシンボリックリンクを張ることで，TeX でヒラギノフォントを利用できるようにしていました。
HiraMinPro-W3.otf -> /Library/Fonts/ヒラギノ明朝 Pro W3.otf HiraMinProN-W3.otf -> /System/Library/Fonts/ヒラギノ明朝 ProN W3.otf HiraMinPro-W6.otf -> /Library/Fonts/ヒラギノ明朝 Pro W6.otf HiraMinProN-W6.otf -> /System/Library/Fonts/ヒラギノ明朝 ProN W6.otf HiraKakuPro-W3.otf -> /Library/Fonts/ヒラギノ角ゴ Pro W3.otf HiraKakuProN-W3.otf -> /System/Library/Fonts/ヒラギノ角ゴ ProN W3.otf HiraKakuPro-W6.otf -> /Library/Fonts/ヒラギノ角ゴ Pro W6.otf HiraKakuProN-W6.otf -> /System/Library/Fonts/ヒラギノ角ゴ ProN W6.otf HiraKakuStd-W8.otf -> /Library/Fonts/ヒラギノ角ゴ Std W8.otf HiraKakuStdN-W8.otf -> /Library/Fonts/ヒラギノ角ゴ StdN W8.otf HiraMaruPro-W4.otf -> /Library/Fonts/ヒラギノ丸ゴ Pro W4.otf HiraMaruProN-W4.otf -> /Library/Fonts/ヒラギノ丸ゴ ProN W4.otf
しかし，El Capitan では，次のようにシンボリックリンクを張り直さなければなりません。
HiraginoSerif-W3.ttc -> /System/Library/Fonts/ヒラギノ明朝 ProN W3.ttc HiraginoSerif-W6.ttc -> /System/Library/Fonts/ヒラギノ明朝 ProN W6.ttc HiraginoSans-W0.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W0.ttc HiraginoSans-W1.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W1.ttc HiraginoSans-W2.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W2.ttc HiraginoSans-W3.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W3.ttc HiraginoSans-W4.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W4.ttc HiraginoSans-W5.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W5.ttc HiraginoSans-W6.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W6.ttc HiraginoSans-W7.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W7.ttc HiraginoSans-W8.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W8.ttc HiraginoSans-W9.ttc -> /System/Library/Fonts/ヒラギノ角ゴシック W9.ttc HiraginoSansR-W4.ttc -> /Library/Fonts/ヒラギノ丸ゴ ProN W4.ttc
TeX 側の対応
このシンボリックリンク作成作業を全自動で行うために，Norbert さんの cjk-gs-integrate に，これらのシンボリックリンクを自動作成する機能を付け加えて頂きました。
現在では CTAN および TeX Live に収録されていますので，tlmgr でアップデートすれば最新版の cjk-gs-integrate がインストールされます。
ユーザの行うべき対処
詳細は TeX Wiki にあるとおり， 最新版の cjk-gs-integrate をインストールした上で，
$ cd /usr/local/texlive/2015/texmf-dist/scripts/cjk-gs-integrate $ sudo perl cjk-gs-integrate.pl --link-texmf --force $ sudo mktexlsr
などとして，シンボリックリンクの張り直しを行ってください。（上記パスは MacTeX 2015 の場合のインストールパスの例です。実際には各自の TEXMFDIST のパスを指定してください。）
問題3. dvipdfmx の和文フォントマップ問題
問題の詳細
さて，シンボリックリンクを張り直しただけでは，新ヒラギノフォントが使えるようにはなりません。
HiraMinProN-W3.otf と HiraginoSerif-W3.ttc のように，シンボリックリンクのファイル名自体が異なっているからです。
また，ファイル名だけの問題ではありません。 新ヒラギノフォントでは，同一ウエイトの複数のヒラギノフォントが ttc (otc) で一つに束ねられてしまっているため，「ttc の何番のフォントを使うのか」というのを dvipdfmx に正しく伝えなければならないからです。
TeX 側の対応
そのためには，jfontmaps に新しいフォントマップのプロファイルを付け加える必要がありました。
事前に準備は進めていたのですが，和文フォントの束ね方については Apple も実験を重ねていたようで，El Capitan の Public Beta 版から製品版に変わったときに，和文フォントの構成 (otf と ttc の構成，ttc 内でのインデックス）がまた大幅に変更されるというサプライズがありました。
製品版 El Capitan での和文フォント構成の詳細は，この表にまとめておきました。
製品版でのこの仕様変更に伴い，TeX 側でも急遽再対応が必要になりました。jfontmaps に記載されているフォントマッピングにおける ttc のインデックス指定を刷新する必要が生じたのです。
El Capitan がリリースされてから TeX Live の jfontmaps がそれに対応するまで数日のブランクがあったのは，そういう理由によるものでした。
現在では製品版 El Capitan に対応した最新の jfontmaps が CTAN および TeX Live に収録されています。
tlmgr でアップデートすれば最新版の jfontmaps がインストールされます。
これには，hiragino-elcapitan および hiragino-elcapitan-pron という El Capitan 用の新しい設定プロファイルが用意されています。
ユーザの行うべき対処
tlmgr で最新版の jfontmaps をインストールした上で，
$ sudo kanji-config-updmap-sys hiragino-elcapitan-pron
を実行し，新ヒラギノフォントを使用するよう dvipdfmx のフォントマップ設定を更新してください。
このあたりから次第に話が TeX のフォントの取り扱いの闇に突入していきます。
問題4. dvipdfmx の OpenType Collection 対応問題
問題の詳細
上述の通り，新ヒラギノフォントは .ttc という拡張子を持っていますが，実態は OpenType Collection (OTC) です。OTC は新しいフォント形式であり，これが広く一般ユーザの手に渡るようになったのは，昨年の Source Han Sans（源ノ角ゴシック） のリリースがきっかけでした。
TeX 側の対応
時を同じくして，今年の4月，XeTeX のメーリングリストで，中国語ユーザから，OS X 付属の Hannotate SC などの中国語フォントが XeTeX で使えないという問題が報告されました（このメールとこのメール）。これらの中国語フォントはOTCでした。XeTeX でOTC形式に対応するため，xdvipdfmx に改修が加えられました (r37053, r37054)。
そして，dvipdfmx と XeTeX の xdvipdfmx はソース基盤を共有していますので，dvipdfmx もその恩恵を被り，dvipdfmx も“いつの間にか” OTC 形式のフォントに対応するようになっていました。
ただし，OTC対応を果たした (x)dvipdfmx が収録されているのは TeX Live 2015 以降です。よって，TeX Live 2014 以前では，上記のシンボリックリンク張り直し・dvipdfmx のマップ設定更新を行っても，dvipdfmx で新ヒラギノフォントを埋め込むことはできません。
ユーザの行うべき対処
TeX Live 2015 にアップデートし，最新版の dvipdfmx を使用するようにしてください。 MacTeX を利用している場合，（ディスク容量を気にしないならば）旧環境はそのまま放置して，上から MacTeX 2015 をインストールすればよいです。
TeX Live 2015 へのアップデートが困難な場合，
$ sudo kanji-config-updmap-sys ipa
または
$ sudo kanji-config-updmap-sys ipaex
を実行し，使用する和文フォントをヒラギノフォントではなく IPA(ex)フォントに変更すれば，とりあえず和文文書作成はできるようになります。
（pTeX の場合は ipa, upTeX の場合は ipaex を指定するのが好ましいようです。）
問題5. LuaTeX の OpenType Collection 対応問題
問題の詳細
dvipdfmx と異なり，LuaTeX は，TeX Live 2015 の段階でも，OTC対応がなされていません。従って，現在の TeX Live 2015 の LuaTeX では，新ヒラギノフォントを使用することはできません。
TeX 側の対応
しかし，id:acetaminophen さんの発見に基づき，北川さんが対応パッチを作成してくださりました。そのパッチは，角藤先生によって開発版の LuaTeX に r5330 として取り込まれています。
これと開発版の luaotfload を組み合わせることにより，開発版の LuaTeX では，Source Han Sans をはじめとするOTC形式のフォントを使用できるようになりました。
新ヒラギノフォントについても，従来の LuaTeX-ja の
\usepackage[deluxe,hiragino-pron,jis2004]{luatexja-preset}
などのプリセット設定が，El Capitan でもそのまま用いることができるようになります。
ユーザの行うべき対処
北川さんのパッチが取り込まれている LuaTeX は，本日（2015年10月8日）リリースされた LuaTeX beta-0.81.0 以降であり，また，それに加えて開発版の luaotfload も必要になります。これらが一般ユーザに行き渡るのは，おそらく来年の TeX Live 2016 のリリース時になるでしょう。それまで今しばらくお待ちください。
それまでは，
\usepackage[ipaex]{luatexja-preset}
などとして，IPA(ex)フォントを埋め込んで凌いでください。
TeX Live 2016 リリース後は，再び
\usepackage[deluxe,hiragino-pron,jis2004]{luatexja-preset}
のように戻せば機能するようになるはずです。
問題6. luaotfload のフォント名取得問題
問題の詳細
従来から存在した，
- ヒラギノ明朝 W3, W6
- ヒラギノ角ゴ W3, W6, W8
- ヒラギノ丸ゴ W4
については，上記の LuaTeX 側のパッチ対応で LuaTeX から使えるようになります。
しかし，El Capitan で新たに増補された
- ヒラギノ角ゴシック W0, W1, W2, W4, W5, W7, W9
- クレー ミディアム／デミボールド
- 筑紫A丸ゴシック レギュラー／ボールド
- 筑紫B丸ゴシック レギュラー／ボールド
については，同じように使用しようと思っても，
.../texmf/fonts/opentype/hiragino/HiraginoSans-W1.ttc(HiraKakuProN-W1:-1)Invalid TTC index number
のようなエラーを吐いて，使用することができません。
原因
これは，LuaTeX 本体ではなく，LuaTeX がフォントのロードに用いている luaotfload というユーティリティ側にあります。例えば，上記の ヒラギノ角ゴシック W1 の場合，
- 実ファイル名：ヒラギノ角ゴシック W1.ttc
- シンボリックリンク名：HiraginoSans-W1.ttc
- Full Name: Hiragino Sans W1
- PostScript Name: HiraginoSans-W1
なのですが，そのどれにも当てはまらない HiraKakuProN-W1 という名前でロードしようとして，そのような PostScript 名を持つフォントが存在しないため，フォントのロードに失敗しています。
一方，この表にあるように，従来から存在した
- ヒラギノ明朝 W3, W6
- ヒラギノ角ゴ W3, W6, W8
- ヒラギノ丸ゴ W4
については，従来と同じ HiraKakuProN-W3 といった PostScript 名を持つフォントが OTC バンドルの一部に存在しているため，フォントのロードに成功するのです。
このままでは，せっかく El Capitan で和文フォントが増補されたのに，追加分のフォントを LuaTeX から扱うことができず，多書体を容易に扱えるという LuaTeX の強みが生きません。
TeX 側の対応
前田さんが OTC 内のフォントの PostScript 名を正しく読み取るよう luaotfload を改修するパッチを作成してくださいました。現在（2015年10月8日）本家開発元に取り込みを依頼中です。
ユーザの行うべき対処
今のところ対処法はありません。TeX Live 2016 にて修正版が収録されることが期待されますので，それまでお待ちください。
問題7. Adobe-Identity-0 かつ OpenType Collection となった新游明朝体問題
問題の詳細
El Capitan の YuMincho.ttc の特殊性
Mac においては，OS X 10.9 Mavericks から，游明朝体・游ゴシック体が収録されるようになりました。
ところが，OS X 10.11 El Capitan では，この表にあるように，游書体は少し変則的な扱いとなっています。
- 游ゴシック体については，従来通りウエイトごとに別々の otf ファイルのままです。
- /Library/Fonts/Yu Gothic Medium.otf
- /Library/Fonts/Yu Gothic Bold.otf
- 一方，游明朝体は，新しい 游明朝体+36ポかな を加えて，4種類のフォントが YuMincho.ttc という1つの ttc（実態は otc）ファイルに収録されています。
「游明朝体」と「游明朝体+36ポかな」は，漢字部分は全く同一ですが，かな部分が異なります。「游明朝体+36ポかな」の方が，よりクラシカルなかなのデザインとなっています。
「36ポかな」というのは一見奇妙な名前ですが，開発元の字游工房によると，大正時代の見出し向け36ポイントの金属活字のデザインをもとにしているという意味だそうです。
游明朝体36ポかなファミリーは、游明朝体の漢字と合わせて使えるクラシカルなかな書体です。大正時代に制作された36ポイント（見出し向けサイズ）の金属活字をベースにデザインしました。毛筆の表現力をしっかりと活かして書かれた表情ゆたかな線と、独特のスタイルをもった字形が、このかなの大きな特長です。タイトルや見出しなど、大きなサイズでお使いいただくと、その個性がより一層引き立ちます。
さて，「游明朝体」と「游明朝体+36ポかな」は漢字部分は共通であるので，それぞれ別々のフォントファイルにするのはディスクスペースの無駄です。そこで，YuMincho.ttc においては，両フォントで漢字部分のグリフデータは共有し，かな部分のCID番号を棲み分けることで，2種類のかなを使い分けています。
そのような仕組みを実現するため，YuMincho.ttc は，従来の Adobe-Japan1 のような標準化された文字コレクションに従う ROS (Registry, Ordering, Supplement) を持っておらず，CID番号とグリフの対応は独自のルールに従っています。このような ROS を Adobe-Identity-0 といいます。
Adobe-Identity-0 のフォントが広く一般ユーザの手に渡ることになったのも，昨年の Source Han Sans がきっかけでした。
dvipdfmx と CMap ファイル
dvipdfmx は，マップ設定において，UnicodeとCID番号との対応を規定する CMapファイル を指定しています。例えば，
uprml-h UniJIS2004-UTF16-H HiraMinProN-W3.otf uprml-v UniJIS2004-UTF16-V HiraMinProN-W3.otf upgbm-h UniJIS2004-UTF16-H HiraKakuProN-W6.otf upgbm-v UniJIS2004-UTF16-V HiraKakuProN-W6.otf
の例では，UniJIS2004-UTF16-H のようなファイルが CMap ファイルに該当します。 これらの CMap ファイルには，UTF16 の16進バイト列と Adobe-Japan1 のCID番号がどのように対応するかが記述されています。
しかし，YuMincho.ttc に収録された「游明朝体」や「游明朝体+36ポかな」は，Adobe-Japan1 のような既存のルールに従うわけではありませんので，UniJIS2004-UTF16-H のような既存の CMap ファイルは一切使えません。 YuMincho.ttc のような Adobe-Identity-0 のフォントに対しては，そのフォント専用の CMap ファイルを作成する必要があるのです。*1
TeX 側の対応
昨年の Source Han Sans のときには，専用の CMap ファイルを作成することで dvipdfmx を Adobe-Identity-0 フォントに対応させました。
今回も同様に，縦横両対応の CMap ファイルを作成して Adobe-Identity-0 の YuMincho.ttc を迎え撃つことにしました。
作成した CMap ファイルはこちらです。
ユーザの行うべき対処
El Capitan の「游明朝体」や「游明朝体+36ポかな」を upLaTeX + dvipdfmx で使いたいユーザは，上記 CMap ファイルをダウンロードしてご利用ください。
UniYuMin* や JisYuMin* のファイル一式を，$TEXMFLOCAL/fonts/cmap/Yu/ といったディレクトリに配置し，適宜 mktexlsr します。そして，dvipdfmx のマップ設定を行います。
(u)pLaTeX + otf パッケージ を使えば，游書体6種を同時利用することができます。詳しくは上記 Gist 付属のテスト用ファイルをご覧ください。*2
なお，TeX Live 2016 の LuaTeX-ja では，El Capitan の游フォントに対しても，従来通り
\usepackage[yu-osx]{luatexja-preset}
が使えるようになる予定です。（「游明朝体+36ポかな」を利用したい場合は別途設定が必要です。）
一方，dvipdfmx を利用する場合は，従来の
$ sudo kanji-config-updmap-sys yu-osx
の設定は利用できませんのでご注意ください。jfontmaps の yu-osx は，OS X 10.9 / 10.10 の Yu Mincho Medium.otf などを利用する設定プロファイルだからです。
問題8. Ghostscript の OpenType Collection 対応問題
問題の詳細
Ghostscript は，現状，OpenType Collection に対応しておらず，対応の見込みも当面ありません。よって，(u)pTeX + dvips + Ghostscript の変換経路では，El Capitan の新ヒラギノフォントを埋め込んだPDFを作成することはできません。
ユーザの行うべき対処
今のところどうしようもありませんので，
- ヒラギノフォントの使用を諦めて IPA(ex) フォントを用いる
- 可能なら dvipdfmx を用いる変換経路を用いる
- 和文文字入り PSTricks 図版を作成したりする用途なら XeLaTeX で代用するか bxdpx-pstricks パッケージを利用する
- OTC形式になっていない通常版のヒラギノフォントを購入してインストールする
といった対応を各自検討してください。
*1:別の方法として，dvipdfmx のマップ設定における CMap ファイルの部分に unicode と指定するという手もあります。この場合は CID 番号ではなく Unicode で直接アクセスします。この方法ならば，upTeX を使っている場合であれば CMap ファイルなしで文字の出力ができますが，その方法の場合縦書きには対応できないという問題点があります。
*2:ただし，この独自 CMap ファイルを用いて縦書きを行った場合，小書き仮名や音引き・約物など，縦書き時にグリフの置換が行われる文字については，ToUnicode が正しく機能せず，PDFからの文字のコピーにおいて元の文字が正しく抽出できないという問題点があります。これは，おそらく CMap ファイルや dvipdfmx の問題ではなく，YuMincho.ttc のファイルの作られ方にバグがあるものと思われます。実際，YuMincho.ttc は palt feature に関しても異常があるという報告があります。
