‘InDesign’ タグのついている投稿

組版ソフトとワープロは違うものですよという話

2022/08/19

 最近ある会議関連で組版ソフトとワープロ的なものの違いについての話が出たのですが、これは相当大事な話で、ここ20年近くの印刷組版データ制作現場の苦労の一因はここの混同にあるのではないかなと思ったのでちょっと書いておきます。

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

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

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

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

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

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

活版印刷の母型

活版印刷の母型


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

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

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

電算写植機

電算写植機


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

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

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

※1 TexやMC-B2などはそれに相当する。
※2 手動写植機は「版の保存」の機能を持っていなかったので、本の作成では主流にはなっていなかったと思われる。おそらく雑誌等ではテキスト中心の誌面作成にも使われていたものと思うが、制作に長期間を要する本の作成には向いていなかったのではないか。
※3 大昔のように感じられるかと思うが、本の作成では1980年代までは活版印刷が普通に残っていたはずで、1990年代になってもラインを残している会社はあった。
※4 正確には厳密な日本語組版処理を必要としない一部の出版社ではQuarkXpress等を使用した内製は行われていたものと思うが、電算写植機が持っていた組版機能や漢字の字形の再現がDTPでも可能になったのはInDesign日本語版や日本語OpenTypeフォントの登場以降のはず。

(2022.8.19)

InDesignの制御文字について調べてみた

2016/04/13

 InDesignはとても多様な機能を持ったDTP組版アプリケーションです。そして、その多様な機能をドキュメント内部で記録しておくために、当然さまざまな「制御文字」を使っています。この制御文字は、XML書き出しやEPUB書き出しなどをした際には意味を持たなくなるわけですが、これがそのままXMLに書き出されれば当然トラブルの種になりそうです。ということで、InDesignの制御文字についてちょっと調べてみました。なお、調査した環境はOS X 10.9/InDesign CS6です。

調査対象の文字

 今回調査の対象にしたのは、InDesign内コンテキストメニューの「特殊文字の挿入」「スペースの挿入」「分割文字の挿入」から選択して入力できる文字のうち、明らかに通常の記号に過ぎないものおよび、ページ番号など通常EPUBには書き出さないものを除いたもの(「特殊文字/記号」「特殊文字/マーカー」「特殊文字/引用符」項目を除去)、および、索引マーカー、脚注マーカーなどの各制御文字です。また、今回の基本資料として、こちらの英文記事を参考にしました。

 これをもとに機能名を日本語版InDesignでの表記に置き換え、またEPUB制作時にXMLでの書き出しを行うとどういった状態で出力されるのか、同じくコピー&ペーストで書き出した場合はどうなるかに関して調べました。結果が以下の表です(クリックでGoogleドキュメントの元データにジャンプ)。

column54_1

 特に注意が必要そうな箇所は赤で塗りつぶしてあります。XML書き出し時にはかなりの制御文字が削除もしくは置き換えられていることがわかります。また、改行などを見ればわかるように、同一のコードが複数の制御文字に割り当てられています。あくまで推測ですが、InDesign内で異体字を表示する際に親字のUnicodeひとつに対して複数の異体字をaalt等のサブ属性を割り振って管理しているのと同種の処理を行っているのではないかと思います。

XML書き出しで問題が出そうな文字

 さて、InDesignはXML書き出し時におおむね問題のない置換を行ってくれているようなのですが、いくつかちょっと問題のある処理があるようです。
ちょっと問題ありそうな箇所を列挙してみます。

・U+2011の分散禁止ハイフンが消えてしまう
・U+2003のEMスペースが通常の半角スペースに変わる(幅が狭すぎる)
・U+00A0の分散禁止スペース(ノーブレークスペース)がそのまま残る
・U+2006の1/6スペースがそのまま残る
・U+2005の1/4スペースがそのまま残る
・U+2004の1/3スペースがそのまま残る
・U+000Aの強制改行が通常の半角スペースに変わる
・U+200Bの任意の改行がそのまま残る

 「分散禁止ハイフン」が消えてしまうのはとても困った挙動で、これは欧文の前後の文字を行末改行させないという挙動以外は通常のハイフンと変わらない約物ですので、消えてもらっては困ります。せめて通常のハイフンに置換して欲しいところです。

 また、特殊幅スペース類に関しては、欧文フォントにはグリフの割り当てがあるようですので将来的にEPUBのほとんどのビューアで部分言語指定がきちんと反映されるようになってくればそのままでもよいかと思うのですが、現状では部分言語指定が効くビューアの方が少数で、また日本語フォントには該当コードポイントにグリフの割り当てがないようですので、現状まだ半角スペース等に変換した方が無難と考えます。

 それから改行コード類ですが、「強制改行」は通常、組版の最終段階で文章中の改行位置の微調整に使うものですので、これが半角スペースになるのは困ります。削除が正しい対処かと思います。あとは「任意の改行」ですが、これは主に欧文などで長い単語が行末に来た際などに改行を許す位置を指し示すためのものですので、こちらもEPUB化では削除するのが正しそうです。
 他には「索引の付加位置を示すマーカー」「脚注のマーカー」「アンカーオブジェクトのマーカー」「CID/GIDしかない文字のInDesign内部表示用キャラクタ(参考)」が消えてしまうのも問題で気になるところですが、これらについては目視確認して個別箇所の処理が必要になりますので、別枠とします。

