印刷組版データ制作者は両者を分けて考えている

　私は電子書籍制作を担当する前には組版データの作成もやっていましたが、その際には自然に組版ソフトとワープロは別のものとして考えていました。ワープロ等で作成されたテキストデータが元原稿として入ってきて、それを元にの印刷組版データを制作していたわけなのでこれは当然です。おそらく今現在組版データの作成を仕事としている多くの人も同様なのではないかと思います。

一般的には混同されている感がある

　一方で、原稿の執筆者含めて一般的には両者は混同されている感があります。これはPCユーザーの目線に立ってみればわかることで、今は例えばInDesignのような組版ソフトは汎用のコンピュータにインストールして使用するものであり、その同じコンピュータにはワープロソフトも入っていたりするでしょう。「とりあえずAdobe CCは契約してるからInDesignも入れてある」という人は珍しくもないのではないでしょうか。しかもInDesignのようなWysiwygのUIを採用している組版ソフトは簡単な使用感としてはワープロに近いものがありますし、場合によってはワープロの代わりに使ったりもされていそうです。混同されるのも無理はなさそうです。「フォント指定や図版の厳密な配置ができる高級なワープロ」ぐらいの感覚で認識されているのではないでしょうか。もっとも組版ソフトの中にはWysiwygのUIを採用していないものもありますので^※1、全てがそうだというわけではないですが。

それぞれのソフトの成立経緯をみれば違うものなのがわかる

　では実際両者の違いがどこにあるのかということを考えるときに、それぞれが「そもそも何を目的に作られたものなのか」を考えるのが有効な視点かなと思います。

　「組版ソフト」は元々は「活版印刷の組版工程をデジタル化したもの」のはずです。つまり、「本の紙面を効率的に作成するためのもの」です。汎用のパソコンにインストールして使用する「DTPソフト」の前段階として、専用のハードウェアを使用した「電算写植機」などの時代はありましたが^※2、大きな流れとしては間違っていないものと思います。ですから、当たり前ですが図版の配置位置は厳密に指定できますし、フォントや文字等の装飾要素を効率的に指定するための機能も充実しています。一方で、テキスト入力の支援機能、用語統一やスペルチェッカー等の機能は一般的にはありません。元々そこで文章を作成することは想定されていないはずですので、それは当然です。テキスト入力や編集は可能ですが、本来的にはそれは「一度組んだものを発注者の要望に添って修正するための機能」であるように思われます。
　一方で「ワープロ」は元々、「タイプライターをデジタル化したもの」もしくは「原稿用紙をデジタル化したもの」として作られたものであるように思います。つまり、「デジタルテキストを入力するための道具」です。私くらいの年齢だと、その昔は「日本語ワープロ専用機」が当たり前のように使われていたのを覚えています。「OASYS」や「書院」の時代です。ワープロ普及の初期には手書きの原稿をもとに入力が行われていたかと思いますが、やがて個人でもワープロ専用機を使って直接デジタル文書を作成するのが当たり前になり、それはやがて「一太郎」や「WORD」といった汎用のパソコンにインストールして使用するワープロソフトに代替されていきました。もともとがそこでテキストを入力するためのものなので、用語統一やスペルチェッカー等のテキスト入力支援の機能は充実しています。一方で、図版を必ずこの位置に配置したい、などの機能は少なくとも組版ソフトほど充実してはいません。それは後からユーザーの要望に応えて追加されたものに過ぎないからです。

活版印刷の時代には組版作業は工場で行うしかなかった

　さて、ちょっと昔を振り返ってみると、そもそも活版印刷の時代には、本の版面制作は「工場で職人が行うしかない作業」でした^※3。大量の金属活字を置く場所が必要だったはずですし、各工程ごとに職人がいなければ成立しない仕事だったので当然です。
　もちろんその前段階の原稿のタイプライター入力や、原稿用紙への執筆は各出版社や著者の手元の環境で出来る作業でしたが、その先の「組版」は物理的に無理だったわけです。ですから、自然に別のものとして認識されていたでしょう。

　その後の電算写植機の時代にも（現物のキー配置を見れば一目瞭然ですが）、専門性の高い高価な機材を適切に扱うために長期間の訓練を経たオペレータが必要でしたので、組版作業は自然と工場で行うものになっていて、混同はあまりなかったのではないかと思います。
　大幅な変化が起きたのは明らかに2000年以降、汎用コンピュータに組版アプリをインストールして使う「DTP」の普及以降のはずです^※4。DTPは組版処理に必要な機材コストおよび人的コストを大幅に低減化させた功績がありますが、一方で組版のプロの領域の仕事とそうではない前作業の領域の境目をわかりにくくもしました。その結果何が起きたかというと、本来なら前作業の段階で終わらせておくべき推敲や原稿整理を組版工程に入ってから行う例が後を絶たなくなったわけです。組版ソフトをワープロと同じように捉えられているのであれば、当然といえば当然の結果でしょう。これによって（当たり前ですが）組版の現場にそれまでにはなかった負荷がかかるようになりました。

「設計」と「施工」は分けて考えられるべき

　本来、本の制作で推敲や原稿整理などの「設計」にあたる工程と、そのあとの組版処理、「施工」にあたる部分は分けて考えられるべきものです。これは、例えば家を建てることに置き換えれば簡単に理解できるはずで、例えば「一旦3階建ての家を建ててしまってから2階建てに作り替えて地下室を追加する」とか「日本家屋を建てたあとで気に入らないから西洋風に改装する」とかやっていたらコストがかかって仕方ないはずです。内容の吟味は「設計」の段階で終わらせておくべきもので、「施工」をしてしまってからの修正は小規模なものに止めるのが当然です。
　最近ではワープロに限らず、Web方面では一般的なMarkDown記法やその他のテキストをハンドリングするための技術を用いて本を効率的に作ろうという試みをあちこちで目にしますが、これらも基本的には推敲や原稿整理の段階で用いるべきもので、それを組版作業の工程に融合させる方向性には抵抗感があります。そこを混ぜてしまうと結局現場に多大な負荷がかかるだけで終わるケースが多々あるからです。組版作業工程の効率化はもちろん模索していくべきと思っていますが、それは推敲や原稿整理とは分離して考えられるべきものと考えています。
　なお、「リフロー型電子書籍」の作成は、作成時に特定の版面を前提とした組版調整を行わない（行うことができない）という意味ではワープロ等の文書に性質が近いですが、支給されたテキストを流せば簡単に作れるというものでもないのでやはり「施工」にあたる工程でしょう。ただ、その元データとして「印刷用DTPデータ」が使われるのは明らかに非効率の源ですので、将来的にはそのあたりも含めて出版ワークフローの最適化がなされるとよいなと思っています。

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

　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ではアプリ形式で保存しようとするとエラーが出て保存できなかったりするため、スクリプトバンドル形式で保存してスクリプトメニューから実行）。

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