検索にヒットしない文字

[tsumetogi]

お世話になります。

Adobe-Japan1-4～6のモリサワの書体に的を絞り、
スクリプトで丸数字を数字に一括置換しようと思うのですが、
同じ書体・同じCIDでも、「検索と置換」ダイアログボックスの「字形」タブからの検索で、
ヒットしない文字があります。

1．テキストフレームを作成
2．Proの書体にして字形パレットから○32（CID：10244、Unicodeなし）をダブルクリックして入力
3．2．の文字を選択し、Pr5の書体に変更
4．Pr5の書体で字形パレットから新たに○32（CID：10244、Unicode：325C）をダブルクリックして入力

このように作成されたデータの場合、どちらの文字も、
選択して右クリックの「検索に選択した字形を読み込み」で、同じコードが読み込まれます。
字形パレットに表示される内容も同様です。

しかし実際に検索すると、
4．の文字はヒットするのですが、3．の文字はヒットしません。

情報パレットを見ると、
4．はUnicode：325Cですが、3．はUnicode：001A（Proのママ）となっておりました。

<001A>として、3．を「テキスト」タブからの検索でヒットさせることはできるのですが、
（「字形」タブからの検索ではヒットしませんでした）
同じ状態の他の丸数字も引っかかってしまいます。

この場合、「テキスト」タブから検索してヒットした後、
その文字がCID：10244であるかどうか、という情報は、
InDesignのスクリプトで判別可能なのでしょうか。

もしくは、3．の文字を4．の文字と同じ状態にする動作などはあるのでしょうか。

そもそもですがこのような現象となる原因が、
cmapの違いのせいなのかInDesignの仕様なのか、
当方の知識不足で分からず、行き詰まってしまった次第です。

環境は、Windows 10、InDesign CC2022で再現できました。

どなたかご存知の方がいらっしゃいましたら、ご教示いただけますと幸いです。
何卒よろしくお願い申し上げます。

[works014]

Unicode キャラクター図鑑（https://unicode-table.com/jp/325C/）を参照すると「丸数字32 was approved as part of Unicode 3.2 in 2002.」となっています。一方、例えばリュウミンの場合、Wikipedia（https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%A5%E3%82%A6%E3%83%9F%E3%83%B3）を参照すると「Pro（Adobe-Japan1-4）…2002年」となっています。
この辺りに微妙な作業上での時間のズレが発生しているのではないでしょうか？

[yusuke.s]

001A というコードポイントは、存在しないコードポイントの代替として使われるものです。

https://www.fileformat.info/info/unicode/char/001a/index.htm

InDesignで遭遇するケースでは、おっしゃるように「フォントの字形（GSUB機能）だけで表現される、コードポイントを持たない字形」が多いです。

リュウミンPro はこの字形をコードポイントを持たない文字として扱います。

Pr5やPr6でも（InDesignからなら）グリフだけを指定して画面に表示させることができます。

Proで32の丸数字を表示させ、フォントだけ変えてもコードポイントが 001A のままなのはそういうことです。

一方、Pr5やPr6を設定した状態で字形パネルからダブルクリックで入力すると、コードポイント持った文字として挿入されます。

これは収録文字数が増え、新しいUnicodeにも対応して32の丸数字にもコードポイントを割り当てたからです。

リュウミンPro に限らず、001A というコードポイントから何か情報を得ることはできません。

コードポイントを持たない特定の字形を検索したい場合は、字形検索機能を使うしかありません。

字形検索機能を使うということは、フォント（ファミリーとウェイト）とCID番号ないしコードポイントを一意に指定するということです。

当初の目的である、丸数字をアラビア数字に変換するというスクリプトであれば、

• 利用したいフォント（ファミリー＋ウェイト）で置換対象とする丸数字のすべてのCID番号を控える
• （コードポイントを持つものはコードポイントでも可）
• それらを総当り的に「CID番号：置換したいアラビア数字」という組み合わせの辞書のようなものを用意する

という事前作業が必要になろうかと考えます。

僕も似たようなスクリプトを作ろうとして、あまりの手間に一度諦めました。

ただ文字のコードポイントとグリフの関係をしっかり理解してから作業にかからないと、どんな不具合が起きるのかの予測もままなりません。