XML書き出し前にInDesign内で置換処理を行う必要がある

 さて、対処なのですが、どうやらXML書き出しを行う前に、InDesign内で処置をする必要がありそうです。例えば強制改行などは半角スペースに置換されて書き出されてしまうため、XML書き出しを行った後では目視で潰すしかなくなってしまいます。ということでInDesign内でスクリプト処理を行うとすると、例えばAppleScriptを使って

 といった形で、検索置換パレットを使ったループ処理を行うことになります。多少時間がかかりますが、制御文字の性質上これは仕方ありません。

コピー&ペーストで問題の出そうな文字

 一方でInDesign内のテキストをそのままコピーし、テキストエディタにペーストした場合には、索引マーカー、脚注マーカー、アンカーオブジェクトマーカー、XMLタグマーカーなどを例外として、ほぼ全ての制御文字がそのままペーストされるようです。miにペーストした際にはU+2001のフラッシュスペースがU+2003のEMスペースに変換されるという挙動が見られたのですが、これはどうやらmiのみの問題のようで、テキストエディット等にペーストした際にはU+2001のままペーストされました。おそらくmiの内部でこのコードポイントを使用して何らかの処理をしており、それとバッティングするのを防ぐために変換されたものと思われます。

 そのままペーストされるということは制御文字が剥き出しになるということなので、これは置換、削除する必要が出てきます。処理内容としては

・U+00ADの任意ハイフン → 削除
・U+0008の右インデントタブ → 削除
・U+0007の「ここまでインデント」文字 → 削除
・U+0003の先頭文字スタイルの終了文字 → 削除
・U+200Cの結合なし → 削除
・U+2003のEMスペース → 全角スペースに
・U+00A0の分散禁止スペース → 半角スペースに
・U+202Fの分散禁止スペース(固定幅) → 半角スペースに
・U+200Aの極細スペース → 半角スペースに
・U+2006の1/6スペース → 半角スペースに
・U+2009の細いスペース → 半角スペースに
・U+2005の1/4スペース → 半角スペースに
・U+2004の1/3スペース → 半角スペースに
・U+2008の句読点等の間隔 → 半角スペースに
・U+2007の数字の間隔 → 半角スペースに
・U+2001のフラッシュスペース → 半角スペースに
・U+200B任意の改行 → 削除

 といったところでしょうか。強制改行が普通の改行と見分けられなくなってしまうのは問題ですが、これはテキストになってしまった後では目視で発見するしかありませんので自動処理はできません。あるいはコピー&ペーストする前に(テキストデータにする前に)InDesign内の検索置換で消しておくというような処置をすることになるでしょう。

(2016.4.13)

市川せうぞー師匠より関連情報をお知らせいただきましたのでリンクを貼っておきます。こちらはJavascriptで自動組版する際の制御文字の扱いに関する情報の模様。

(2016.4.14追記)

InDesign出力XML→XMDF変換スクリプト公開

2012/08/10

 「緊デジ」でリフロー型EPUB3の制作受け入れが決まりました。同時に出版社サイドからの制作会社指定が可能になり、PDF制作にも対応、申請点数の上限を年間発行点数の2倍までとした規定の廃止など、申請条件を大幅に変更した旨のお知らせが、緊デジサイトに掲載されています。EPUB3の制作ガイドラインの内容告知、EPUB制作会社の選定準備等は9月1日以降になるとのことで、XMDF・ドットブック形式の制作会社はすでに決定しはじめていると思われるものの、8月7日現在での申請数が未だ目標の6万点の半分にも届いていない状況を考えると「一度仕切り直し」感は否めません。

 ほとんど前例のないプロジェクトですので関係者の方を一方的に責める気にはなれないのですが、制作サイドの会社に所属している一人としては、ここまでスケジュールが遅れている現状でなお当初の予定通り3月末までに6万冊を揃えることが可能な見通しなのか不安があります。おおざっぱなものでも構いませんので、早い時期に今後の制作スケジュールの見通しを示していただくことを望みたく思います

 さて、私の所属している会社は結局XMDF・ドットブックの緊デジ制作会社には選ばれなかったのですが、制作に向けてXMDF変換スクリプトの準備は進めておりました。制作者としてこのまま無駄にするのも忍びない思いがありますので、会社の許可を得てこれを公開してしまうことにしました。以下よりダウンロードいただけます。

