作成者別アーカイブ: taishii

PDFをOfficeファイルに高精度変換!!  『瞬簡PDF 変換 7』 新発売

アンテナハウスでは、PDFをWordやExcelに変換して再編集可能にするソフト『瞬簡PDF 変換 7』を10月14日に販売開始しました。

先行してダウンロード版を発売し、パッケージ版は10月21日から出荷を開始していますので、このブログが掲載される頃には店頭で新しいパッケージを見ることができるかも知れません。

リッチテキストの名前が消えた!?

これまで弊社の『リッチテキストPDF』シリーズをお使いいただいていたユーザー様は、今回の製品名をみて「あれ!?」と思われたかも知れません。そうです、今回より製品名から『リッチテキスト』の文字が消えてしまいました。

『リッチテキストPDF』シリーズは2005年の6月に最初のバージョンを発売しまして、これまで何度も改良を重ねて参りました。PDFからOffice文書に変換するソフトウェアとしては、けっこう老舗の部類に入ると思います。
また、最初のバージョンは日経誌の記事”PDFをWordファイルに見事に変換「リッチテキストPDF」“にも取り上げられて、ここでお褒めをいただいたことや、ご指摘を受けたことなどが、以後の開発に随分と励みになったものです。

そのような、歴史?のある「リッチテキスト」の名称を今回使用しなかったのは、「瞬簡PDF」シリーズへの統合をより明確にするためでした。

『瞬簡PDF 変換』という命名には、ビジネスや日常で欠かせないものになってきたPDFの活用をサポートするツールとして、アンテナハウスがどのような製品を提供し、それで何ができるかを、分かりやすく明快にお客様にお伝えしたいとの思いを込めています。

「瞬簡」は、「瞬時」に「簡単」からなる造語です。「瞬簡PDF」という名称を共通に冠した弊社製品群が、この名に恥じないように、お客様のPDFご活用の一助となれば幸いに存じます。

今回の新製品では、今ご覧いただいているブログの右側を見ていただくとお分かりいただけますように、「瞬簡PDF 作成」と「瞬簡PDF 変換」のパッケージもこれまでと違って、幅の広い存在感のあるものにリニューアルしました。さらに、企業・官庁様向けに”超”お得な価格設定を新規に導入するなど、全体に力の入ったものとなっています。

さて、外側の話しはこれくらいにして、明日からは、内部でどのような改善を行ったかにつきまして、ご説明していきたいと思います。次回も是非お読みください。


CAS-UBのセミナー各種

昨日は、アンテナハウスのクラウド型汎用書籍編集・制作サービス「CAS-UB」を使うと、同じ原稿から、EPUB版、PDF版の電子書籍を同時並行で製作できることを紹介しました。また、PDFで入稿して印刷・製本することで、電子書籍と印刷の両方に対応した出版ができることを紹介し、この出版形態をアンテナハウスでは、「ハイブリッド出版」と呼んでいることも紹介しました。
 今日は、CAS-UBのセミナーについてお知らせします。
 まずは、まもなく、2011年10月26日(水)に開催する第3回CAS-UB紹介セミナー。
 これは、CAS-UBの実演をして、CAS-UBがどんなものか、出版の未来がどう変わっていくかを紹介するものです。現在、開発中の最もホットなCAS-UBを知ることができます。
 もちろん、参加は無料です。
 参加、ご希望の方は、
CAS-UB お知らせ
にある、「第3回CAS-UB紹介セミナー開催」を、ご覧ください。
 次は、実際にCAS-UBを使いながら、本を作る体験学習ができるハンズオン形式のトレーニングセミナー。
 これは、無料で、毎週、開催しています。
 詳しくは、
CAS-UB トレーニング・セミナー
を、ご覧の上、お申し込みください。
 定員が、毎回5名と少数なので、すぐ埋まってしまいます。お申し込みは、お早めにお願いします。
 先週、2011年10月12日から16日まで、ドイツのフランクフルトで行なわれたヨーロッパ最大の、本と出版に関する展示会「フランクフルト ブックフェア」に、ドイツのリセラーさんの協力でCAS-UBを出展しました。
 そのときの模様は、残念ながらまだ報告が上がってきてないのですが、CAS-UBは、今後も、日本国内、海外を問わず、積極的に展示会やセミナーで紹介していきます。
 ぜひ、一度、展示会のブースやセミナーで、CAS-UBを実際にご覧になり、説明を受けてください。
 クラウド型汎用書籍編集・制作サービス「CAS-UB」について詳しいことは、
