plugin development

ditamap内データのエレメントデータについて

  • 3rd 3月 2016
  • DITA

FrameMakerを利用したDITA案件が増えてきている。
1点今後のためにメモ。

ditamap内に定義される各種データに、2バイト文字が利用されることがある。
メタ情報の設定場所なので多々でてくる。

ditamapのデータは他のFMデータと同じようにしてテキストデータを取得できるのだが
ditamapデータはFMに投げ込まれた時にテンプレートとEDDが紐付いていることを
忘れてはならない。

ある要素の内容についてF_ApiGetTextなどを利用して取得するのだが
ditamap用のテンプレートで各要素に設定されているフォントが
2バイト文字に対応していない場合、プログラム側でどうやって
処理しようとしても必ず文字化けとなってしまい正しい値を取得できない・・・。
また、取得できたとしてもEDD側で要素に対してPrefixが設定されている場合
予定なテキストデータまでくっついて取得できてしまう。

ditamapに定義されているデータを表紙などに利用しようとする場合に
ditamapにはテンプレートとEDDが強く関連していることを念頭に
おいておかなければならない。
単なる各種ditaデータへのパスが定義されているMAPデータではないということ

Oxygen XML WebApp

  • 21st 1月 2016
  • DITA

ブラウザベースのXML編集に関してはCKEditorやJQueryを利用したモジュールで構築していることが殆どでしたが
oXygen XML WebAppを利用したシステム構築を検討中です。

demo はこちらです。
https://www.oxygenxml.com/webapp-demo-aws/app/oxygen.html

SDKも公開されているので、細かい部分を調整してかなり便利で安定したEditorに仕上げられそうです。
編集中のツリー表示ができればさらに良いのでこのあたりはJQueryを利用してモジュールを組み込みたいですね。

oxygen

PowerPoint VSTO

PowerPoint VSTO 開発

プロジェクトの初期設定や開発に際しての入り口がプラグイン開発は難しいところですが
取っ掛かりが見つかるとリファレンスを見ながらある程度スムーズに開発は
すすみます。Excel,WordにしろVSTOを利用した開発案件の際には是非一度お声掛け
いただければと思います。

 

FrameMaker12 合成フォントのバグ

FrameMakerでは構造化文書において1バイト文字と2バイト文字が混ざって使われている場合、
合成フォントという定義を利用して1バイトも時にはArial、2バイト文字にはMSゴシック
といったようにフォントを使い分けることができる便利な機能がある。

FrameMaker7でもこの機能が利用できるのだが、構造化文書を利用する場合
つまりXMLからFMデータを自動で生成する(構造化アプリケーションを利用)場合、
2バイト文字に正しくフォントが適用されないというバグがあった。
これに対する対応情報はAdobeのサイトでも公開されていた。

さすがにFrameMaker12ではこのバグが直っているのだと思い込んでいたが
全く同じ状況が生じた・・・。ずっとバグを引きずっているよう。

ただおそらくこれが発生するのは特定の条件が揃った場合のようで
すべての状況では生じないよう。
少なくともFM12で1から作成した構造化アプリケーション
の場合はこの問題は発生しない。

現在対応中の案件でこれが発生!

このバグ回避用のプラグインを開発しました。
この点でお困りの方はご相談下さい。

FrameMakerでのpgwideの動きについて(2)

  • 21st 11月 2014
  • DITA

pgwideの動きについてですが、0,1の指定で表幅が変わるのだが
どうやら、0の指定がされた場合は、表の直前のテキストが存在する段落の
段落書式の1行目ではなく、2行目以降のインデント。つまり、
基本タブの左インデントの値に合わせて表のインデントが設定されるようだ。

FrameMaker DITAアプリケーション

  • 11th 11月 2014
  • DITA

FrameMakerにデフォルトで設定されている構造化アプリケーションの他に
プロジェクト単位で別の構造化アプリケーションを定義する場合、
structapps.fmファイルを編集することで対応が可能である。

DITAについてはDITAアプリケーションが用意されている。
DITA 1.1、1.2ともに設定されている。
しかしレイアウトを含めて個別の設定を持たせたい場合は、
FrameMakerのDITAメニューから、DITAオプションを選び、
DITAアプリケーションマネージャーを利用して任意の設定をする。

DITAアプリケーションを必要な分だけ設定することで、
デフォルトの設定とプロジェクト単位の設定とを瞬時に切り替えて結果を確認できる。

※ デフォルトのDITAアプリケーションを下手にいじると、DITAデータのレイアウトなどが
一切できなくなることも生じ得るので注意が必要

DITA – FrameMaker構造化定義ファイル

  • 26th 10月 2014
  • DITA

FrameMaker11を利用してDITA1.1で構造化データを定義している。

構造化するデータ用に独自の構造化アプリケーションを構築する
必要があるが、FraemMaker側で独自に設定されているDITAの構造化定義を
なるべくそのまま利用した方がよい。

テンプレートやRWルールは調整する部分があるとはいえ、
その他のAPIの定義や、TransformationFile,XSLTなど
デフォルトのままで利用した方が良い。

DITAデータ自体は問題なく作成されるが、
DITAデータを扱うFM側の機能が正しい動作をしなくなる。
Bookmap定義、相互参照の設定、その他細かい部分…。

FrameMakerのditaval対応について

  • 16th 10月 2014
  • DITA

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の動きについて

  • 16th 10月 2014
  • DITA

FrameMakerでDITAを扱う場合、構造化データを確認しながらレイアウトも確認・調整できるため
操作と扱いに慣れてしまえばとても有用なアプリケーションになると思われます。

FrameMakerはDTIA表でpgwide 属性を利用しOASIS 交換表モデルに準拠しています。
この属性は1=ページ幅、0=カラム幅を示します。

それで実際にDITAで表を作成し、FrameMaker上で表レイアウトを見ながらpgwide属性の値を
切り替えて動作を確認してみようと思う。

ただ、そのままでは動作の確認ができない
利用するDITAモデル毎に設定されているEDDファイルにおいてtable要素にpgwide属性を
定義してあげないと画面上に属性値が表示されないので注意すること。

WS000049

また、ページ幅とカラム幅で表のレイアウトが切り替わることを確認するためには
表がレイアウトされているページのカラム数が複数カラムになっている必要があるので
注意すること。1カラムのページ上では数値を切り替えても全幅にはなるかもしれないが
いったん全幅になった後は変化をみることはできない。

FrameMaker側でデフォルトで用意されているDITA用のデフォルトのテンプレートでは
FrameMaker独自の横見出しテンプレートが設定されている。横見出し部分はカラムとは
認識されないのでここも勘違いしないようにしなけれればならない。
あくまでもコラム数を複数にする必要がある。

上記の条件をクリアした状態で、pgwideの属性値を0,1と設定してみると
表幅がページ幅とカラム幅に変化することを確認することができる。

※ pgwide動作確認のための必要設定は以下の通り

  • EDD側でpgwide属性を定義する。
  • RWルールでtable要素に「attribute “pgwide” is fm property page wide;」が定義されていること。
  • レイアウトページが複数コラムとなっていること。