FrameMakerコラム

FrameMakerの構造化についてです。

この記事での「構造化」の意味するところは、FrameMakerデータのXML化です。

eXtensible Markup Langageの名の通り、XMLはタグ付けする言語です。タグ付けは意味付けです。

テキストの意味付け

FrameMakerの非構造化データ（通常のデータ）があるとします。

FrameMakerでは、非構造化データを構造化データにする際に、とても便利な機能が備わっていますが、そのひとつが「変換表」です。

この段落書式（スタイル）は、このエレメントにするんだよー。という指示をFrameMakerに伝える表ですね。

しかし、それを使うのはエレメント定義が終わってからです。エレメント定義ができていないと、「このエレメントにするんだよー」の部分ができませんから、当然ですね。

また、「変換表」を使う際には、既存のデータにおいて段落書式は正しく適用されているか？という問題もあります。

それを保証してくれる人はほぼいません。経験上で言っているのでいるかもしれませんが、ほとんどは「正しく適用されているはずだが調べてくれ」となることが多いです。

さらにこの段落書式（スタイル）が曲者で、「8_pt」とか見た目の定義をしているのはそのままエレメントには変換できません。

技術的にできないのではなく、XMLにする目的が「他のデバイスで表示する」「HTMLにする」「部分的に抜き出して違うマニュアルを構築する」だったりすることが多いので、紙（PDF）の見栄えだけに合わせたエレメントを作っても異なる方法でデータを使用したい場合に意味が希薄になってしまいます。

「XMLにすることで達成したいタスク（目的）」が問われます。

見た目も大事です。とても理解できる主張です。そもそもデザイン（設計という意味ではなく）にもそのデザインにした重要な理由があるはずですし、外せないこだわりもあるはずです。

しかし、ここで言うテキストの「意味」は「8_pt」からは推測できません。

パターンの把握

テキストの意味付けを行うためには、既存データのテキストの意味を知る必要があります。

それが明確ではないなら、文書を解析することから始める必要があります。全てのテキストに意味付けするわけですから、「おおよそ」とか「たぶん」はいけません。「すべての」です。

分析するには、「この部分はどのような意図で文字を太くしているのか」など「どのような意図で」が重要になります。ですのでライターさんの協力が欠かせません。まずライティングの仕様の有無を確認しますが、文書にまとめられていて更に現状でそれが厳守されていることはまれです。

結局、「文書の再定義をしましょう」ということになることが殆どではないでしょうか。

で、文書に使用されているパターンを把握する必要があるのですが、「この文字サイズのパターン」「インデント量のパターン」「複数コラムのパターン」など、パターンといっても色々です。そして、既存のデータで使用されているパターンが、本当に必要なのかを、内容変更の決定権者に確認して進めていく必要があるかと思います。この「決定権者」がライターさんなのか重役さんなのかどなたなのかは組織によって異なるでしょうが、これをしないと、後でこんなはずじゃなかった論議に花が咲くことになりますので、XML化をする前によくよく話し合いをすべきだと思います。

話し合いで、パターンの種類を机上に出し、共有化できるものなのか個別のものにすべきものなのか話し合って種類を最小限にし、それぞれに定義していきます。

文書の構造化

皆さんお気づきでしょうが、既存の文書をXML化しようとしたら、まず、既存の文書が「文書の構造」を正しく持っているかどうかを検証する必要があります。

FrameMakerにはとても便利な機能が備わっていますが、既存の文書を自動で思い通りのXMLにすることはできません。地道な作業が必要（もちろんFrameMakerに限りません）なので、それを認識したうえでXMLにすることによって、今後どのような展開をし、どのようなメリット、デメリットが考えられるのかを話し合ったうえで、腰を据えて取り組むのが良いと思います。

・・・いつのまにやら具体的な話ではなくなってしまいましたが、弊社では費用と時間をかけても文書は構造化したうえで運用していくべきだと考えています。

文書の今後の展開をどう見積もることができるか？が重要ですね。そしてそれはクライアント側にしかできない見積もりです。

