そもそもなんでそういう現象が起きるのか

　Macの「ターミナル」はbashやzshといった「シェル」を使うためのアプリです。Windowsで言うところのコマンドプロンプトですね。で、例えばOSに元々入っているバージョンとは違うPerlやPythonを使いたいとか、非標準モジュールを入れて使いたいといったような場合にはmacの場合はパッケージマネージャーのHomebrewやMacPortsをまず入れてその後それを使ってさまざまな必要なものを入れていって環境を構築するわけですが、入れたものを有効にするために「パスを通す」作業が度々発生します。これは作業手順自体は検索すればいくらでもWebで見つかるのですが、要はシェル（bashやzsh）の環境設定ファイルである「.bash_profile」や「.zshrc」にシェルの起動時に自動実行する設定（環境変数の設定など）を記述しておく作業です。これをやることでいちいち実行ファイルのあるディレクトリに移動してからコマンドを実行するようなことをしないでも良くなるわけです。

　ただ、「.bash_profile」や「.zshrc」への記述は、あくまでターミナルでシェルを起動した際に読み込まれる設定であるため、AppleScriptやXojo内からシェルに処理を投げた場合には適用されません。このため、ターミナルでは通っていた処理が通らなくなったりします。

シェルに処理を投げる際に設定を読ませれば処理は通る

　ではどうすればよいのかと言うと、例えばApplescriptの場合なら以下のように

　命令文の前に環境設定の記述をセミコロンで繋げて実行してやれば処理が通ります（この場合サンプルとしてHomebrewのバージョンを表示させている）。環境設定の記述はターミナルで処理が通っているのなら現在有効にしているシェルの設定ファイルのどこかに記述があるはず。

bashやzshの環境設定を読み込んで実行するようにした

　ただ、上記の方法だとApplescript等のコード自体に各環境に依存する表記を追記することになるため、違うマシンにスクリプトを持って行くとたちまち動かなくなるといったような話になりそうです。それはできれば避けたいため、シェルの環境設定ファイル自体を読み込むperlスクリプトを作ってみました。

　exportもしくはevalで始まる行を抽出してセミコロンで繋げたものを返すので、あとはそれを実際に実行する処理の前に連結してシェルに処理を投げればOKです。

Applescriptに組み込んだ場合は以下のような感じ。上のperlスクリプトをshellconfigexec.plの名称でスクリプトバンドル形式ファイル内のContents/Resourcesフォルダに保存して実行しています（macOS 12 Montereyではアプリ形式で保存しようとするとエラーが出て保存できなかったりするため、スクリプトバンドル形式で保存してスクリプトメニューから実行）。

　シェルの設定ファイルの処理を全部引っこ抜いて実行が乱暴すぎるという場合は読み込みファイルを独自定義してルートディレクトリに置いておき、それを指定して読み込ませればよいです。

悩ましいEPUBの「注」

　EPUBを作っていて結構手間がかかるのを覚悟しなければならないのが「注」です。注は紙の本では脚注、頭注、段間注、章末注、巻末注など配置位置によってさまざまに分類されていますが、（少なくとも現在の）リフローのEPUBでは同一画面内に注と本文を表示する脚注や頭注は再現が難しいので、注のテキストは章末や巻末に移動して本文内の合印との間に相互リンクを設定することになります。Amazonは現在制作仕様として注の相互リンクの設定を求めていますし、実際リンクの設定がないと電子本で注を参照しながら読むのはかなりストレスがたまるので相互リンク設定を指定することの意味はよくわかります。ただ、数百の注が存在するような類の本では相当な手間がかかるのも確かです。また、どう頑張ってもエンタメと同レベルの売り上げは期待できない難解な人文書などでは、コンテンツが複雑化・高度化すると制作費用の回収が困難になるという切実な悩みも当然あるかと思います。

悩ましいEPUBの「索引」

　同様に、言うなればリンクの塊である「索引」ページの電子化も当然大変です。難しめの本では巻末の索引を全てリンクにすると1000点を超えるようなケースは普通にありますので、膨大な手間（＝コスト）がかかります。このため、現在DTPデータからのEPUB制作では索引はリンクとせず、用語だけ残す、あるいはページ自体を削除するという判断をするケースが多いようです。EPUBでは本文内を全文検索もできますので、そういう判断になるのは理解できるところです。

根本にある「2画面の相互参照」という要望

　ではなぜ注や索引の電子化に手間がかかるのかというところを考えてみると、「手作業で膨大な数のリンクの設定が必要になるから」というところに行き着きます。そしてなぜリンクしなければならないかと言えば、紙の本では許されていた脚注や頭注の配置のような「マルチカラム」レイアウトがEPUBでは現状許容されず、「シングルカラム」レイアウトに作り変える必要があるから、という点に集約されるのではないかと思います。紙の本では読者は同一ページ内の2つの「画面」を相互参照しながら読んでいるのです。
　索引も読者の行動としては索引ページを参照して本文ページをめくることになるので、2つの画面を見比べて読んでいるという行動自体は変わらないように思います。こちらも同じく実は「2画面の相互参照」なのです。
　見開きで片方のページに図を配置し、対向ページに解説を置くというスタイルにも共通の意味合いがありそうかなと思うのですが、そこにまで言及するとちょっと切りがなくなりそうなので今回はそこは触れないでおきます。

複数の本をまたいだ「注・索引」を実現するには？

