とある制作会社の目次索引作成技法
18 likes•12,237 views
「目次」と「索引」は、日陰者の扱いを受けがちな付き物の中では異色の存在であり、デザイン性追求の労を厭わないことも多い。だが、「デザイン」という見た目に訴求しやすい要素に比して、その「コンテンツ」自体の制作手法については関心が低いのもまた事実であろう。「目次はDTPソフトが自動でやってくれるからコストフリー」「索引はゲラにマーカーをひいておけば、後はDTPオペレータが入れてくれる」……その幻想を、打ち砕く。 関連動画: http://youtu.be/5phOH4_BwZI http://youtu.be/-LmxyA7uaIc
![索引テキストファイル(4)
● 索引項目の読みは通常、辞書探索で解決
● 人名・地名、専門用語、文脈で読みが
分かれる文字（例：偽[ぎ/にせ]）等は、
3列目に読みを指定可能
– ノンブル TAB 索引項目 TAB 読み
– ノンブル TAB 親索引<<>>子索引 TAB
親読み<<>>子読み
16 平文 ひらぶん
✕ へいぶん、ひらふみ
◯ ひらぶん](https://image.slidesharecdn.com/index-toc-141006195242-conversion-gate01/85/-21-320.jpg)
とある制作会社の目次索引作成技法
- 1. とある制作会社の 目次索引作成技法 株式会社トップスタジオ 武藤 健志 @kmuto
- 2. 大扉 クレジット はじめに 本書について 目次 第1部 第1章 ： ： 付録 索引 著者について 奥付
- 4. お話の柱 ● 目次と索引 の過去・現在の 制作手法比較 ● 「正確性」と「即応性」の 両立の追求 ● より良い制作のための 相互理解と提案
- 5. 自己紹介 ● 武藤 健志 （MUTO Kenshi） @kmuto ● 株式会社トップスタジオ 執行役員 –編集 –自動組版設計・DTP – プログラミング – ネットワーク管理 – 福利厚生 – etc...
- 6. 索引作成手法 ● パターンA: ゲラにペンで マーカーを付けて、 後はお任せ ● パターンB: Excelファイル やテキストファイルで作る – B-1. とりあえず項目とページを 並べて、後はお任せ – B-2. 読みで整列済み。 そのまま貼り付けられる
- 7. 索引完成日数の変化 ● 昔よりも早くできあがってきている ような…とお感じになりませんか？ （おおむね1〜2日） ● かつては4〜7日かかっていた ● DTPソフトウェアに何か 劇的な発展があった？ ● はたまた当社の怠慢だった…!？
- 8. 当時の時間を分解してみると…… ●編集者がゲラにマーキング。2レベル索引のように 複雑なものは指示記入（1〜2日） ●DTPオペレータがマーカーの文字、読み、ノンブ ルを手作業でExcelに記入する （2〜3日） ●読みに基く並べ替えを手で行い、「ABC」「あい う」などの見出しを手で付けてDTPデータ化 ●編集者が内校で、索引文字や読み、整列順、参照 先ノンブルを注意深く目視確認する （1〜2日） ●修正漏れ箇所をDTPオペレータが反映し、 念のために編集者が再度、内校確認する
- 9. 問題点 ● 文責があるのは編集者なのに、DTPオペ レータが逐一、文字入力している ● 単語に読みをいちいち入れないと、 整列できない ● 並べ替え・ノンブル順序付け・見出しの 挿入といったほとんどが人力 ● 検証・照合手段が人力以外ない ● 再校→念校、あるいは改訂で、ノンブル が変わると追従作業に疲弊
- 10. DTPソフトが進化？ ● Adobe InDesign
- 11. InDesignの索引機能 ● 整列、見出し挿入、ページ追従 はしてくれるが……
- 12. InDesignのガッカリ索引機能 ● 読み入力必須 – 記入しないと ダイアログを閉じれない – ひらがな/カタカナは別扱い ● 入れた箇所がわかりにくい ● 完成紙面に後から入れると、行の文字 組みや折り返しが変わることがある
- 13. InDesignのガッカリ索引機能 ● 完成紙面に後から入れると、 行の文字組みや折り返しが変わる ことがある
- 14. InDesign索引機能の利用可能性 ● ハイパーリンク化されるのは魅力だが…… ● 追加、削除、変更のコストが高く、 工程終盤で利用するのは事故に即直結 ● 完璧に完成され、もう文言を 一切いじらないような原稿であれば…… ● 自動組版なら？ – InDesign索引をスクリプトで利用する上での 致命的かつ古典的なバグの存在 – 結局InDesign機能に頼らずに実装
- 15. 問題点（再掲） ● 文責があるのは編集者なのに、DTPオペ レータが逐一、文字入力している ● 単語に読みをいちいち入れないと、 整列できない ● 並べ替え・ノンブル順序付け・見出しの 挿入といったほとんどが人力 ● 検証・照合手段が人力以外ない ● 再校→念校、あるいは改訂で、ノンブル が変わると追従作業に疲弊
- 16. これが実現すれば素敵な世界が ● 文責がある人（編集者）が索引を 直接管理できる ● 読みは辞書から自動でひく （特殊なものは読みを指定できる） ● 並べ替え・ノンブル順序付け・ 見出し挿入 がすべて自動で処理される ● 機械的な検証・照合ができる ● ページの変化に簡単に追従できる
- 17. で、実現してみた ● 社内用Webアプリケーション 「索引ゲートウェイ」 – 名前がダサいのは……こまけぇことはいいんだよ！！
- 18. 索引テキストファイル(1) ●ノンブル TAB 索引項目 の列挙 – 1行あたり1ノンブル、1索引項目 – なるべくノンブル順に並べておくとよい 2 情報セキュリティ 2 機密性 2 完全性 2 可用性 3 可用性 3 セキュリティレベル ...
- 19. 索引テキストファイル(2) ●＃から始まる行はコメント扱いで無視される # 1章 2 情報セキュリティ 2 機密性 2 完全性 2 可用性 3 可用性 3 セキュリティレベル … # ２章 …
- 20. 索引テキストファイル(3) ● 2レベル、3レベル索引は <<>> で区切る – ノンブル TAB 親索引<<>>子索引 – ノンブル TAB 親索引<<>>子索引<<>>孫索引 情報セキュリティ............2 ポリシー................... 6 2 情報セキュリティ … 6 情報セキュリティ<<>>ポリシー …
- 21. 索引テキストファイル(4) ● 索引項目の読みは通常、辞書探索で解決 ● 人名・地名、専門用語、文脈で読みが 分かれる文字（例：偽[ぎ/にせ]）等は、 3列目に読みを指定可能 – ノンブル TAB 索引項目 TAB 読み – ノンブル TAB 親索引<<>>子索引 TAB 親読み<<>>子読み 16 平文 ひらぶん ✕ へいぶん、ひらふみ ◯ ひらぶん
- 22. 索引テキスト コメント行 # 1章ファイルの例 2 情報セキュリティ 2 機密性 2 完全性 2 可用性 3 可用性 3 セキュリティレベル 3 セキュリティホール 3 脆弱性 ... 6 情報セキュリティポリシー 6 情報セキュリティ<<>>ポリシー ... 10 クォータ 11 リードオンリーでマウント 11 マウント<<>>リードオンリー ... 13 侵入検知システム # 2章 16 暗号 16 平文 ひらぶん 16 シーザー暗号 17 アルゴリズム 17 鍵 17 暗号<<>>鍵 ノンブルと索引項目のペアをタブで区切る 2レベル索引 読みの明示指定
- 23. # 1章増減追従 2 情報セキュリティ 2 機密性 2 完全性 2 可用性 3 可用性 3 セキュリティレベル 3 セキュリティホール 3 脆弱性 ... 6 情報セキュリティポリシー 6 情報セキュリティ<<>>ポリシー ... 10 クォータ 11 リードオンリーでマウント 11 マウント<<>>リードオンリー ... 13 侵入検知システム # 2章 16 暗号 16 平文 ひらぶん 16 シーザー暗号 17 アルゴリズム 17 鍵 17 暗号<<>>鍵 改訂版で+10P分の 章が追加！アイェー！ # 1章 2 情報セキュリティ 2 機密性 2 完全性 2 可用性 3 可用性 3 セキュリティレベル 3 セキュリティホール ... 13 侵入検知システム # 新2章 16 CentOS 16 YUM 18 useraddコマンド 18 passwdコマンド 19 ifupコマンド … 23 netstatコマンド # 新3章（旧2章） 26 暗号 26 平文 ひらぶん 26 シーザー暗号 27 アルゴリズム 27 鍵 27 暗号<<>>鍵 新しい索引を挿入 以降のノンブル値を +10Pするだけで追従完了
- 24. デモ Episode I
- 25. 索引テキストファイルの作成 ● テキストエディタ？ ● Excel？ # 1章 2 情報セキュリティ 2 機密性 2 完全性 2 可用性 3 可用性 3 セキュリティレベル 3 セキュリティホール 3 脆弱性 6 情報セキュリティポリシー 6 情報セキュリティ<<>>ポリシー ...
- 27. デモ Episode II
- 28. 索引ゲートウェイ構成図 Ruby プログラム Web サーバー Ruby プログラム IPA辞書追加辞書 MeCab (形態素解析) mendex (索引整列) テキストエディタ, Acrobat 索引 テキスト ファイル pdftk, pdftotext, grep 分割 テキストPDF 貼り付け用 索引 XML索引 読み対照表 PDF照合 OSSを組み合わせ、 Rubyプログラムで統合する
- 29. 今後の索引制作 ● 索引はDTPデータとは別にテキストで持 ち、できるだけ編集者が一元管理する ● テキストエディタやExcelのほか、 Acrobatでも作成できる ● 過去の制作物も、DTPデータ（inddま たはqxd）があれば ほぼ逆方向変換で作成できる – PDFだけだと、いろいろ厄介なことが…
- 30. 目次作成手法 ● 本文の見出しから、ちょちょっと ひっぱってくるだけ なんじゃないの？
- 31. InDesignの目次機能 ● InDesignの目次機能で「ラフな」 目次を作成 ● 「段落スタイル」に基いて設定
- 32. Danger! It's a TRAP! ● InDesign目次機能では罠が多い ● InDesignにとっては 「文書構造？ 知らんがな」
- 33. TRAP 1 ● イレギュラーな見出し段落スタイルの 指定忘れ – 「2行用スタイル」 – 「2桁番号用スタイル」 – 「付録スタイル」 – 「上アキ違いスタイル」... ● 当然、忘れたものは目次から欠落 ● 採番されていない見出しは特に 見落としやすい
- 34. TRAP 2 ● デザイン性のある見出しは、目次作成 に不幸を招く ● インラインフレームの見出し – 「節」をインラインフレームで作り、「項」を 普通の段落スタイルで作ると、同じページの場合 1.1→1.2→1.1.1→1.1.2 という並びになる1.1 情報セキュリティとは インラインフレーム 企業が持つ資産には「人（人材）」... 1.1.1 情報セキュリティの三大要素 インラインフレーム
- 35. TRAP 3 ● 生成される目次は素朴 – 目次の段落スタイルや文字スタイルの表現で なんとかするには限界が… ● 手でいじった箇所は、 目次を更新すると消失する – 凝った目次を作ると 再作成のコストが高すぎる – 人間が手で同期作業
- 36. 目次制作の現状 ●DTPオペレータが、InDesignの 目次機能でラフを作成 ●装飾等を実施、校作成 ●編集者がゲラで校正。見出し抜けや 順序違い確認、ノンブル先の照合 ●DTPオペレータがDTPデータを 「単なる文字として」修正 – 目次を1から再作成するのはレアケース
- 37. 目次のミス予防策 ● プログラムによるチェック→ デザインが不定なので困難 ● 目次をテキスト化して、 索引ゲートウェイで確認？ – 目次の文字の誤りや、 ノンブル間違いを発見できる ● 今のところ、 “1つずつ目視確認”に優るものなし (´・ω・｀)ｼｮﾎﾞｰﾝ
- 38. （補足）XML自動組版での目次 ● XML自動組版では、段落スタイルから ではなく、XMLに埋め込んだ目次情報 を収集して目次を生成 – インラインフレームなどに左右されない ● デザイン等もXML側で整形し、組み直し容易
- 39. まとめ ● 目次、索引ともに、ゲラには表れない 泥臭い舞台裏がある ● 100%機械に委ねることは今後もない が、目視と人力のみに頼る作業を減らし ていくことが、正確性と即応性の向上に つながる ● 索引の作成手法は確立しつつある。索引 テキスト書式の採用により、索引の作 成・更新・照合・管理に改善を見込める