FrameMakerの情報を得ようとしてWeb検索しても、ヒットするのは一昔前の記事なことが多いです。

もちろんAdobeさんの最新記事はヒットしますよね。しかしこれが的を射ていないこともあります。発売元の記事ですから当然、第一級の重要な情報なのですが、では実際使用してみたらどうなのか？という視点から書かれたものではないと感じることもあります。

あと、翻訳者視点の情報も多々ありますよね。FrameMakerの場合。

このコラムは、現在（2018年）もどっぷりFrameMakerに浸かって奮闘している弊社の現場視点から書かせていただこうと思っています。

こんな方にお勧めです。

1. 社内にFrameMaker資産が存在するが、どう処理していいか検討されている方
2. 新規文書作成に当たって、ツールの選定をされている方
3. （Web系ではなくドキュメント系の）CMS導入を考えている方
4. 過去にバグの多さからFrameMakerを憎んでいる方
5. 何か新しいことやれと命令されている方
6. FrameMakerは終わったツールだと思っている方

意外といらっしゃるのが、「FrameMakerはもう開発もしていないし過去のツールだ」と思っている方ですね。

そうではないですよ。と反論してみても、「昔使っていたがバグが多すぎて使い物にならない」というご意見をいただくこともしばしば。

この辺りは、Adobeさんにも責任がありまｓゴニョゴニョ

今現在も、これってバグでは？と思うようなものは散見しますね。確かに。

今も昔もある伝統的バグは、「次頁の内容が入り込んできてしまう」というもの。

再現性が（ほぼ）無いため、画面は後日貼りますが。。。

弊社はこれをチェックするツールを作成して対応しています。
皆さん、どんな対応されているんでしょうか。

しかしこういったバグ的なものは、内容をしっかり把握し対応することは可能だと思います。

それらを踏まえたうえでも、FrameMakerをドキュメント作成ツールに採用する価値は十分にある。と、考えています。

とはいえ、何でもかんでもFrameMakerを。ということではありません。適材適所。まず、

1. 対象のドキュメントは何のためのものか？
2. ドキュメントをどうしたいのか？
3. その要件とスケジュール

をはっきりさせたうえでツールの選定を行うことが最も重要なことではないでしょうか。選定根拠の情報収集のためにも、このコラムをご活用ください。

FrameMakerを使ってドキュメントを作成していくと、FrameMakerのファイルを開いた時に、「非決定の相互参照」のアラートが表示され、ビックリすることがあります。

具体的には、このようなメッセージです。

「XXXXXXX.fm」には、非決定の相互参照があります。決定方法は、ユーザーガイドまたはオンラインヘルプを参照してください。

（画像は、FrameMaker 12です。以降同様です。）

FrameMakerを使いはじめたころは、よくわからずアラートにしたがってマジメにつなぎ直したり、相互参照を更新したりするのですが、次回ファイルを開いた時に、また「非決定の相互参照が…」のアラートが…。

なぜ、相互参照がファイルを開きなおすたびに切れてしまう（非決定になる）のか分からず悩んでしまうことがあります。

ただ、大抵の場合、ブック内のファイルを全て開き、「ブック更新」で「全ての相互参照」を更新すると「ブックエラーログ」に非決定の相互参照が表示されること無く、更新できてしまいます。

あれ？！相互参照、切れてないじゃん！

そう思ったあなたは正しいです。

全ての相互参照を更新して、「ブックエラーログ」に非決定の相互参照が表示されなければ、相互参照に問題はありません。もし、ここで非決定の相互参照が表示されていれば、それは、修正すべき箇所です。

では、なぜ相互参照に問題がないのに、ファイルを開いた時に非決定の相互参照のアラートが出てしまうのでしょうか。

実は、すごく単純な話なのです。

開いたファイルにある相互参照が、別のファイルを参照していると、その参照先のファイルがまだ開かれていなかった場合、参照先が無いと判断され非決定の相互参照アラートが出てしまうのです。