入念な準備とテストが必要になるでしょう。

[assause · Accepted solution]

こちら、「InDesignの仕様」でもあり「一般的にはそうせざるを得ない」ともいえます。

字形パネルで入力した場合、InDesignでは、Unicodeが優先されますが、UnicodeがCMapで付与されていないCIDやGIDのみのグリフは、そのコードで入力処理されます。
よって、InDesign上のテキストに残るのは、（すでにyusuke.sさんが記載されてますが）001Aと、CID/GIDのグリフコードのみで、これが「文字列情報の実体」です。
グリフコードがあるので、その情報がフォントに渡されて字形表示されますので、グリフコードが同じであってフォント側にもそのグリフがあれば、フォント変更をしても表示の変化は起きません。
このあたりはInDesignの仕様、ともいえます。

ただ、異なるフォントに変更しても、「文字列情報の実体」はそのままですから、Unicodeはテキスト情報としては勝手に変化することはありません。
ここは逆に「一般的にはそうせざるを得ない」部分になるでしょう。

裏で持っているグリフコードを元にしてUnicode変換は、理論でいえば可能だと思います。
問題はその変換が、フォントおよびそれに付随するCMapと一致するものを利用して行えるか、というところです。
Adobe-Japan1用のCMapも初期から現在まで複数あるので、確実に処理するという点ではいろいろと考えないといけない、ということになりそうです。

[tsumetogi]

皆様、お答えいただきありがとうございます。

現象は皆様のご説明のおかげで理解できました。

ありがとうございました。
書体の変更ではUnicodeは変らないということなんですね。

今回のようなCIDの字形検索でもヒットしなくなってしまった文字は、
目視で処理するしかないようですね...

assause様
ちなみに裏で持っているグリフコードというのは、
ExtendScriptで読み取れるのでしょうか。

[assause]

テキスト側で持っている検索としてでいえば、findGlyphPreferencesでの処理はできるとは思います。

置換のほうがchangeGlyphPreferencesを使えばできそうな気はするんです、が……自分がそこまでスクリプト得意ではなく、実際の実行まで至っていません。

（自分ならInDesignタグテキストに書いてからcSpecialGlyphか、IDMLにしてCustomGlyphを処理してしまうところです。それらの形式を再度取り込み/開くことの影響も別に検討は必要になりますが）

[tsumetogi]

assause様

InDesignタグ付きテキストやIDMLなど、
一旦書き出したデータからだと解析できそうですね。

こちらの方法も勉強しつつ、試してみます。
ありがとうございました。

[monokano · Accepted solution]

モリサワのProは、Adobe-Japana1の古いバージョンです。

「㉜」はAJ1-4ですが、古いバージョンではcmapで紐付けされていませんでした。モリサワは互換性を重視しているので、（新しいProフォントでも）最初に出した当時のバージョンのAJ1-4のままなのです。

まとめると、

・Adobe-Japana1はバージョンアップしてCMapが改訂されることがある。

・モリサワは最初に出した時点のAdobe-Japana1のバージョンのまま固定している。

・Std/Proは、それぞれ最初に出した当時のバージョンのAJ1バージョンになっている。

・Pr5とPr6はモリサワのアップデートがあり、その時点のAJ1バージョンに改訂されている。

>その文字がCID：10244であるかどうか、という情報は、InDesignのスクリプトで判別可能なのでしょうか。

残念ながらできません。

>もしくは、3．の文字を4．の文字と同じ状態にする動作などはあるのでしょうか。

残念ながらありません。

[tsumetogi]

monokano様

ご回答ありがとうございます。

スクリプトでその文字を掴めてもCIDが取り出せないのは残念です。
このような不正（という言い方が正しいかどうか）な文字が混在していると厄介ですね。

どうしても目視以外で、となると、
別のスクリプトを作成し、
力業で調べるしかなさそうでしょうか。

仮に対象が○32だけだとして…
001Aとして文字検索を行い、
ヒットした文字をPro書体に変更し、
その文字に対してCID：10244の字形検索を行い、
結果が返ってくれば○32と判定して、
ページ番号や前後の文字などをレポートして表示

あまり推奨はされないやり方かもしれませんが、
他に思いつかず…