アンテナハウスEPUB情報ページ

CAS-UBのPRサイト
をご覧ください。


CAS-UBで本のEPUB版, PDF版を同時に作る

 アンテナハウスのクラウド型汎用書籍編集・制作サービス「CAS-UB」については、以前、このブログでも紹介しました。
 たとえば、
クラウド型汎用書籍編集・制作サービス CAS-UBを発表
にあります。
 このときCAS-UBは、まだ、実験的なサービスでしたが、9月1日から正式なサービスになりました。この間、多くの方から改良点のお寄せいただき、開発チーム一同、大変に感謝しております。
 いまのCAS-UBは、上記で紹介したときからは、ずいぶん変貌を遂げています。
 現在の画面を出しても、また、すぐに変わってしまうので、出しません。
 というのは、まだまだお客様からの要望がいくつもあり、日々、開発と改良が続いているからです。
 そこで今回は、CAS-UBのマニュアルについて紹介します。
 CAS-UBのマニュアルは、なんと、開発の初期の段階から、CAS-UB自体で執筆し、製作しています。
 CAS-UBを使うと、同じ原稿から、簡単に、EPUB版とPDF版の本を作ることができます。つまり、EPUB版とPDF版を同時並行で製作できるのです。さらに、PDFで入稿して印刷することで、紙の本も作れます。
 電子書籍と印刷の両方に対応した、この出版形態をアンテナハウスでは、「ハイブリッド出版」と呼んでいます。
 CAS-UBのマニュアルもそうやって、EPUB版とPDF版を作っています。
 CAS-UB 関連資料集にある「CAS-UB マニュアル」をご覧ください。
 そこに、スタートアップ・ガイド、チュートリアル、ユーザー・ガイドのそれぞれについて、EPUB版、PDF版があります。自由にダウンロードできますので、ぜひ、ダウンロードして、中身をご覧ください。
スタートアップ・ガイド
CAS-UB「ユーザー登録から退会処理まで」(EPUB形式)
CAS-UB「ユーザー登録から退会処理まで」(PDF形式)
チュートリアル
CAS-UBチュートリアル(EPUB形式)
CAS-UBチュートリアル(PDF形式)
ユーザー・ガイド
CAS-UBユーザー・ガイド(EPUB形式)
CAS-UBユーザー・ガイド(PDF形式)
 開発チームとして注目していただきたい点は多々ありますが、やはり、目次、注釈一覧、図表一覧、索引といったものが、自動的に作られていることです。
 日本の本、特に新書では、索引がないものが多く、読者からは、編集者、著者の怠慢と指摘されています。CAS-UBを使えば、このように簡単に索引が作れるのです。ぜひ、活用していただきたいと思います。
 もう1つ、注目していただきたいのは、テーマによって、がらりと違う雰囲気のEPUBが作れることです。
 CAS-UB 関連資料集にある「CAS-UBで作成したPDFとEPUB」をご覧ください。
 次の2つは、同じ原稿から、テーマを切り替えることで、見栄えだけを変えて作ったものです。印象が全然違うことがおわかりいただけると思います。CAS-UBでは、これが、簡単にできるのです。
CAS-UBで作成したEPUBのサンプル(1)テーマ:オルディーズ(EPUB)
CAS-UBで作成したEPUBのサンプル(2)テーマ:グリーン(EPUB)
 なお、Adobe Digital Editionsでは、「テーマ:オルディーズ」が正しく表示されません。Firefoxのアドオン、
EPUBReader
で、ご覧ください。
 同じ原稿から作ったPDF版と見比べるのも、面白いかもしれません。
CAS-UBで作成したPDFのサンプル(PDF)
 クラウド型汎用書籍編集・制作サービス「CAS-UB」について詳しいことは、
アンテナハウスEPUB情報ページ

CAS-UBのPRサイト
をご覧ください。


