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も出来る限り解説していくつもりですので、変換表を先にやっちゃいますね。次回ですけど。