CarbonアプリだったComoを64bit Cocoaアプリにしました。
ダウンロードはこちらから。→ monokano/Como-Lite
Illustratorはリンクファイルをどうやって探しているのか
2023.3.29 改訂 間違っていた箇所を修正。
Illustratorって、リンクファイルのリンクがいつどこで変わるのか把握しにくくて、管理が難しいですよね。そこで「Illustratorはリンクファイルをどうやって探しているのか」をここで整理してみます。
まず、大前提から。Illustratorファイルの中には「リンクファイルがどこにあるのか」の情報がフルパス（絶対パス）で保管されています。下図は、保管されたリンクファイルのフルパスの例です。
Illustratorは、ファイルを開く時、保管されたフルパスをもとにしてリンクファイルを探します。この時、探しに行く順番があるのです。この順番がとても重要なんです。
- フルパスに同名ファイルがあったら、そのファイルとリンク
- 1 がなかったら、Illustratorファイルと同じ階層にある同名ファイルとリンク
- 2 がなかったら、Illustratorファイルと同じ階層にあるLinksフォルダ内の同名ファイルとリンク
ファイルを開く度に、Illustratorはかならずこの順番でリンクファイルを探します。
さらに、Illustratorのバージョンで違いがあります。
- CS6（v16.0）まで：２番目まで探しに行き、なかったらリンク切れ
- CS6（v16.1）以降：３番目まで探しに行き、なかったらリンク切れ
とにかく、どのバージョンでも、かならず１番目から順番に探しに行くのだと覚えてください。
たとえば…
下図のように画像ファイル９個をリンクしている場合を見てみます。よく見ると同名ファイルが混在してることが分かります。
この画像ファイルのフルパスがすべて変更されたとします（上位フォルダの名称を変えたり、上位フォルダを移動したりするだけでフルパスは一気にすべて変わります）。そしてその状態でaiファイルを開くと、Illustratorは１番目（保管されたフルパス）で同名ファイルを見つけられないので、次の２番目で探します。するとどうなるか…。
２番目は「Illustratorファイルの同階層にある同名ファイルとリンク」ですから、こうなってしまいます。何の警告も出してきません。この現象は２番目で発生するので、Illustratorの全バージョンで同じ結果になります。同名ファイルをリンクするのはまじでヤバいんですよ…。恐怖！
と、このように１番目から順番に追っていくと、Illustratorがリンクファイルを選んだ理由が分かるようになるのです。
ちなみに、InDesignも同じ現象になるのですが、なんと、ちゃんと警告してくれるんですよ！ インデデさん大好き！
浮紙 8.1.0
浮紙を8.1.0にアップデートしました！
ダウンロードは 浮紙ページからどうぞ。
- 新規 テキスト整形項目に「縦組用約物を解決」を追加。
- 修正 テキスト整形項目「CJK 部首補助／康煕部首を解決」が動作していなかったのを修正。
- 改善 左上メニューを少し整理した。
縦組用約物の文字コードなんかDTPで使ってはいけません。でも、他所で作られたデータにたまに紛れ込んでるんですよね…。たぶんきっとPDFの編集機能のせいです。これについてツイートしたので貼っておきます。
https://t.co/TpJm2jk0uK
AcrobatのPDF編集機能に「新規テキストの追加」があって、これを縦書きにして注釈のように使われるとホントにもう最悪。どうしてかというと、編集機能をOFFにして確定すると、約物の文字コードが縦組専用（CJK互換形）に変わってしまうのだ…。 pic.twitter.com/Edngh9xjX4— ものかの (@monokano) March 23, 2019
これを実装していたら、「CJK 部首補助／康煕部首を解決」が動作していなかったのに気づきました…。ごめんなさい！
欧文フォント混植の理想と現実
縦組で英数字を欧文フォントにするのは、きわめて筋が悪い。どのように筋が悪いのかをtwitterで連投したので、ここに貼っておきます。
欧文フォント混植の理想と現実 pic.twitter.com/ju4V40Iql6
— ものかの (@monokano) March 13, 2019
縦組の欧文フォント混植は、スペーシングの問題だけでなく、行分割の問題も同じくらい深刻です。欧文文字コード列は行分割禁止になる（丸ごと次行へ追い出されてスカスカに間延びする）ので、正立回転する文字は全角英数の文字コードにする必要があります。深刻な問題は同時に２種類あるのです。
— ものかの (@monokano) March 14, 2019
スペーシングの問題はフォントのグリフ、行分割の問題は文字コードに関わる話です。デジタル組版の文字は構成要素にグリフと文字コードの異なる２種類のデータを同時に持ちます。ですから、今のデジタル時代の組版設計は、グリフと文字コードの両方のふるまいを考慮しなければなりません。そうしないと、設計として成立しないのです。
ヒラギノをDTPで使うコツ
ヒラギノは一部の記号が他のAJ1フォントと異なります。例えば、他のAJ1フォントで「×」「÷」は和文用全角グリフですが、ヒラギノだけは欧文用プロポーショナルグリフです。以下がその一部の記号。
§¨°±´¶×÷‐′″ℏℵ↔⇒⇔∀∂∃∅∇∈∊∋∑−∓√∝∞∟∠∧∨∩∪∫∬∭∮∴∵∽≃≒≠≡≦≧≪≫≲≳⊂⊃⊆⊇⊕⊖⊗⊘⊠⊥⊿
DTPでヒラギノを使うと、これらの記号が欧文用になってしまうのでかなり悩まされます。でも、InDesignならこれらを正規表現スタイルで等幅全角字形になるように仕込めばOK。ついでに「‘’“”」も加えるとさらにグッドです。インデデさん大好き。
すこし詳しい説明
AJ1のCMapには大きく分けて「UniJIS」「UniJISX0213」の２種類があります。UniJISX0213はヒラギノだけに採用されています。それ以外のAJ1フォントはすべてUniJISです。
この２種類の違いについては、ちゃんと公式なドキュメントで説明されています。
adobe-type-tools/cmap-resources/Adobe-Japan1-7
上記リンク先の「cid2code.txt」に詳細な説明が書かれています。
でも、どうしてAJ1にヒラギノだけが使っているUniJISX0213があるのか、その理由までは書かれていません。ここから私の推測なのですが、ヒラギノはmacOSのシステムフォントとして、UIでの表示を最優先とし、上記の記号を欧文用文字で表示するようにしているのかもしれません。日本語フォントとして上記の記号が欧文用なのは、率直に申し上げると、まともではありません。やはりAppleの意向に合わせた特異な措置なのであろうと思われます。
DTPでヒラギノを使うなら、UniJISX0213をUniJISに合わせた方が良いでしょう。方法は、上記の記号に等幅全角字形を適用するだけです。これだけでかなり使いやすくなります（中には欧文用の方が使いやすい記号もあったりするかもなので、そこは取捨選択してください）。
追記：
それほど大事ではないと思ったので省いたのですが、念のため書いておきます。UniJISとUniJISX0213の違いは上記のほかにU+2012「‒」があります。これはFIGURE DASH（数字の幅のダッシュ）と呼ばれるものです。しかしAJ1では数字の幅ではなく、UniJISはENダッシュ「–」、UniJISX0213はハイフン「-」と同じグリフが表示されます。まあでもFIGURE DASHを日本語組版で使うこともないでしょうから、これは無視して良いでしょう。
かなり前に作った一覧PDFもついでに公開しておきます。
［PDF］Difference in UniJIS and UniJISX0213.pdf