PDFからのテキスト抽出で困っていること

 昨日は、TextPorterがさまざまなソフトのファイルからテキストを抜き出してくるソフトであること。一般の人の目に触れないところで、実は、数多く採用され、活躍していることをお話しました。
 そのTextPorterを使ったPDFからのテキスト抽出で、最近、困ったことが起きています。
 1つ目は、壊れたPDFが氾濫していることです。
 PDFは、Adobe社が独自に開発したものですが、仕様はすでに、
PDF Reference and Adobe Extensions to the PDF Specification
として、公開されています。また、ISO 32000という国際規格にもなっています。
 規格に沿ったPDFであれば、TextPorterは困らないのですが、世の中には、規格を逸脱したPDFがたくさんあります。
 お客様から、このPDFからテキストが抽出できないという問い合わせがあり、調べてみると、規格に準拠してない、壊れたPDFであることがほとんどです。
 それらは、オープンソースのPDFライブラリや自作の独自ライブラリを用いて作られたものが多いようです。そのPDFライブラリのバグなのか、そのPDFライブラリを使うプログラマのレベルが低くて、バグを入れてしまっているのかは、定かではありません。とにかく、壊れた汚いPDFがあちこちで流通してしまっているのが現状です。
 中には、Adobe Readerでも表示できなかったり、Adobe Readerがハングアップしてしまうものまであります。
 TextPorterは、なるべくテキストを抽出しようとがんばってはいますが、自ずと限界はあり、壊れ方がひどいと、どうしようもありません。
 出来の悪いプログラマが作るPDFには勝てません。どうか、プログラマのみなさん、仕様書を読んで、まともなPDFを作ってくださいと願うばかりです。
 2つ目は、画像ばかりのPDFからは、テキストが抽出できないということです。
 お客様から、このPDFからテキスト抽出ができないと送られてきたPDFが、実は、テキストは1文字も入っておらず、全ページが画像のPDF。つまり、スキャナで紙の書類を画像として取り込んでPDFにしたものだったというケースが増えています。
 技術知識のない一般のお客様の場合、Adobe Readerで見て文字が読めるのだから、テキストが抽出できると思ってしまわれるようですが、そうなりません。実は、TextPorterは、画像認識をしてまでテキストを抽出しようとはしていないのです。
 これには理由があって、画像認識までして文字列を抽出しようとすると、処理スピードの低下など、あれこれ弊害が出てしまうからです。TextPorterは日夜、膨大な数のファイルからテキスト抽出をする用途に使われているので、処理スピードの低下は、大きな問題になるのです。
 ハードウェアの性能がもっと向上すれば、挑戦すべきテーマとは思いますが、現在のところ、そこまでやることは控えています。
 画像ばかりのPDFからは、テキスト抽出はできない。これを覚えておいていただきたいと思います。
 TextPorterについての詳しい説明は、
TextPorter
をご覧ください。
 TextPorterをはじめ、アンテナハウスのシステム製品につきましては、事前に技術相談会を行っております。お気軽にお問い合わせください。
 詳しくは、
システム製品技術相談会
をご覧の上、お申し込みください。


サーバ組込用テキスト抽出エンジンTextPorter

 TextPorterは、クラウドコンピューティング時代のサーバ組込用テキスト抽出エンジンです。
 何ができるかを一言でいうと、Word, Excel, PDFなど色々なアプリケーションのファイルから文字列を抜き出してくるソフトです。
 「ファイルから文字列を抜き出してくるだけなのに、そんなに大変なことなの?」と思われるかもしれませんが、世の中には、実に数多くの種類のファイルがあり、そこから文字列を抜き出すだけでも、けっこう大変な仕事です。
 ファイルの解析から始め、テキスト部分がどこかを探り当て、それを抽出するプログラムを書いて、いろんなケースをテストして製品の完成度を高めないといけません。
 TextPorterが対応しているファイル形式の一覧「抽出対象ファイル形式」をご覧いただくとおわかりのように、これだけのファイルに対応するのは、一朝一夕ではできません。アンテナハウスが長年にわたって開発を続け、蓄積してきた成果なのです。
 「大変なのはわかった。でも、テキストが抽出できると何がうれしいの?」と思われるかもしれませんが、この技術は、検索エンジン、ウィルス対策ソフト、ドキュメント管理システムなど、さまざまな用途に使うことができるのです。
 システム開発をする人が、サーバに組み込んで使うソフトなので、直接、一般の人たちの目には触れませんが、縁の下の力持ちとして、大いに役立っているソフトなのです。
 採用事例は数多くあり、世界的なソフトウェアやサービスにも組み込まれていますが、契約の関係上、採用事例をご紹介できるのは、次の事例です。