InDesign CS5 XML→XMDF変換スクリプト

(XMLファイルを「ID5XML2xmdf.bat」にドラッグ&ドロップすると置換されます)
(XMLファイルをテキストエディタ「mi」で開き、スクリプトを実行すると置換されます)

 なおこれは、私のブログに掲載されております「InDesign→EPUB3用XHTML作成ワークフロー」の手順に従ってタグ付け作業を行ったInDesignデータから書き出したXMLデータを、XMDF本文用のXMLデータに変換するためのスクリプトです。手順19までは共通の流れとなりますのでご了解ください。また、配布スクリプトをWindows環境でご使用いただくには、あらかじめActivePerlのインストールが必要になります。
 割り当てるタグの名称等は上記ワークフローのそれに準じます(つまり、同一のXMLソースからスクリプトの切り替えだけでEPUB用XHTMLとXMDF用XMLの双方の出力が可能です)。

XMDFビルダー側で必要になる作業

 本文をXMDF形式のXMLデータに変換した後、実際にXMDFコンテンツとして書き出すためにXMDFビルダー側で以下の作業が必要になります。なお、XMDFビルダー内での詳細な操作に関しましては、XMDF情報スクエアにてログイン後ダウンロード可能な説明書をご参照下さい。また、緊デジでの作業内容に関しましては、公式サイトのガイドライン等をご参照いただければ幸いです。

1 テキストをコピー&ペーストします

テキストをコピー&ペースト

テキストをコピー&ペースト

 変換済のXMLファイルをメモ帳等で開き、一番上の「<?xml version="1.0" encoding="UTF-8" standalone="yes"?>」の行を除いた全てのテキストを、XMDFビルダー「ワークスペース」内の「フロー」にコピー&ペーストします。また、画像・外字画像等を使用している場合は、「パーツマネージャー」からコンテンツ内に取り込んでおきます。

2 スタイルを設定します

スタイルを設定

スタイルを設定

 「文書構造スタイル」「文字スタイル」を設定します。書き出されたタグのうち、「<structure style="○○">」の「○○」が文書構造スタイル名(InDesignで言うところの段落スタイル名)に相当します。同じく「<font style="××">」の「××」が文字スタイル名です。
 XMDFビルダー内「基本構成」メニュー内「スタイル」にて設定できますので、適宜適切な値に設定します。各スタイル名をスクリプトが自動出力する値以外に設定したい場合は、あらかじめテキストエディタの一括置換機能などでXMLファイル内のスタイル名を置換した上で、XMDFビルダー側に置換後の名称を設定することで対応できます。
 なお、「コンテンツテンプレート」機能を用いて各種パラメータをインポート/エキスポートできますので、見出し/本文等のスタイル設定を保存しておくことは可能です。

3 画像の回り込みなどを設定します

画像の回り込み等を設定

画像の回り込み等を設定

 必要であれば画像の回り込み、表示方法などを設定します。

4 文書内リンク等を設定します

文書内リンクの設定

文書内リンクの設定

 文書内リンクは「<char_id char_id="■">※</char_id>」といった形で出力されますので、「■」を選択して「装飾編集」パレット「イベントID」からID番号を入力し、「基本構成」メニュー内「イベント編集」で移動先のページ等を設定します。なお、こちらの作業は手順として、一冊分全てのフローを設定した後で行った方が効率的と思われます。

5 外字の代替文字を入力します

 外字は「<external_char alt="〓" alt_img=”cid-0000.png” />」のような形で出力されますので、「〓」部分に適宜代替文字を入力します。代替文字を入力しなくても、外字画像が適切に設定されていれば通常表示に問題はありませんが、将来的な変換や読み上げ等の対応を考えた場合、入力しておいた方が何かと流用が効きやすいデータになるように思います。

InDesign内で外字ファイル名にルビを設定

InDesign内で外字ファイル名にルビを設定

 なお、外字にルビをかける場合は、InDesignドキュメント内にインラインで記述されている外字ファイル名(「InDesign→EPUB3用XHTML作成ワークフロー」手順3参照)にグループルビとしてルビを入力しておくことで、自動で変換出力されます。
 なお、EPUB3出力でも同様の外字ルビ処理に対応するため、そちらのスクリプトも改訂いたしました。適宜ダウンロードしていただければ幸いです。

 緊デジでの画像サイズの設定、ファイル名の規定等に関しましては、公式ガイドラインをご参照下さい。また、こちらのスクリプトを使用したことによるデータ破損等の損害に関しまして、私としては責任は負いかねますので、あくまで自己責任でご使用ください。

(2012.8.10)

Mac用置換スクリプトで「<p.indent>〜」等の記述が正常に変換されないケースがあった問題を修正しました。

(2012.9.6)

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。