DITAのPDF出力のplug-inを作るときに必ず出てくる問題に、共通画像の処理があります．
一般的には文書に特有な画像は文書と一緒にCMSが管理していて、その文書をpublishingするときにCMSが同時にチェックアウトしてくれます．だいたい文書から見ると画像は同一階層となります．これは問題ありません．例えば<image href="GUID-92110092-F4A5-45EF-944A-B1E5EB0252EB.pdf" id="IMAGE_CBD3FADD4CA84969853DEF4B02ADF085"/>から<fo:external-graphic src="GUID-92110092-F4A5-45EF-944A-B1E5EB0252EB.pdf"/>を生成すればよいだけだからです．DITAインスタンス中に画像参照があるとDITA-OTが自動的に出力フォルダにコピーしてくれます．
しかし文書間で共通の画像、例えばnote要素につけるマーク画像のようなものや、文書の表紙の会社のロゴマークのようなものは、一般的にはプラグイン側に持たせます．そして日英で会社のロゴマークを変える時などは、publishするときにどれを使うか指定します．
問題は、これらの共通画像はDITAインスタンス中に含まれないので、自動的な出力フォルダへのコピーが行われないことです．
私はあるお客様のプラグインを作るときにCMSのベンダーの人から要請を受け、プラグインの持っている画像を出力フォルダにコピーするようにプラグインのbuild.xmlに記述を追加しました．CMS側は非同期にユーザーからpublishのリクエストを受け付けるため、テンポラリフォルダや出力フォルダもリクエストに応じて動的に決定されます．この出力フォルダに共通画像は必ずコピーされます．
最初はなんの疑問も持ちませんでした．でもそのうち共通画像の数がやたら増えてくると、テスト環境を自分のPCに作ると出力フォルダはこの共通画像だらけになります．そしてそのうち実際に使われるのはごくわずかという状態なのです．
これはあまり精神衛生上よくありません．DITA-OTのFOプラグインはどうしているのか？と思って見て見ると、
確かにこれなら共通画像のコピーは発生しません．でもこれでも冗長ではないか？と最近考えるようになりました．プラグインのフォルダからの相対パスで記述することさえ決めておけば、スタイルシートで画像の絶対URIを求めることは可能だからです．
例えば
file:/D:DITA-OT1.5.4/plugins/pdf5/xsl/dita2fo_bodyelements.xsl
<xsl:variable name="pluginUri" as="xs:string" select="string(resolve-uri('../', static-base-uri()))"/>
とすればこの例だと、file:/D:DITA-OT1.5.4/plugins/pdf5が求められます．
あとは、例えば画像のパスが
<xsl:variable name="noteImage" as="xs:string" select="'common-image/note.png'"/>
とでもなっていれば、
<xsl:variable name="noteImageUri" as="xs:string" select="string(resolve-uri($noteImage, $pluginUri))"/>
として、画像の絶対URIを求めるとこの値は
file:/D:/DITA-OT1.5.4/plugins/pdf5/common-image/note.png
になります．これから
<fo:external-garaphic src="{$noteImageUri}"/>
としてやれば、XSL-FOがどこに作られようとも安心して共通画像を絶対URIで参照できます．つまりプラグインに対するパラメータも不要だし、共通画像のコピーも不要になります．決めておくことは、共通画像のパスをプラグインのフォルダに相対で記述するというルールだけです．
こんど機会があったらお客様に提案してみようかな？と思います．
＃これはあくまでもPDF出力の話です．HTMLの場合だったら必ず共通画像も出力フォルダにコピーしてやらねばなりません．