採用事例(ケーススタディ)

のあるように、エヌ・ティ・ティ アイティ株式会社(NTT-IT)様InfoBeeにご採用いただいております。
 ほかにも、
スマートフォンでの活用 互換性 Server Based Converter
にあるような活用法も考えられます。
 TextPorterについての詳しい説明は、
TextPorter
をご覧ください。
 TextPorterをはじめ、アンテナハウスのシステム製品につきましては、事前に技術相談会を行っております。お気軽にお問い合わせください。
 詳しくは、
システム製品技術相談会
をご覧の上、お申し込みください。
 最近、PDFからテキスト抽出をするときに困っていることが起きているので、明日は、それについて書いてみます。


AH Formatterの強い味方「XSL Report Designer」

 アンテナハウスのAH Formatterは、世界各国で使われ、高い評価を得ています。最近では、「米国国税庁でAH Formatter 案件が進む」にあるように、アメリカの国税庁(IRS)でも採用されました。
 このように大変優秀なソフトですが、レイアウトを決めるには、XSL-FOとXSLTの知識と経験が必要です。
 習得すると、思い通りのレイアウトができますが、習得には時間がかかります。
 そこで、登場するのが、「XSL Report Designer」です。
 XSL Report Desingerを使うと、GUIの画面で、簡単に帳票のレイアウトを設計できます。
 設計したレイアウトとXMLのデータを組み合わせて、XSL-FOを生成して、AH FormatterでPDFにしたり、印刷したりできるようになるのです。
 どういうレポートが設計できるかは、
XSL Report Designer レポート設計サンプル

をご覧ください。
 AH Formatterを活用するソフトとして、XSL Report Designerは、海外でもご好評をいただいています。
 以前、通貨の出力を、ヨーロッパで使う形式、つまり、小数点を「,」、3桁の区切りを空白にできるかという質問がありました。
 たとえば、「1,234.56」ではなく、「1 234,56」で出力したいという要望です。
 XSL Report Designerは、国際化対応をしていますので、この要望にもお応えすることができました。
 XSL Report Designerについての詳しい説明は、
XSL Report Desinger
をご覧ください。


DITA超入門 ― まとめ

こんにちは。DITAの話は今日でいったんおしまいにします。
昨日までの4日間で漏れてしまった話題について、軽く紹介しておきます。
■conref
昨日、条件処理を使ってコンテンツの一部を出したり出さなかったりをする方法を紹介しましたが、conrefは他のトピックの中のほんの一部を流用する機能です(フラグメント単位での再利用)。
製品名とかコピーライト表記をひとつのトピックファイルにまとめておいて、それを参照したりするような使い方をします。
■関連テーブル
どのトピックとどのトピックが関連し合っているのかを、それぞれのトピックの中ではなくマップの中に記述することができます。
トピックの中に関連情報を書くこともできますが、そうするとトピック間の関連関係が変更されたとき、トピックをこつこつと変更しなくてはなりません。それはそれで大変なので、マップに追いやってしまおうというわけですね。こうすることでマップだけを修正すればいいことになります。
■keyref
これは参照先をマップで解決しようという機能です。言葉で説明するのは難しいのですが、図式化すると次のようになります。

トピックの中には具体的な参照先は書かないで、マップに書いてしまおうということですね。
この機能は最新のDITA1.2仕様で追加された機能です。一度書いたトピックはできるだけ変更しなくてもいいようにしよう、可変データは可能な限りマップに追いやってしまおう、というDITAの設計思想が感じられます。
■DITA Open Tookit
せっかくマップやトピックが用意できたのに、これをどうやってHTMLやPDFにすればいいんだろう、という疑問がありますよね。大丈夫です。マップやトピックを処理して最終成果物を作ってくれる「DITA Open Tookit」という処理系がすでにあります。オープンソースで誰でも無償で使うことができます。入手先は下記です。
http://sourceforge.net/projects/dita-ot/
Open Toolkitは
  * トピックファイルや画像などの素材を集める
  * 条件処理を解決する
  * conrefやkeyrefを解決する
  * PDFやHTMLを作る
