FrameMakerコラム

当然ながらFrameMakerのヘルプトピックに変換表の記事がありますので開いてみます。

変換処理では、FrameMaker 書式コンポーネント（段落タグ、文字タグ、マーカー、相互参照、表コンポーネントなど）から、構造化エレメントを作成します。

FrameMaker (2017 release) ヘルプ から引用

その通りですね。「変換処理」とは非構造化文書を構造化文書にする処理ですから、まず非構造化文書を開きます。その非構造化文書は、

変換処理を開始するには、内容を代表するような非構造化文書を選択します。 この文書には、文書に出現しうるあらゆる書式タグの例が含まれていることが理想的です。

FrameMaker (2017 release) ヘルプ から引用

そうです。「内容を代表するような、文書に出現しうるあらゆる書式タグの例が」含まれている文書を変換前文書として選択します。

選択します、といっても「文書に出現しうるあらゆる書式タグ」が網羅されている文書ファイルが存在し且つそれをすぐ選択できる状況は稀ではないでしょうか。

ということで、出来るだけ全文書（構造化すべきブック内全コンポーネント）を通して出現しうるあらゆる書式タグのうち、全書式タグを使用していなくても最も多いであろう文書を選択します。

つまり、この時点でFrameMaker書式コンポーネント（上記参照、Adobe談）について適切に管理されていることが望ましいといえます。

しかし待ってください。そんなことってあるでしょうか？
わが組織の既存文書の書式コンポーネントはすべて適切に管理され、登録されていない段落タグ（段落書式）などなく、書式の上書き（オーバーライド）も皆無で、適切な個所に適切なタグが設定されているのは間違いない！！
という方は、問題ないです。失礼しました。

往々にして歴史のある文書には様々な理由で様々な書式が入り乱れているのが普通だと思っています。
書式は入り乱れているのに表示（見栄え）だけは統一されている場合はオーバーライドされている可能性が高いですよね。

次の画像をご覧ください。

新規作成文書にデフォルトで作成される段落書式を文書に現わしたものですが、「謎の段落」という段落書式は登録されていないことがわかると思います。

この「謎の段落」という段落書式に対する対応も「変換表」には挿入されます。ファイルは以下です。
サンプル文書

逆に

FrameMaker は、文書をスキャンして、この文書中に出現する書式コンポーネントのリストを作成します。 リストには、書式設定カタログで定義されているが、文書では使われていないタグは含まれません。

FrameMaker (2017 release) ヘルプ から引用

ということで、書式が定義されているかどうかではなく、文書で使用されているかどうかが問われます。

ただ！！

むつかしく考えなくてもオッケーです。変換表は「更新」することが可能だからです。

ということでまずは、

1. 「どちらかというと他の文書ファイルより色々な書式が使用されていそうな文書ファイル」を開きます。
   サンプル文書に EDD からエレメント定義を取り込まなくても、とりあえず今は問題ありません。
2. 構造／ユーティリティ／変換表を生成を選択し、「新しい変換テーブルを生成」を選択し、「生成」をクリックします。
   メニューコマンドに関しては、バージョンで異なるので適宜読み替えてください。

変換表が生成されました。

「Wrap this object or objects」列の元文書の内容を「In this element」列のエレメントでラップします。

「With this qualifier」列は、修飾子です。見分けるためのフラグ、グループ分け、ですね。「In this element」列のエレメントは同じでもグルーピングの種類が異なる場合に便利です。これをまた後でラップするわけです。

生成された表は3列ですが、変換表開発時に役に立つ4列目を追加しておきましょう。ヘッダは「Description」です。開発途中のメモ列として活用すると便利です。というかこの列が無いと、複雑な変換になったときにミスが起こりやすくなりますし、後から見たときにわかりやすくなります。

「In this element」列にはEDDで定義されたエレメントを記入するわけです。。。。

結局、すでにEDDが開発済みである必要がありますね。。。とはいえ、変換表の前半終了です。次回はやっぱりEDDに手を付けるのがよさそうでしょうか。。。

というわけで、構造化していきましょう。

「構造化」という言葉の定義は横によけておいて、XML化と捉えてくださっても良いと思います。（「XML化」という言葉の定義も避けておきます。実際、FrameMakerでタグ付けしても、それがXMLそのものというわけではありません。）

新規で文書を作成するにしても、既存文書を構造化するにしても、文書全体の把握は欠かせません。

パターンの把握

前々回の記事と重複しますが、まず既存文書のパターンを把握しましょう。
文書といっても多岐にわたりますので、数百ページのオーナーズマニュアルを念頭に置いて進めていきます。

大→小で攻めていきましょう。ブック構成というやつですね。

ブック構成

本全体の構成は良いでしょうか？
章の並び、情報の過不足、問題ないでしょうか。
目次は複数（総目次、目次、章目次など）必要でしょうか。索引はどうでしょう。
トラブルシューティングは？用語集は？

問題なければ、次に進みましょう。
問題が発見されれば構成を再検討してください。

この辺りは各組織によってまちまちでしょうから、軽く触れるだけにとどめます。

章構成

通常メインの文書になります。

既存の非構造化FrameMakerファイルを構造化するには「変換表」を利用すると、作業が簡素化されます。（すべての内容が自動で構造化されるわけではなく、手作業は必ず必要になります。）

