Confluenceプラグイン開発
コンテンツコラボレーションツールとして有名なConfluenceのプラグイン開発を経験しました。
非常に拡張性のあるツールなので、スモールスタートから必要に応じたカスタマイズをすることが
可能ですね。
大企業からベンチャー企業に導入されているという意味での安心感と安定感があります。
今後も機会があれば開発をすすめていきたい。
株式会社MA-CREATE 佐藤
FrameMaker2019
FrameMaker2019がリリースされましたね。
https://www.adobe.com/jp/products/framemaker/features.html
今までも64bit環境で動作していましたが、内部的な処理をすべて64bit対応したことで
かなりスピードアップしているようです。参照画像などによりパフォーマンスは
異なると思いますが、1000ページ単位のデータでも2,3分でPDFに変換できるとのこと。
「PDFやResponsive HTML5のパブリッシュ速度が最大65％向上します。」
要チェックですね。
MA-CREATE 佐藤
WORD VSTO
WORDプラグインをVSTOで対応しています。
ExcelやPowerPointと同じような感覚で触れます。
ほぼ、毎日使うWORD、Excel、PowerPointを使いやすいようにカスタマイズするのは有用です。
社内でのドキュメント運用において、統一感、同レベルの品質を実現できます。
DITAデータを Congility – IdXMLを利用したInDesign自動組版
Congility社のIdXMLを利用したInDesign自動組版を手がけました。
DITAはOxygenを利用して生成されます。
このDITAデータを入力データとしてIdXMLで変換を掛けます。
IdXML（http://congility.com/idxml/）ではかなり幅広い設定があり、
InDesignへの入力データとして適切な形へと変換してくれます。
今回はIdXMLを一部カスタマイズしましたが、なるだけカスタマイズしないで
IdXMLの仕様に細々合わせていくことで、余計な工数を削減し
シンプルなXMLファイルへと変換できると感じます。
今回は、IdXMLの処理直前にXSLT変換、処理後にもXSLT変換させて
InDesignのプラグインへと連携させました。
ditamap内データのエレメントデータについて
FrameMakerを利用したDITA案件が増えてきている。
１点今後のためにメモ。
ditamap内に定義される各種データに、２バイト文字が利用されることがある。
メタ情報の設定場所なので多々でてくる。
ditamapのデータは他のFMデータと同じようにしてテキストデータを取得できるのだが
ditamapデータはFMに投げ込まれた時にテンプレートとEDDが紐付いていることを
忘れてはならない。
ある要素の内容についてF_ApiGetTextなどを利用して取得するのだが
ditamap用のテンプレートで各要素に設定されているフォントが
２バイト文字に対応していない場合、プログラム側でどうやって
処理しようとしても必ず文字化けとなってしまい正しい値を取得できない・・・。
また、取得できたとしてもEDD側で要素に対してPrefixが設定されている場合
予定なテキストデータまでくっついて取得できてしまう。
ditamapに定義されているデータを表紙などに利用しようとする場合に
ditamapにはテンプレートとEDDが強く関連していることを念頭に
おいておかなければならない。
単なる各種ditaデータへのパスが定義されているMAPデータではないということ
FDK Reference … dita
FrameMaker12 以降 ditaという点ではかなり頑張ってきたFrameMaker
カスタマイズ用にFDKも公開されており活用させていただいています。
が…マニュアルが英語なのは仕方がないと思っていますが
dita関連のメソッドやプロパティなど利用できるのであれば
FDK Referenceにはしっかりと記述して欲しいものです。
いくつかのプロパティやメソッドはReferenceには書かれていないものの
実際にはAPIが用意されていました…。
Adobeさんにはドキュメント類のアップデートもお願いしたいと思います。
FrameMaker DITA 表の列幅
FrameMakerで用意されているDITA用構造化アプリケーションだが、
FMファイル上で指定した表幅をそのまま維持したい場合、つまり
表列幅の実サイズをdita、XMLに書き出したい場合は
デフォルトで用意されている構造化アプリケーションのRWルールを
書き換える必要がある。
Rwルールファイルの最後の方に以下の一文があるので
これをコメントアウトする。
writer use proportional width;
これをコメントアウトすることで
tgroup要素直下のcolspec要素のcolwidth属性の属性値に
実サイズがインチで出力される。
※ インチ以外の出力は無理…。
デフォルトの場合は表幅に対する比率がcolwidth属性に指定されることになっている。
pgwide属性を利用することが想定されているということ。
2016.02.02 追記
dita側でcolspec要素を設定して各列の幅を指定するも、テンプレートに充てて構造化データとしてレイアウトされると
colspec要素が邪魔となって表のレイアウトが崩れてしまう…。RWルールでcolspecをdropするとエラーも崩れもなく
表レイアウトされるが、幅の指定がpgwide頼みとなってしまい列幅が均等になってしまう…。解決先を模索中…。
Oxygen XML WebApp
ブラウザベースのXML編集に関してはCKEditorやJQueryを利用したモジュールで構築していることが殆どでしたが
oXygen XML WebAppを利用したシステム構築を検討中です。
demo はこちらです。
https://www.oxygenxml.com/webapp-demo-aws/app/oxygen.html
SDKも公開されているので、細かい部分を調整してかなり便利で安定したEditorに仕上げられそうです。
編集中のツリー表示ができればさらに良いのでこのあたりはJQueryを利用してモジュールを組み込みたいですね。
PowerPoint VSTO
PowerPoint VSTO 開発
プロジェクトの初期設定や開発に際しての入り口がプラグイン開発は難しいところですが
取っ掛かりが見つかるとリファレンスを見ながらある程度スムーズに開発は
すすみます。Excel,WordにしろVSTOを利用した開発案件の際には是非一度お声掛け
いただければと思います。
Xpath ロケーションパス（開発メモ）
<p>aaaaaaaaaaaaaaaa<graphic src=”インライン用画像”/>bbbbbbbbbbbbbbbbb</p>
<p><graphic src=”通常画像”/></p>
上記のようなXMLがあった場合にXSLTスタイルシートでPタグ中のテキスト部とgraphicタグ部を
分割して処理させる。しかし、同じグラフィック要素でもインライン用の用途と通常画像用の
グラフィック要素が存在している。
この場合、スタイルシート側では同じgraphicテンプレートでインライン用の処理と
通常用の画像処理を定義してやらなければならない。
この分岐をするためにXPath で ロケーションステップを書く時に以下の
工夫が必要だった。
following-sibling::text()
preceding-sibling::text()
この書き方でgraphicタグの前や後ろにテキストノードがあった場合は
インライン用の画像処理をするという命令を定義した。しかし、
following-sibling::text()はうまく動作するものの、なぜか
preceding-sibling::text()は動作しない･･･。(プロセッサはXerces)
<xsl:when test=”parent::node()/child::text() != ””>
この定義でまかなおうとするがこれでもダメ
<xsl:when test=”normalize-space(parent::node()/child::text()) != ””>
前後のスペースをトリムしたらうまく動作する。なぜ･･･。苦労した･･･。