といったことを自動的にやってくれます。
■期待するレイアウトを実現するには
Open Toolkitを使えばPDFを作ることはできるのですが、あくまでもサンプル程度です。
これを期待したレイアウトにするにはそれなりのカスタマイズが必要になります。具体的にはPDF生成用のXSLTスタイルシートを作らないといけないのですが、弊社ではこのスタイルシート作成を請け負っていますので、ぜひご相談ください。
また、Open Toolkitには標準で自動組版エンジンが付いてくるのですが、正直な話、機能的にいまいちです。特にまじめに日本語組版をしたいということであれば、Antenna House Formatterが必須になります。
■お問い合わせ
DITA導入についてのお問い合わせをお待ちしております。
営業担当:小林(guten@antenna.co.jp)までよろしくお願いいたします。
では、5日間ありがとうございました。
最後に関連情報のリンクを少しだけ
OASIS DITA仕様(英語サイト)
DITA News(英語サイト)
DITAコンソーシアムジャパン(日本語サイト)
アンテナハウスDITAサービス(日本語サイト)


DITA超入門 ― 特殊化ってなに?

こんにちは。今週のDITA超入門も、残すところ、あと1回です。
今回は特殊化の話題です。
「DITA」の最初の「D」は(進化論の)ダーウィンの頭文字から来ていますが、ずばり、特殊化という機能があるがゆえにダーウィンの登場というわけです。
昨日までに紹介した機能は、名称や形こそ違え、似たようなことは昔から行われてきました。しかし特殊化という機能はおそらくDITAが最初ではないでしょうか。
■特殊化
特殊化とは既存の情報タイプ(トピックタイプ)を自分が好きなように拡張することです。たとえばdocbookでドキュメントを記述するとき、docbookの仕様の中で定義されている要素をそのまま使うしかありませんが、DITAの場合、都合のいいように要素を定義し直してもいいよ、と。もちろんある程度の制限というか作法のようなものは守らなければいけませんが。
生物は環境に適したものが生き延びる、というのが進化論の教えるところですが、情報タイプもあなたの環境に応じたものを用意していいですよ、というわけです。
次のような手順を出力したい、としましょう。

1. 電源スイッチを押す
2. [ラジオ]ボタンを押す
3. チューニングレバーを回す

もっとも初歩的な解決方法は次のようなトピックを用意することです。
<topic>
  <title>ラジオの聴き方</title>
  <body>
    <ol>
      <li>電源スイッチを押す</li>
      <li>[ラジオ]ボタンを押す</li>
      <li>チューニングレバーを回す</li>
    </ol>
  </body>
</topic>
もちろんこれでも期待する結果は得られますが、では次のような例はどうでしょうか。
<task>
  <title>ラジオの聴き方</title>
  <taskbody>
    <steps>
      <step><cmd>電源スイッチを押す</cmd></step>
      <step><cmd>[ラジオ]ボタンを押す</cmd></step>
      <step><cmd>チューニングレバーを回す</cmd></step>
    </steps>
  </taskbody>