。。。ここで「変換表」の詳細に入っていこうかと思いましたが、「変換表」を説明するためにはまずEDDを理解している必要があるのではないか。。。などとも思いました。

結局、追ってEDDも出来る限り解説していくつもりですので、変換表を先にやっちゃいますね。次回ですけど。

前回の続きです。

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

と言ったように、今後の文書の展開に対して

1. どのように活用するか？
2. 期限は？
3. 費用は？

といったことを、大まかにでも想定することが肝要かと思います。

もちろんプロジェクトは変質していくものですし、最初からすべて把握できているわけではありません。ただプロジェクトにかかわる各個人の頭の中にあるイメージくらいは最初に吐き出しておくべきかと思います。

そして当然クライアントのお役に立てるようなものを構築していくのですから、自分勝手でもいけません。

「期限」「費用」については仕事の一般論になってしまいますね。でも一番重要なことですよね。

どのように活用するか？

情報の活用方法によって、そこにメタ情報として用意しておくものが変わります。文書の設計が変わるということです。

後々用途が変わったり想定していた状況のみでは対応できなくなったりといったことは、ままあることです。しかし、ある程度文書を作成してしまうと、その定義を後から変更するには工数が倍々で変わっていきます。プロジェクトの最初で知恵を絞って様々な状況を想定すべきかと思います。

技術的な想定はある程度外部の人間にもできますが、クライアント様の内部的な構想や都合は外部の人間には知り得ないものですので、この、「初期ミーティングで仕様を詰める」作業が、後々非常に重要な意味を持ってきます。

構造化したデータをどのように使用したいか、実際どのように使用できるか、（できれば）その効果はいかほどのものか、さらにその先は誰が（人や組織）関わり、どのように管理していくのが良いか、などです。使用方法や管理方法によっては、FrameMakerで構造化しないほうが良い場合もあります。

エディターとしてのFrameMaker

弊社は創業以来13年間（スタッフはそれ以前から）、FrameMakerを使用した業務に携わってきました。FrameMakerには長い歴史があり、それぞれの時代でエディターとして活躍してきました。

しかしFrameMaker6をシステムの中心に据えるには、解決すべき課題がありました。

1. 他フォーマットへの展開
2. ユニコード文字への対応
3. アラビア語などへの対応

などが大きなところだと考えます。

1はver.6+SGMLでSGML、ver.7で統合されXMLに対応、2はver.8で対応され、3はver.13（FrameMaker2015）で対応されました。

つまるところ、FrameMakerをマルチパブリッシングの中心（あるいはその近く）に鎮座ましますものとして採用するのも「あり」ではないかということです。

更に、FrameMakerは「エディター」として活躍してきました。
その機能をも存分に発揮してもらえるというわけです。

「強力にXMLを取り扱え、エディターとしても高度に機能する」ことこそが、FrameMakerと他者を分ける境界線だと思えます。

とはいえ不満もあるんですよ。。。
細かいことではいろいろ。。。
しかし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最大の特徴だと私は捉えています。

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

オブジェクトスタイルは使いようによっては良いものですが、注意が必要です。

FM→XML→FMという順路をたどる（ラウンドトリップ）ことを仮定します。

1. 描画されたLineオブジェクトに、線の両端が矢印になる「Arrow」オブジェクトスタイルが適用されています。

   

2. このLineを「オブジェクトの属性」パネルから変更すれば、通常、オブジェクトスタイルは外れます。

   

   

3. しかし、グラフィックツールからオブジェクトを変更すると、オブジェクトスタイルは適用されたままです。オブジェクトがオーバーライドされた状態になるのですね。

   

4. 「3.」の状態のままXMLに書き出して、再度FrameMakerで開く（ラウンドトリップ）と、オブジェクトスタイルが再度適用されますので、以下のような状態になってしまいます。

   

これを理解しないまま、オペレーターに業務が移行するワークフローであればどうでしょうか。

ちょっと取り返しのつかないことになる可能性がありますね。（もちろん状況によりますが）

EDDなど含めFrameMakerに関してのご相談は是非、弊社に！

Windows 10 バージョン1803 にアップデートすると、FrameMakerからPDFが生成できなくなるという問題があります。（2018/05/22現在）

FrameMakerコミュニティフォーラムに記事があります。

https://forums.adobe.com/thread/2488236

本家フォーラムにも話題があがっています。

https://forums.adobe.com/thread/2476727

Microsoftは現在バグ修正に取り組んでいるようですが、現状としては、Windowsをロールバックするしか回避方法は無いようです。

弊社でも1803から1709にロールバックする必要に迫られまして、無事これを行いました。ロールバックによってもたらされる目立った不具合はありませんでした。（潜在的にあるのかどうかはわからないです）

Windowsのバージョンの調べ方は、「Windowsキー + R」で「winver」で「OK」してください。

表があります。

それぞれのセルの塗と罫線の設定は、「表から」です。

複数のセルを選択してみます。

設定は「表から」です。当然ですね。

異なる組み合わせの複数セルを選択してみます。

！？

カラー混合って、なんでしょうね？

しかも単に表示だけの問題ではなく、これが原因で余分な「カラー」を削除できなかったりします。（正確には、その「カラー」を使用しているとFrameMakerに注意されます）

・・・・