XDocs,DITAToo
DITAを扱うにあたりFrameMakerを利用したシステムを考えた場合
XDocs,DITATooは非常に親和性が良く、便利であり有用なツールになります。
DITAデータの管理、FrameMakerとの連携、多言語管理をお考えの場合
なにかしらのCMSの導入は必須と言えます。DITAの良さを十分に
発揮させるためにも必要です。
FrameMakerでのpgwideの動きについて（２）
pgwideの動きについてですが、0,1の指定で表幅が変わるのだが
どうやら、0の指定がされた場合は、表の直前のテキストが存在する段落の
段落書式の1行目ではなく、2行目以降のインデント。つまり、
基本タブの左インデントの値に合わせて表のインデントが設定されるようだ。
FrameMaker DITAアプリケーション
FrameMakerにデフォルトで設定されている構造化アプリケーションの他に
プロジェクト単位で別の構造化アプリケーションを定義する場合、
structapps.fmファイルを編集することで対応が可能である。
DITAについてはDITAアプリケーションが用意されている。
DITA 1.1、1.2ともに設定されている。
しかしレイアウトを含めて個別の設定を持たせたい場合は、
FrameMakerのDITAメニューから、DITAオプションを選び、
DITAアプリケーションマネージャーを利用して任意の設定をする。
DITAアプリケーションを必要な分だけ設定することで、
デフォルトの設定とプロジェクト単位の設定とを瞬時に切り替えて結果を確認できる。
※ デフォルトのDITAアプリケーションを下手にいじると、DITAデータのレイアウトなどが
一切できなくなることも生じ得るので注意が必要
DITA FESTA 2014
六本木ミッドタウンXEROX様オフィスにて
DITA FESTA 2014が開催されました。（http://dita-jp.org/?page_id=1701）
個人的にはアートダーウィン合同会社 加藤さん、
YAMAGATA INTECH株式会社 平井さんのお話は大変参考になりましたね。
DITA1.3の解説も行われました。keyref,troubleshootingの実装は
大変楽しみです。
DITA – FrameMaker構造化定義ファイル
FrameMaker11を利用してDITA1.1で構造化データを定義している。
構造化するデータ用に独自の構造化アプリケーションを構築する
必要があるが、FraemMaker側で独自に設定されているDITAの構造化定義を
なるべくそのまま利用した方がよい。
テンプレートやRWルールは調整する部分があるとはいえ、
その他のAPIの定義や、TransformationFile,XSLTなど
デフォルトのままで利用した方が良い。
DITAデータ自体は問題なく作成されるが、
DITAデータを扱うFM側の機能が正しい動作をしなくなる。
Bookmap定義、相互参照の設定、その他細かい部分…。
XMLをInDesignタグ（タグ付けテキスト）に変換
XMLをInDesignに読み込ませてレイアウトを整えるとなると複雑な表レイアウトが多いマニュアルでは
レイアウトを再現するまでのスピードの問題が発生する。
そこで、取り込む表についてはXMLからInDesignタグへと変換してしまい。
それをそのままInDesign上に配置ことで時間の短縮を図る。
InDesignタグ仕様 -> 「InDesignタグ付きテキスト ユーザーガイド」
※ InDesign自動組版の場合、表以外のレイアウトでもタグ付きテキストにしてしまった方が
レイアウト処理はスムーズである。各種書式の変更やマスターページの変更といった
ことが頻繁に起こるのであればメンテナンス性にかけるこの手法は面倒な点があるものの
変換処理の安定性やコーディングの難易度からすると、はるかにInDesignタグを利用する
ことに利点があると言える。
FrameMakerのditaval対応について
FrameMakerでは、各種段落やテキストに対して表示・非表示の属性を持たせることができる。
コンディショナルテキスト情報としてFrameMakerでは管理されていた。
現在ではDITA導入となりditavalでの運用も可能となっている。
機能としては非常に似ている
コンディショナル機能
ditaval機能
だが効果としては若干の違いがある。
簡単にいうと構造化情報を意図するditaval機能に対して
コンディショナル機能では構造は意図せず属性が設定されているか否かに基づいて
適用される。
以下のような定義をしてみた。
<bookmap>
∟ <chapter>
∟ <concept>
∟ <title> sample title text </title>
∟ <conbody>
∟ <section product=”productA” >
∟ <p otherprops=”otherA” > sample AAA text </p>
∟ <p otherprops=”otherB” > sample BBB text </p>
この場合、ditavalにてotherAを表示としてproductA,otherBを非表示に設定する。
すると構造を認識するditavalの機能ではsection以下がすべて非表示となる。
しかし、コンディショナル機能で同じような設定を適用した場合は、
otherAが表示設定となっているため、なんと…
ダミーのsection要素が自動で生成されてotherAが表示された。
構造の考え方が適用されないと考えられる。
dita＋FrameMakerでの運用を考えた際にはコンディショナルを利用することは
避けるべきであり、ditavalでの運用を考えるべき
FrameMakerでのpgwideの動きについて
FrameMakerでDITAを扱う場合、構造化データを確認しながらレイアウトも確認・調整できるため
操作と扱いに慣れてしまえばとても有用なアプリケーションになると思われます。
FrameMakerはDTIA表でpgwide 属性を利用しOASIS 交換表モデルに準拠しています。
この属性は1=ページ幅、0=カラム幅を示します。
それで実際にDITAで表を作成し、FrameMaker上で表レイアウトを見ながらpgwide属性の値を
切り替えて動作を確認してみようと思う。
ただ、そのままでは動作の確認ができない
利用するDITAモデル毎に設定されているEDDファイルにおいてtable要素にpgwide属性を
定義してあげないと画面上に属性値が表示されないので注意すること。
また、ページ幅とカラム幅で表のレイアウトが切り替わることを確認するためには
表がレイアウトされているページのカラム数が複数カラムになっている必要があるので
注意すること。１カラムのページ上では数値を切り替えても全幅にはなるかもしれないが
いったん全幅になった後は変化をみることはできない。
FrameMaker側でデフォルトで用意されているDITA用のデフォルトのテンプレートでは
FrameMaker独自の横見出しテンプレートが設定されている。横見出し部分はカラムとは
認識されないのでここも勘違いしないようにしなけれればならない。
あくまでもコラム数を複数にする必要がある。
上記の条件をクリアした状態で、pgwideの属性値を0,1と設定してみると
表幅がページ幅とカラム幅に変化することを確認することができる。
※ pgwide動作確認のための必要設定は以下の通り
- EDD側でpgwide属性を定義する。
- RWルールでtable要素に「attribute “pgwide” is fm property page wide;」が定義されていること。
- レイアウトページが複数コラムとなっていること。
AH Formatter アラビア語対応
アラビア語は文字が右から左に流れるために以下の属性をblock要素に付与する。
- writing-mode=”rl-tb” （文字の流れ右から左）
- language=”ar” （言語）
表罫線の指定の仕方にも注意する。通常、罫線の表示指定については
border-left-style, border-right-style
といった設定を利用して罫線のスタイルを指定するが、
組みの流れが逆になっているため、これも逆に考える必要がある。
しかし、border-start-style, border-end-style
という指定の仕方で指定しておけば、組の流れが右から左でも左から右でも、
組の流れに対して相対的に指定することができる。
左から右の流れの場合の左端罫線はborder-start-style
右から左の流れの場合の左端罫線もborder-start-styleとなる。