</task>
前者は番号付き箇条書きであることは分かりますが、どういった意味の箇条書きであるのかまでは分かりません。それに対して後者の場合、単なる箇条書きではなく、何かの「手順」であるということがはっきりと分かります。どちらの方が情報の質が上かと言えばもちろん後者ですよね。
このように、それまでは<ol>を使うしかなかった状況から、(情報の質を高めるために)<steps>を使える状況に拡張することが特殊化です。
あ、これは<ol>に限ったことではなく、別の要素だって特殊化の対象になりえます。
■情報タイプ(トピックタイプ)
DITAにはすでに下記の情報タイプ(トピックタイプ)が用意されています。
【汎用topic情報タイプ】
DITAの出発点となる情報タイプで、HTMLライクな要素が定義されています。この情報タイプを使えばだいたいどのようなマニュアルも記述できますが、先ほど述べたように情報の質という点では劣ります。
昨日までにいくつかのトピックサンプルを例示しましたが、すべてこの情報タイプで記述したものです。
【task情報タイプ】
操作手順を記述するのに特化した情報タイプです。どのような順番でどういう操作をすればどのような結果が得られるか、というようなことを記述しやすいようになっています。
この情報タイプは上記の汎用topic情報タイプから派生させた(特殊化した)ものです。
【concept情報タイプ】
「それは何か」に対する答えを記述するのに便利な情報タイプです。たとえば「製品の特徴」であるとか「ご使用の前に」とか…etc。上記のtask情報タイプでは記述できないコンテンツは大抵この情報タイプを使うことになるでしょう。
この情報タイプは上記の汎用topic情報タイプから派生させた(特殊化した)ものです。
【reference情報タイプ】
リファレンスマニュアルを記述するのに特化した情報タイプです。
この情報タイプは上記の汎用topic情報タイプから派生させた(特殊化した)ものです。
【glossary情報タイプ】
用語集を記述するのに特化した情報タイプです。
この情報タイプは上記のconcept情報タイプから派生させた(特殊化した)ものです。
おおよそこれらのすでに用意された情報タイプで事足りると思いますが、中にはそれでも不十分だということもあるでしょう。そのときは(上記の情報タイプから派生させる形で)自分で特殊化することになります。
今日の話を図式化すると次のようになります。

なんだか、いかにもダーウィンって感じですね。
特殊化については(それだけで数十ページ書けそうな話題なので)これ以上突っ込んだ話は他の参考書に任せますが、日本語の参考書としては
DITA 101
DITA概説書
があります。
では、また明日。


DITA超入門 ― フィルタリング トピックを効率的につくる!

こんにちは。昨日に引き続きDITAのお話です。
昨日は(複数の)トピックとマップを使ってマニュアルを作るという話でした。この仕組みによってトピック単位でのデータ再利用が実現されるわけです。
ここで、ある製品Aと別の製品Bとで充電の方法が「ほんの少しだけ」異なる場合を考えてみましょう。昨日の話の範疇で考えると「充電の方法-A用.dita」と「充電の方法-B用.dita」のふたつを用意して、マップの中から必要な方のトピックを参照すれば無事解決です。もちろんこの方法で間違っていません。
ただ、「ほんの少しだけ」違うだけなのにトピックを丸ごとふたつに分けるのもなんだかな~、と思いますよね。
そこで条件処理(コンディショナルプロセシング)の出番です。
■条件処理(コンディショナルプロセシング)
条件処理には、大きく2つの機能があります(フィルタリングとフラッギング)。今日は、そのうちのひとつ、「フィルタリング」を紹介します。
●フィルタリング
ひとつのトピックファイルの中に複数の製品の情報を混在して書いておいて、マニュアル生成時にその時の条件によって、特定の情報を出力したり、出力しなかったり、をコントロールすることをフィルタリングといいます。具体例をあげましょう。
<topic id=”HowToCharge”>
  <title>充電の方法</title>
  <body>
    :
    :
    <p product=”上位モデル”>
      充電が完了するのに「30分」程度かかります
    </p>
    <p product=”下位モデル”>
      充電が完了するのに「60分」程度かかります
    </p>
    <p>
      充電中は電源を入れないでください
    </p>
    :
  <body>
</topic>
ここには上位モデル用の充電時間と下位モデル用の充電時間が混在して書かれています。このまま何も考えずに処理すると両方ともマニュアル内に出力されてしまいます。
そこで、もうひとつ、ditavalファイルというものを用意します。上位モデル用の出力を得たい場合は次のような内容にしておきます。
<val>
  <prop att=”product” val=”上位モデル” action=”include” />
  <prop att=”product” val=”下位モデル” action=”exclude” />
</val>
ここでは、
 * product属性が「上位モデル」のコンテンツは出力してください
 * product属性が「下位モデル」のコンテンツは出力しないでください
 * その他は出力してください
ということを意味しています。
そしてマニュアルを作る時に、このditavalファイルを使ってくださいね、と宣言すると次のような出力が得られるわけです。

 充電が完了するのに「30分」程度かかります
 充電中は電源を入れないでください

見事に下位モデル用の記述が抜け落ちていますね。
こうすることで、「ほんの少しだけ」違うトピックを複数個作る必要がなくなるわけです。
この機能をうまく使えば、ひとつのトピックの中に「Windows向けとLinux向けの記述」であるとか「上級者向けと入門者向けの記述」であるとかを混在して書いてもいいことになりますね。
では、また明日。