例えば、ブックに先頭から「A.fm」、「B.fm」の順にファイルを登録してあり、「A.fm」のファイル内には「B.fm」への相互参照が貼られているとします。

全ファイルを開こうとした時、ブックの先頭にあるファイルから開かれていきますが、

この「A.fm」を開いた時には、まだ「B.fm」は開かれていません。そのため、FrameMakerは、「参照先が無いぞ！」と判断し、実際には参照先があるにもかかわらず、アラートを出してしまうのです。そのため、ファイルを全て開ききったあとに、全ての相互参照を更新してもブックエラーログには、非決定の相互参照が表示されないのです。

アラートのあの一文ももっと親切に、「決定方法は、ユーザーガイドまたはオンラインヘルプを参照してください。あるいは、参照先のファイルがまだ開かれていない可能性があります。」など、付け加えてくれたら分かりやすいのになと昔から思ってました。

つまり、結論的には、ファイルを開いた時に表示される非決定の相互参照アラートは、「気にしない」で大抵大丈夫です。

ただし、全てのファイルを開いているのに、相互参照を更新して「ブックエラーログ」に非決定の相互参照が表示される場合は、ちゃんと修正しましょう。

ちなみに、Adobeさんも、ファイルを開いた時の「非決定の相互参照」のアラートが少々面倒くさいと気づいたのか、FrameMaker11あたり（うろ覚えです…）から、このアラートを非表示にできるように設定することができるようになりました。

設定方法は、FrameMaker12を例にとると「編集」→「環境設定」→「グローバル」の「警告」をクリック。「ファイルには非決定の相互参照が含まれています」のチェックを外せばOKです。

これで、スッキリ開けます。

所在不明のフォントについても、注意点があるのでいずれまた…。

新規にドキュメントを作成する際、仕様ツールについても検討されると思います。

どんな基準で検討されているでしょうか？

今回は、FrameMakerとInDesignについて比較してみようと思います。

基礎的な比較はAdobeのヘルプにお任せします。

https://helpx.adobe.com/jp/x-productkb/multi/217.html

ここで比較しなくても既に、様々に高度な比較をされているサイトが存在すると思いますが、少しだけ違和感があるのは、FrameMakerをいわゆる「DTPツール」として捉えていたり「ワープロ」として捉えていたりすることです。

その捉え方は、、、正しいです 😀

ただ私はFrameMakerをシステムだと捉えています。これは言葉のニュアンスなのでどれが正解とかの話ではなく、感じ方の話です。

一般的には、DTPツールの代表格といえばAdobe Illustratorがあがると思いますが、これと良好な関係を保っているのがAdobe InDesignです。デザインに主眼を置いているツールです。私はInDesignを「ページレイアウトツール」と呼んでいます。

InDesignは「印刷」に特化しておりまして、その機能は目を見張るものがあり、素晴らしいです。

色の管理もInDesignが優れていますし、テキストがオーバーフローしていたら知らせてくれるなど、親切心いっぱいです。

フローを自由に配置しデザインしていく「ページレイアウトツール」です。

対してFrameMakerはメインフローを真ん中に据え、そこに内容を流し込んでいくようなイメージです。

色の管理やグラフィックの描画に関しての機能はInDesignに比べれば貧弱と感じるでしょう。しかし、FrameMakerの真価はそこにはなく、「構造化」文書の作成時にこそ真の力を発揮すると考えています。

「構造化」文書とは単純にXMLを指すわけではなく、構造規則のもと作成されている文書のことですが、話が長くなるのでここではXMLをイメージしていただいてもかまいません。

FrameMakerはXMLを取り扱うアプリケーションとして非常に強力です。

スタイルや構造を定義するEDD（Element Definition Document）や読み書きルールなどを含む「構造化アプリケーション」を開発することによって、XMLを詳細にコントロールすることが可能です。

XMLを強力にコントロールできるツールでありながらWYSIWYGのエディターであることが、FrameMaker最大の特徴だと私は捉えています。

長くなってしまったので、また次回…