FrameMaker と RoboHelp , レイアウトおよびEPS画像が荒くなる問題
RoboHelp は Adobe の製品で、MS-WordやFrameMakerのドキュメントを
各種ヘルプ(MS-Compiled HTML Help,Web Help,Flash Help,Eclipse Help, etc...)
に変換するためのツール。
Adobe Technical Communication Suite 2
にFrameMakerとRoboHelpが含まれていることからわかるように
Adobe は FrameMakerとRoboHelpを連携利用することを想定しています。
単にWordやFrameMakerで作成したドキュメントをヘルプに変換するだけでなく、 RoboHelp上で、 ヘルプトピックを新規に作成/編集もできますから、 単体で、 ヘルプを作成するツールとしても使えます。
ヘルプ化したときにFrameMakerのDTPレイアウトはどのくらい維持できるか
実際にFrameMakerデータをRoboHelp経由でヘルプへ変換してみると、
FrameMakerで設定している
レイアウトやスタイルを維持してヘルプトピックを生成してくれます。
ただし、これはFrameMakerのDTPがまともな場合です。
たとえば、非構造化FrameMakerのDTPデータの中には、
独立テキスト枠を複数設定してページレイアウトを行うという
InDesign的発想でDTPしている場合がありますが、
そういうダーティなデータの作り方の場合は、結果はかなりひどいことになります。
ほかにもNGパターンがいくつかあります。
さらに、ヘルプトピックが基本的に HTML+CSS を使ってレイアウト/スタイル付けされるという点も ポイントです。 FrameMakerのようなDTPで常識的に指定できるレイアウトがすべて HTML+CSS で再現できるわけではないので、 レイアウトエンジンが異なっていることから生じる問題まで RoboHelp は面倒を見ません。
この辺はドキュメントを内容と表現にわけて考えるXML的発想でいえば、避けられない問題という認識が常識だと思います。 将来ヘルプが使用するレイアウトエンジンがFrameMakerやWordに追いついた段階では解消される はずなので、DTPはむしろ内容あったデータ構造を持たせる方向を目指すべきです。 結果として、現時点では、 表現力の貧しいレイアウトエンジンを使っているヘルプで、 十分にレイアウト/スタイルが維持されないのはいたしかたない、という考え方です。
それは、携帯電話でWebを閲覧しようとした場合を考えればわかる話です。
しかし、FrameMakerとヘルプ(MS Compiled HTML Help や Web Help 等)はどちらもPC上で閲覧するため、 ヘルプに変換したときに表現が貧弱になる・レイアウト/スタイルが維持できないということを 残念ながらお客さまは理解できないようです。
お客さまに 理解していただくのが難しいだけでなく、 納得を得るのは到底無理なような気もしますねorz
EPSの問題
次は、 RoboHelp のEPS画像変換についてです。 レイアウト崩れは致し方ない(または別の方法で回避する)としても RoboHelp で納得がいかないのが、 FrameMaker上で使用しているEPS画像をヘルプに変換したときにかなり劣化してしまう、という問題です。
デフォルトの変換設定でEPS画像をヘルプの画像(PNG,JPEG等)にRoboHelpで変換させると、 かなり劣化してしまいます。 試しに EPS データを手動でIllustratorを使って PNG に変換したところ、 かなりきれいな画像を得ることができました。
しかし、画像点数が多いので、一枚一枚Illustratorで手作業変換するわけにもいかないし、 何かよい方法はないでしょうか。 (→GraphicsMagickを使えばOK)
元EPSデータを工夫する、というアプローチもあるのですが、 何をどう工夫したら RoboHelp は EPS画像をきれいに PNG 等Web画像に変換してくれるのか 見当がつかないのでこのアプローチはパス。
考えら得る方法
- 方法 A RoboHelpにデータを渡す前に手当てする
- 方法 B RoboHelp上で対処する
- 方法B-1. RoboHelp の中間生成ファイルをRoboHelpの外側で操作して対処
- 方法B-2. RoboHelp の画像変換部分の(なんとかして)カスタマイズする
方法 A による解決
RoboHelpにデータを渡す前に手当てする方式。
- 画像を EPS → PNG にバッチ変換する
- FrameMaker上で EPS から PNG に入れ替える(APIクライアントを使用) or mif上で書き換えるのもありかも
EPS→PNGバッチ変換自体は単純な話ですが、 画像ディレクトリがどこにあるか、など、 FrameMakerドキュメントを構成するデータレイアウト自体に依存するため話がややこしくなりそうです。
細かい話ですが、この方法でヘルプを作成してもデフォルトの画像変換設定(on RoboHelp)では画像荒くなります。 しかし、画像が荒くなる原因は、RoboHelpが Width,Height を指定しまうためです。 これを避けるには、、 RoboHelpの画像変換設定で、画像の幅と高さを 0 に設定します。
確か、RoboHelpのオンラインヘルプでもこんな解説があったと思う。
方法 B による解決
- 方法B-1. RoboHelp の中間生成ファイルをRoboHelpの外側で操作して対処
- 方法B-2. RoboHelp の画像変換部分の(なんとかして)カスタマイズする
こちらも試してみたのですが、方法B-1 については、 WebHelpのようにはじめから画像ファイルがセパレートな場合は問題ありませんが、 MS Compiled HTML Help のようにすべてのファイルが一つにファイルにアーカイブされてしまう形式の ヘルプでは、うまくいきませんでした。
MS Compiled HTML Help を生成中に作成される中間ファイルを操作できるような 仕様になっているとうれしかったのですが...
- いったん chm ファイルを decompile する手段は提供されている
- RoboHelpが作成する中間ファイルのHTMLに直接手を入れてしまう...ワークフローが複雑になるのでやりたくはない
RoboHelp以外のヘルプツール(Web Works,MadCap Flare とか)では、この辺どうなんだろうか。
方法B-2 はもっともスマートに問題を解決できるのですが、 問題は、RoboHelpがそのようなカスタマイズができるつくりになっているか(Developer's KITのようなものがあるか) という問題です。 RoboHelpはスクリプトで処理の自動化が可能、ということは説明されているのですが、 画像変換エンジン自体をプラグインできるような話は表面に出ていないので、これから調査ということになります。