DITA超入門 ― トピックとマップ 避けては通れないはじめの一歩

こんにちは。昨日に引き続きDITAのお話です。今日は、DITAの初めの一歩として避けては通れないトピックとマップについて触れてみます。
DITAではひとつのドキュメントを作るにあたり、(複数の)トピックと(ひとつの)マップを組み合わせて使います。
■トピック
トピックにはドキュメントのコンテンツを記述します。たとえば次のようになります。
<topic id=”GoalOfDITA>
 <title>DITAのめざすもの</title>
 <body>
  <p>DITAの目的は次のとおりです</p>
  <ul>
    <li>データ再利用性の向上</li>
    <li>ワンソースマルチユース</li>
    <li>翻訳の効率化

  </ul>
 </body>
</topic>
なんだかどこかで見たことあるような..ないような…
そう、雰囲気的にはHTMLにそっくりです。とりあえずここまではあまりハードルは高くなさそうですね。
ひとつのトピックファイルにはひとつのトピック(話題)しか書かない、ということが推奨されています。ひとつのトピックファイルの中でだらだらといくつもの話題に触れるのはよしましょう、ということですね。そのため、ひとつのドキュメントを制作するにあたり必然的に複数のトピックファイルを用意することになります。
■マップ
上記の(複数の)トピックファイルをひとつにまとめることがマップの役割です。マップを使ってトピックの出力順やトピック間の階層構造を決めることになります。たとえば次のようになります。
<map title=”取扱説明書”>
  <topicref href=”はじめに.dita” />
  <topicref href=”電源の入れ方.dita” />
  <topicref href=”ラジオの聴き方.dita” />
   :
   :
</map>
この例は超基本的な例です。この他にさまざまな機能が用意されています。個人的にはマップを制することがDITAを成功へ導く秘訣だと感じていますが、ま、最初の一歩としては上記で十分でしょう。
マップとトピックの関係を図式化すると次のようになります。

この図を見て分かるように、マニュアルの種類だけマップを作り、それぞれのマップから1セットのトピックファイル(群)を共有参照する、というのがDITAの基本的な考え方です。
■トピック指向の執筆
ワードやdocbookでマニュアルを書くときは、1つのファイルに1冊分のコンテンツを丸ごと記述することになりますが、DITAでは複数のトピックファイルに分割して記述することになります(モジュール化)。こうすることで各トピックの再利用性の向上を図るわけですが、このことにより、執筆の仕方を今までとは変えなくてはならないことがあります。
たとえば「ラジオの聴き方」を書いたトピックの中では「すでに述べた方法で電源を入れた後に・・・」という書き方は避けた方がいいでしょう。なぜならマップの書き方次第では「すでに述べた」とは言い切れないからです。後で述べるかもしれませんし、そもそもどこにも述べない可能性もあります。つまり文脈依存の書き方は避けた方がよい、ということになります。これをトピック指向と言います。
■ショートデスクリプションの奨め
トピック内にショートデスクリプション(要約)を書くことが推奨されています。たとえば次のようになります。
<topic id=”GoalOfDITA>
 <title>DITAのめざすもの</title>
 <shortdesc>DITAによってマニュアル制作の効率化を望めます</shortdesc>
 <body>
  <p>DITAの目的は次のとおりです</p>
  <ul>
    <li>データ再利用性の向上</li>
    <li>ワンソースマルチユース</li>
    <li>翻訳の効率化</li>
  </ul>
 </body>
</topic>
こうすることでHTMLにした場合など、アンカー文字列にマウスホバーしたときに要約をポップアップさせたり、検索結果として要約のみをリストアップすることができるようになります。
とても小さなトピックの場合、要約を書くことによって本文に書くことがなくなってしまう、という心配もあるかもしれませんが、そのときは本文の方を空にします。それほど要約が重要視されているということですね。
各トピックの要約を読んだだけで製品の全体像がそこそこ分かってしまう、という形が理想的なのかもしれません。ですので、
 <shortdesc>ここではxxxについて述べます</shortdesc>
というような要約はご法度です。
では、また明日。


Pages: Prev 1 2 3 4 5 6 7 8 9 10 11 12 13 Next