とある制作会社の目次索引作成技法

とある制作会社の目次索引作成技法

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