2016/04/13
InDesignはとても多様な機能を持ったDTP組版アプリケーションです。そして、その多様な機能をドキュメント内部で記録しておくために、当然さまざまな「制御文字」を使っています。この制御文字は、XML書き出しやEPUB書き出しなどをした際には意味を持たなくなるわけですが、これがそのままXMLに書き出されれば当然トラブルの種になりそうです。ということで、InDesignの制御文字についてちょっと調べてみました。なお、調査した環境はOS X 10.9/InDesign CS6です。
調査対象の文字
今回調査の対象にしたのは、InDesign内コンテキストメニューの「特殊文字の挿入」「スペースの挿入」「分割文字の挿入」から選択して入力できる文字のうち、明らかに通常の記号に過ぎないものおよび、ページ番号など通常EPUBには書き出さないものを除いたもの（「特殊文字／記号」「特殊文字／マーカー」「特殊文字／引用符」項目を除去）、および、索引マーカー、脚注マーカーなどの各制御文字です。また、今回の基本資料として、こちらの英文記事を参考にしました。
これをもとに機能名を日本語版InDesignでの表記に置き換え、またEPUB制作時にXMLでの書き出しを行うとどういった状態で出力されるのか、同じくコピー＆ペーストで書き出した場合はどうなるかに関して調べました。結果が以下の表です（クリックでGoogleドキュメントの元データにジャンプ）。
特に注意が必要そうな箇所は赤で塗りつぶしてあります。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を使って
|
|
tell application "Adobe InDesign CS6" --置換元：置換先をネストしたリストで列挙 set replaceCharaList to {{"<0009>", ""}, {"<2011>", "<002d>"}, {"<2003>", "<3000>"}, {"<00A0>", "<0020>"}, {"<2006>", "<0020>"}, {"<2005>", "<0020>"}, {"<2004>", "<0020>"}, {"<000A>", ""}, {"<200b>", ""}} --置換元：置換先を1項目ずつ取り出して置換実行 repeat with myCharaSet in replaceCharaList set myFindChara to item 1 of myCharaSet set myReplaceChara to item 2 of myCharaSet --置換処理 set find what of find text preferences to myFindChara set change to of change text preferences to myReplaceChara change text document 1 end repeat end tell |
といった形で、検索置換パレットを使ったループ処理を行うことになります。多少時間がかかりますが、制御文字の性質上これは仕方ありません。
コピー＆ペーストで問題の出そうな文字
一方で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書き出し, 制御文字
カテゴリー: 未分類 | コメントはまだありません »
2016/03/24
グレープシティさん開催の「Xojo の基本から実践まで学べるセミナー」に行ってきました。
私が所属している会社ではこれまでEPUB制作用のツールをPerlにApplescript StudioでGUIを被せる形で作ってきたのですが、Applescript Studioを使うにはXcode3の環境の維持が必要で、XcodeはMac OSに強く紐付いたツールなので、OS Xの環境としては10.7の動作環境を維持する必要がありました。インストーラを加工して無理矢理10.9で動かす※1などの小細工でこれまでどうにか乗り切ってきたのですが、早晩マシンが壊れるなどすれば限界が来るのは見えていましたし、10.11ではXcode3のインストール時に相当深刻っぽいアラート画面が表示されたりもしましたので、代替環境として業界の先輩のものかのさんなどが使っていたXojoに目星をつけたわけです。
当日は専門の開発者向けに結構高度なセッションも行われていたのですが、私のように数ヵ月に1回ツールを作る程度の人間には正直ちんぶんかんぷんだったりもしましたので、ここでは私のような非専業でアプリも作る程度の使い方の人間にとって有用そうな情報に絞って紹介します。
Xojoで作れるもの／ライセンス価格
XojoはREALbasicの流れを汲むプログラム開発環境で、Windows、 Mac、 iOS、 Linux、 Raspberry Pi のアプリの他、Webアプリも作れるようです。何故かAndroidが無いのですが、中の人に聞いてみたらOSのメジャーバージョンアップでコロコロ仕様が変わるためとのこと。
ただ、各環境ごとにライセンスの購入は必要になります。料金表はこちら。Single Desktopあたりなら特に高くはないと思います。それ以外はある程度の期間開発に専念する境遇ならというところでしょうか。
Applescript Studioと比べてどこが良かったか
イベントハンドラにコードがぶら下がる
EPUB制作ツールをいくつかXojoに移植した程度ですのでそこまで深いことはもちろん言えませんが、まずユーザーインターフェース的に各ボタンのイベントハンドラに動作させるコードをぶら下げる作りになっており、コードの管理はしやすいです。Applescript Studioでは「on clicked theObject」の中でオブジェクト名を名称判別してサブルーチンに飛ばすみたいな処理を自分で書く必要がありました。中でやってることは同じなんでしょうが、管理しやすいのはよいことです。
それから、ほとんど英文ですがオンラインマニュアルが充実しており、使いたい機能名で検索すれば公式コードサンプルが大体すぐに出てきます。ユーザーコミュニティもそれなりに大きいようで、パワーユーザーによる新しめの情報にもアクセスしやすく、このあたりはもうとっくにレガシーなApplescript Studioとは雲泥の差がありました。
また、内部で正規表現が使えるのも大きいです。Applescriptは正規表現使えないんでテキスト置換とかで泣けるんですよね※2。
あとはOSベンダーの都合で仕様がガンガン変わったりしないことでしょうか。Appleは割とバッサリ下位互換を切るところがありますので。
移行で苦労したところ
Perlのコードを呼び出して使う
AppleScriptもPerlも、変数の型をあまり意識しないで使えるスクリプト言語でしたので、きっちり型定義しないといけないところにはちょっと苦労しました。あとオブジェクト指向言語なのでオブジェクトのNil判定周りでちょっとコケてTwitterで教えてもらったりしましたが、まあそれくらいで、結構あっさり移植できた印象があります。ネット上にサンプルコードが豊富にあるとやはり強いです。それと有償ツールなので当然ではあるのですが、いざという時に公式サポートから助言がもらえるのは何と言っても心強いところです。
今後どう使っていくか
何と言ってもマルチ環境対応が大きいです。ライセンス料のコストはかかりますが、直にJavascriptやPHPを書かなくても簡単なWebアプリのGUIならサクッと作れそうですので、例えば社内向けツールを簡単に作って社内サーバーで公開して使ってもらう、外部の協力会社や発注者向けに情報共有ツールを作って提供するなど、いろいろとやれることがありそうです。
また、PerlだけでなくAppleScriptも連携して動かせますので、InDesignなどを外部制御して動かすツールも作れます。まあその場合はもちろんMac専用になるわけですが。
◇
という感じで、弊社内でのツール開発目的での導入としては正解でした。今後ガンガン使っていきます。GUIがあるとないとでは使ってもらえる人の幅に大きな差が出ますので、結構こういうツールは重要です。Xojoはコードの書式がほぼVBに近いということですので、ExcelやAccessなどでVBAを動かしていた層のアップグレードとしても結構有用なんじゃないでしょうか。MSのアプリケーション環境にロックインされませんし、なんでもかんでもExcelマクロよりは明らかに筋は良いです。
※1 そのままインストールすると起動時にカーネルパニック画面が拝めます。
※2 AppleScript's text item delimitersでごにょごにょやるか、シェル経由でperlあたりに投げる必要があります。複雑な置換処理は外部シェル一択。
（2016.3.25）
タグ: Xojo
カテゴリー: 未分類 | コメントはまだありません »
2016/02/29
電書ラボのこちらのページにて、私も制作に協力した「電書ラボ制作仕様見出しテンプレート」が正式公開されました。
第一義的には「発注者が制作者に対して指示を入れるためのもの」
「電書ラボ制作仕様見出しテンプレート」は、リンク先の説明にもあるように、まず第一義的には発注者が見出しのスタイルを目視で確認しながら制作者に対して指示を入れるためのものとして作られたものです。
従来、紙の本の制作は、編集者がコンセプトや大まかなレイアウトを決め、それを製作者に伝達して製作を行うという形で進められてきました。ですが現状電子書籍の製作では、この形を引き継ぐことが必ずしもできてはいません。
これは現状のCSSの表現能力と紙のDTPのそれとの差といった側面もあるかとは思うのですが、発注者にとってわかりやすい指定方法が提供されてこなかったということにも一因があるのではないかと思っています。
「電書ラボ制作仕様見出しテンプレート」は、そういった点を踏まえ、発注者に必ずしもCSSについての知識がなくても意図したレイアウトの大まかな内容を製作者に伝達できるようにと考え、提供することとしたものです。
副次的には論理的なEPUBデータの作成を補助、促進
また、副次的には、より論理的（セマンティック）なEPUBデータの作成を補助、促進する意味もあるかと思っております。
ストアで販売されている電子書籍のソースコードを確認することはもちろんできませんので、はっきりとしたことはもちろんわからないのですが、現状おそらく相当数、以下のようなタグ付けが行われたリフローの電子書籍が存在しているのではないかと思われます。
<p><span class="bold"><span class="gfont"><span class="font-150per">見出しテキスト入る</span></span></span></p>
<p> 本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト</p>
見出しに当たる部分を本文と同じ<p>タグでコーディングし、<span>タグで多重に囲って装飾指定を入れれば、確かに見た目としては「見出し」にはなりますが、例えばストア側が中身の見出しタグのテキストを自動抽出してそれぞれの本の概要を簡易表示させようとしても、これではどの部分が見出しでどの部分が本文なのかを機械判別できません。結果としてこういった形でコーディングされた電子書籍は、概要がよくわからず、「買ってみないとわからない」状態になりそうです。
また、制作時の修正作業にしても、例えば見出し文字サイズを150％から140％にする必要が生じた場合に、見出しが100箇所あれば100箇所すべてを修正する必要が生じてしまいます。当然修正ミスも出るでしょう。
困ったことに上記のような状態でも「電書協ガイド準拠」に違いないため、相当数が出回っていそうです。
本来これは、以下のような形でコーディングをするべきです。
<h3 class="naka-midashi">見出しテキスト入る</h3>
<p> 本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト本文テキスト</p>
CSSファイルに以下のように指定
.hltr h3.naka-midashi {
font-weight: bold;
font-family: sans-serif-ja, sans-serif;
font-size: 150%;
}
この形であれば修正はごく簡単で、CSSのfont-sizeの値を修正すれば、見出しが何カ所あろうが全て一括で指定変更が反映されます。見出しをh3タグでコーディングしていますので、マシンリーダブルなデータにもなっています。
このあたりはWebの方から見ればごくごく初歩的な話かと思うのですが、紙印刷用のDTPのデータを元にした電子書籍の制作は、必ずしも論理性を考えずに作られたデータを、ごく短期間に「現物合わせ」で変換していく作業であるため、最初からデジタルネイティブで作られるデータほどきちんと論理的に作ることはそもそも現実的な理由で無理です。実際、電書協ガイドはそれを念頭に置いて作られたフォーマットだと思っています。
ただ、せめて見出しをhnタグでコーディングする程度の最低限の論理性は付加しておきませんと、後々の修正で制作者自身も大きな苦労を背負い込むことになるかとは思います。
「電書ラボ制作仕様見出しテンプレート」を用いることで、比較的現場に負荷をかけずにそれは実現可能かと思っており、ご活用いただければ幸いです。ご意見、ご要望などお待ちしております。
（2016.3.1）
カテゴリー: 未分類 | コメントはまだありません »