　また、注を多数含むような本を電子化していれば嫌でも気づくことですが、現在EPUBでは「その本とは違う本の特定の箇所」にリンクを貼ることができません^※1。これは「特定のEPUBを指し示す世界共通の識別番号がまだない」という根本的な問題があるのでどうにもならないのですが^※2、外部参考文献の参照に支障があるというのはやはり現状のリフローのEPUBが抱えている欠陥のひとつだと思います^※3。
　これの解決手段としては「共通の識別番号を設定してリンクを貼れるようにする」以外に、「紙の本のページ番号をタグとして埋め込んで呼び出せるようにする」、「そもそもフィックス型で電子化する」などが考えられますが、さてどれが最適解なのかは今後市場が決めていくことになるのかなと思っています。当然どういった種類の本なのかによっても変わってくるでしょう。現在法律書などは固定レイアウトでの電子版提供が一般化している^※4ようですが、そういう傾向がずっと続くのかはもちろんわかりません。

EPUBビューアに「タブブラウジング」機能が欲しい

　では電子版で2画面の相互参照を「リンク」を使用せずに行うにはどうすればよいのかと考えてみると、例えばごく単純に「2つのデバイスを用意する」ということを思いつきます。手元にタブレットを置いて注のページを参照しながらPCの画面でも同じ本の本文ページを開いて見比べながら読む、といったような行為です。これは既にやっている人はやっているかと思いますし、単純に画面が2つあるわけですから参照は容易でしょう。ただ、当然ながらデバイスを複数用意する追加コストは必要になりますし、電車の車内など手狭な場所で2つのデバイス画面を見比べながら読むのは厳しそうです。いずれVRデバイスがマルチ画面を実現してくれることを期待していますが、それはまだまだ先の話です。
　そこで思いつくのが、現在Webブラウザではごく一般的になっている「タブブラウジング」の機能です。タブレットで同じ本の複数のページを同時に開いて適宜タブをタップしながら画面を切り替えて読むことができれば、EPUBに相互リンクの設定が無くても気軽に注と本文を見比べられそうです。これならリンク設定ができないフィックス型のEPUBにも恩恵があるはずですし、既存のEPUBに手を加える必要もありません。当面タブレットやPCのようなマシンリソースに余裕のあるデバイス限定にはなるでしょうが、ビューアが採用してくれるとよいなあと思っています。タブはユーザー体験的に「枯れた」技術でもあるので、すんなり受け入れられるかなとも思います。

新フォーマットへの完全切り替えが秒読み

　Amazon Kindleの新フォーマットへの切り替えがだいぶ進んできているようです。Amazon Kindleは2012年の日本上陸からずっと出版社には「.mobi」形式のファイルの納品を求めてきたのですが、今年の6月あたりから「.epub」形式で納品してAmazon側で変換という形に変わっています。背景にあるのはAmazonが「タイプセッティングの改善」と呼んでいるものへの対応で、これは新しめの本を購入してKindleアプリなどで開いてみれば古いものと明らかに違うユーザーインターフェースで開かれるので区別ができます。つまり今のKindleアプリは新旧の表示エンジンを両方持っているのです。なお聞いた話では現状まだMac版／Windows版は「タイプセッティングの改善」に未対応とのことなのですが、これもおそらくは近々切り替わるのでしょう。先日既存コンテンツの変換も始まったらしいという情報が流れてきましたので、完全切り替え秒読みというところだろうと思っています。

　今、Kindle Previewer3でEPUBを表示させて「エクスポート」を選ぶと、「.kpf」という形式でのエクスポートを選択できます。これが「タイプセッティングの改善」に対応した次世代フォーマットということかなと思います。

埋め込みフォント対応が気になる

　さて、新フォーマット対応でこれまで制作時に悩まされてきた様々なKindleの表示の不具合が解消されることを期待していますが、それはいずれ表示チェックするとして、今気になっているのが「埋め込みフォント」の表示対応です。
　現状、一般的に電子書店で販売されている電書協ガイド準拠のEPUBでは、制作者が明示的に表示フォントを指定することはできません。もしどうしても特定のフォントで表示させたければ、EPUBのファイル内に表示フォントを収録してそれを表示させるしかありません。Webと異なりオフラインでも表示できることが前提となるEPUBでは、外部サーバーのWebフォントにアクセスして字形データを取得して表示させるといった手段は取り得ないからです。このため、フォントのライセンスが大きな問題となり（ソフトウェアバンドル扱いになるとのこと）、現状まだ商用フォントを自由に埋め込んで利用できる状況ではないのですが、もしKindle全プラットフォームで埋め込みフォントの利用が可能ということになれば、例えばSIL Open Font Licenseなどで公開されているオープンソースのフォントを埋め込んで利用することを考えられますし、商用フォントであってもフォントメーカーに個別交渉をすれば利用が可能になるので製作物の表現の幅は広がるはずです。

星海社の本でフォント埋め込みの対応状況をチェックする

　埋め込みフォントにKindleの各プラットフォームが対応しているかどうかのチェックをどう行うかですが、星海社さんが自社でフォントを開発し、既にそれを埋め込んでいることを売りにしていますので、ありがたくチェック用として使わせてもらうこととします。現状手元のファイルを端末に転送してKindleのビューアで表示させても「タイプセッティングの改善」が適用された状態になりませんので、明確に埋め込みフォント対応を行ったことを謳った本が市場に出ていることはかなり有り難いです。
　なお今回は知人の著書の「迷宮駅を探索する」をチェック用に利用しましたが、星海社 e-SHINSHOはどれも埋め込みフォント対応のはずです。

　以下、各プラットフォームでの表示結果になります。