framemaker
FrameMaker に挿入した画像がリサイズされているかいないかをスクリプトでチェックする方法(途中)
FrameMaker 文書を RoboHelp に変換するときに、 FrameMaker 上の画像がリサイズした状態で挿入されていると たとえそれがEPSであったとしても、RoboHelpで変換後のヘルプの画像品質が 著しく落ちてしまう。
そこで、ヘルプ化するFrameMaker文書に挿入する画像はリサイズなしの100%原寸で 入れていただくよう事前に依頼していたのだが、案の定守られていない。
数100ページもあるマニュアル中のどこが100%で画像挿入されているかいないかの 調査＆指示書をつくる必要があるのだが、手作業でチェックできない（する時間がない・予算もないし） ので機械的にスクリプトでチェックを試みました・・・という話。
このエントリーは書きかけです。 mif 中にある情報で、リサイズしていれているかどうか把握できると思っていたのですが、 ここに書いている方法で調べても、すべての画像ファイルが100%で入っているという結果しかでなかった。 どうやら、もとのEPSデータから画像サイズを計算して、mif上に記述されている サイズと比較する必要があるようです・・・
なぜかヘルプのフォントが明朝になってしまう問題の回避, FrameMaker + RoboHelp
原因わかりました。
FrameMakerのデフォルトのフォント設定がMS明朝になっていたのが原因。 デフォルト設定をMSゴシックにすることで問題が回避できた。 (というか、環境にFMドキュメントで使用されているフォントがないことが本当の原因なのだが。)
FrameMakerで新ゴとか、標準環境にないフォントを使っているからなのかは、 まったく不明なのだが、FrameMakerデータをリンク形式で取り込んでRoboHelpでHTMLを 出力すると、フォントが明朝になってしまうのだった。
状況によってはゴシックになったりして、どこでどう設定されるのか、設定の流れが わかっていないのだが、最終的なHTMLヘルプ直前のHTMLや画像,CSSが置かれている RoboHelpの作業ディレクトリを見ると、hogehoge.css というファイルがある。
この中身をチェックすると MS 明朝 が指定されている。
解決方法としては、この RoboHelp が自動生成する css ファイルを手動で上書きしてしまえばよいと。
MIF ファイル中から特定のマーカーだけを取り出す(FrameMaker,RoboHelp)
特定の種類のヘルプマーカを標準出力する方法のメモ
MIFから段落スタイル名を抽出する (FrameMakerの話)
RoboHelpでFrameMakerデータをリンクさせると、 RoboHelp側でFrameMakerに存在している段落タグの一覧が確認できる。 便利だなと思ったが、その一覧をテキストデータ化する方法は RoboHelp上では提供されていないようなので、自分でMIFから抽出するコードを書いた。(groovyで)
EDDでテキスト範囲に指定したフォントが反映されない問題を MIF上で解決する
構造化FrameMaker8の話。 EDD上でテキスト範囲指定している要素に対して、合成フォントやフォントファミリを指定しても 有効にならない。合成フォントでは、EDDの指定自体が反映されないようだ。 (再度構造化ツールでEDD書き出ししたときに指定が無効になっていないかで確認)
以前の自分の調査によれば...
継承元の段落書式に合成フォントを指定するとNG になるらしい。 逆に合成フォントを継承元の段落書式に設定していなければ、 EDDでテキスト範囲に対して行った書式設定は有効かされると...
というメモを見つけた。（この内容が真実かどうかは現時点では未確認です。）
ただFrameMaker GUI上で直接該当要素(この例では markup)に対して 合成フォントを指定してやればきちんと有効になる。
そこで、今回はMIF上でこのGUIで行ったのと同じ操作を行うことにした、という話。
こんな対処をしなければならないのはレアケースだとは思いますが、 EDD+テキスト範囲指定にはいままでもいろいろ苦しめられてきたので、メモとして残します。
Adobe FrameMakerでXMLを開くときにありがちなXML変換のためのXSLT
FrameMakerでXML文書を開く前にXML変換して、 変換後のXMLをFrameMakerでフォーマット、というのが定番ですが、 このとき必ずといって良いほど使用するXSLTコードをメモ。
MIF 上で EPS 画像を PNG に置きかえる方法( Adobe FrameMaker の話 )
Adobe FrameMaker ドキュメント中に含まれる(参照で挿入している) EPS 画像を PNG 形式の画像に まとめて入れ替える方法。
単純に foo.eps を foo.png に置換すればOKと思ったのだが、そこまで簡単ではなかった。 (のでメモ)
Adobe RoboHelp Howto, FrameMakerファイルをリンクしたときに 相互参照を設定する方法
FrameMaker ドキュメントを使って RoboHelp でシングルソース方式(リンク方式)でヘルプを作成する場合に、 FrameMaker で作成した相互参照を ハイパーリンクにするにはどうすればよいか、という話。
Adobe RoboHelp Howto, FrameMakerファイルをリンクしたときに トッピックの区切り指定方法
FrameMakerドキュメントを使って RoboHelpでシングルソース方式(リンク方式)でヘルプを作成する場合に、 ヘルプトピックの区切りをどうやってFrameMaker側で設定すればよいか、という話。
ヘルプ側から見れば複数のヘルプトピックが 一つの fm ファイルに入っている状態になっている。 これをどうやって別々のヘルプトピックに分割すればよいのか。
方法は２つあり、後者のマーカを使った方法の方がコントロールはしやすい。
RoboHelp の EPS 画像の扱い方→ RoboHelpで生成した画像が荒い
Adobe RoboHelp 8 のヘルプの項目 画像変換設定 には以下の行がある。
FrameMaker 文書には、EPS形式の画像が含まれています。オンラインヘルプ用に、 EPS 画像を、JPEG、GIF、PNG などの Web でサポートされている画像形式に変換します
これってEPS画像をサポートしている、としか読めないよね。 でも、実際に試したところ、EPS画像をサポートしているのではなく、EPSに添付される低解像度プレビュー画像を サポートしているだけっぽいのだ。
ただし、大島の環境に何かも問題があったとか、FrameMaker側での EPS 画像の配置の仕方に問題があったとか、 RoboHelp は本当は EPS に対応しているのだが、大島のやり方/環境によって結果としてうまくいっていないだけの可能性もあるので その点はご了承ください。
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上で、 ヘルプトピックを新規に作成/編集もできますから、 単体で、 ヘルプを作成するツールとしても使えます。
XML Round-Trip 方式による FrameMaker アプリケーションの開発
Adobe FrameMaker + XML のアプリケーション開発では、 One-Way 方式と Round-Trip 方式があります。
- One-Way 方式は、内容をXMLで制作してそれを FrameMaker でフォーマットします。
- Round-Trip 方式は、XML文書とFrameMaker文書の両方で内容・スタイル等を変更でき、XML→FMだけでなく、FM→XMLに書き戻すことができます。
つまり、Round-Tripは いったんFrameMakerで開いてフォーマットした fm データをもう一度XML文書として 保存することができる形のFrameMakerアプリケーションということです。 この方式では FrameMaker上で変更した内容・レイアウト／スタイルに関する情報をXML文書に戻すことができることになります。 (どの変更内容までをXML文書書き戻しサポートするかは、FrameMakerアプリケーションによってまちまちです。)
XSLTで子要素(テキスト)を属性にする記述、およびその逆変換
このXSLのイディオムはあまりによく使うのでメモ。
MIF翻訳の調査 S-Tagger for FrameMaker を利用
SDL Trados 2007 に付属している S-Tagger for FrameMaker を使って、 MIFを翻訳するという話。
以前調査したときはネットに情報がなく困ったなと思っていたが、 SDLのサイトに SD Trados S-Tagger ユーザーガイド をダウンロードできるページがあり（たくさんの項目、個人情報含む、を提供しないと ユーザーガイドが手に入らないのはどうかと思いましたが、そもそも Tradosインストールしたらこの手のドキュメントも含まれているのが普通だろうと思うのだが） ここからユーザーガイドを入手して読んだところ、問題なく処理できることがわかりました。
プロフィール
大島友明
名古屋市在住のプログラマ。
突然いまさらTwitterのすごさに開眼！ってでもいまのところフォロワーが増えないのが悩みの種。
Twitterはライフログとして使うんだからいいのさ、と自分にいいわけ。
（あとはiPhoneかAndroidがあって24時間Twitterできればね。）
気軽にフォローお願いします。
現在のところ 仕事のメインは構造化FrameMakerおよびFDK。
FrameMakerに特化したブログサイトも運営中ですよろしく。 http://www.my-notebook.net/
繁体字フォントをEDDで指定しているにもかかわらずMS明朝でオーバライドされるという問題（構造化FrameMaker8）
半年ほど前に、 EDDでフォントをArial指定しているのにＭＳ 明朝になってしまう、という問題 というエントリーを書いたのだが、 その問題をそのまま放置していたところ、 今回、中国語の繁体字指定したEDDを使ってXMLをFrameMaker8で開いたところ、 繁体字フォント指定がほとんど反映されないで、ほぼすべてがMS明朝になってしまった。
今回はそのエントリーに書いた以下の部分を簡単に解消できるツールをつくりました。
方法としては、FrameMakerのGUI上で処理してもよいし、mifにいったん保存して、 該当箇所の書式上書き設定記述を削除することでも解消できる。
結論としてツールだけを入手したい場合はこちらです。
Adobe FrameMaker FDK, 構造化されたドキュメントの要素を順にたどって要素の属性を列挙するAPI Client
DocbookXMLで内容を記述し、それを構造化FrameMakerでフォーマットしている。
フォーマット（スタイル）の指定のほとんどはEDDであらかじめ指定しておけばよいのだが、
仕上げの段階の「詰め」の作業などで、どうしてもスポット的に行間を狭めたり、長体をかけたり、という
例外的なフォーマット指定を行う必要が生じる。
これをタッチアップと称して、FrameMaker上で手作業で行うのだが、
この手作業の結果は、次にDocbookXMLから再度フォーマットし直したときに失われてしまう。
(ラウンドトリップして、FrameMakerからDocbookに再度書き戻せられれば問題ないのだが、そうなっていない。
というか、Docbookにはスタイルを記録できる要素や属性は定義されていなから基本的には無理なわけだが...)
したがって、フォーマットのたびに毎回同じ手作業による修正が発生してしまいます。
前置きが長くなりましたが、このタッチアップを少しでも減らすために、 DocbookXMLをFrameMakerで開いたときに各要素に埋め込まれたスタイル指定情報(※)を読み出して そのスタイル適用するAPI ClientをFDKを使って書いてみようと、そういう話です。
※もちろんDocbookXMLにはスタイル情報を記録できる要素や属性はないので、ちょっとしたトリックを使う必要はあります。
まだ道半ば（もいいところなの）ですが、まずは、構造図に表示される要素ツリーを順にたどって、 各要素の属性を取得するところまで作動するものができたので、ここにメモしておきます。
Adobe FrameMaker FDK, 構造化されたドキュメントの要素を順にたどって要素の属性を列挙するAPI Client(C++版)
C++版
Adobe FrameMaker FDK 8.0 API Client を nmake を使ってコマンドプロンプトでビルドする方法
FDK 8.0(FrameMaker Developer Kit
を使って作成するAPI Client はVisualStudio2005 の使用してビルドする。
通常、VisualStudio2005 は GUI上で開発・ビルドを行うが、
わたしがつくっている程度の小さなC/C++プログラムでは、わざわざGUIを起動するのが面倒。
面倒というより、そもそもコーディングも vim でやっているので、ビルドするためだけに
VisualStudio2005 の重いGUIを起動していることになる。
ビルドするだけなら、コマンドラインでMakeで済ませたい、と思って調べたところ、
標準でインストールされるVisualStudio2005 コマンドプロンプトを使って
namke(というMicrosoftが提供している) make ツールを使えばよいことが判明。
VisualStudio2005をインストールすると一緒にインストールされる VisualStudio2005 コマンドプロンプトは、通常のDOSプロンプトと異なり あらかじめ C++ プログラムをビルドするのに必要な環境がセットアップされている。
Jython で javax.swing.JTree を使う
Jython ではほとんどGUIのコードを書くことはないのだが（個人的には） Jythonで処理しているデータを可視化して、あっているかどうか確認する場合には SwingによるGUIは非常に重宝する。
例： 構造化FrameMakerでDocbookから本をつくる場合で、索引ページを本文から生成する場合などに DefaultMutableTreeModel を使用している場合の可視化
JTreeをJythonから使う方法のメモ。
ひらがなの濁音を清音に変換するには
ドキュメントの最後につける索引ページ、その索引タームのソート問題で、 今回は、濁音は清音に変換した状態でソートする必要がある。 どうすればいいか。
索引ソートの実際の全体の作業ステップとしては以下のようになります・・・
- 索引タームを抽出
- 索引タームが漢字カタカナひらがな混じりなので、ひらがなだけのよみに変換
- 濁音を清音に変換
- ソート
これだけが必要になります。
索引ターム自体の「漢字カタカナひらがな混じり」を「よみ（カタカナ・ひらがな）」に変換するには、 たとえば、YahooWebAPIを使います。（茶筅や和布蕪、KAKASIなどでもできると思いますが）
その後、YahooWebAPIで得た「よみ」はカタカナも含まれているので、カタカナをひらがなに変換します。
さらにひらがな中に含まれる濁音を清音に変換します。
すべて準備ができたらソートします。 （ソートはJavaやPythonを使えば簡単です。）
今回は、このステップのうちの濁音を清音に変換する部分の説明です。
構造化FrameMaker8 下矢印（downwards-arrow-sign, U+2193）がMS明朝になってしまう問題の回避
Structured Frame Maker 8 で xml をフォーマットすると、下矢印文字(U+2193)が EDDで Arial指定しているにも関わらず、なぜか書式がオーバライドされてしまいMS明朝になってしまう。
そんな場合の回避方法。
構造化FrameMaker8 EDD PrefixRules のトリビア... less than sign はそのまま使えない
納品条件はFrameMaker7 なのだが、
制作時は都合により FrameMaker8 を使っている。
しかし、納品時に、FM8 から FM7 にダウングレードすると特殊文字が文字化けが発生してしまう。
おそらくは、FM8からは内部もユニコードに対応、FM7までは内部は独自のコード体系を
持っているとかいった話と関係がありそうだが、対処方法がわからない。
ブック中のすべての fm ファイルを開く(Adobe FrameMaker8 FDK Client)
先ほどの tomif.cを流用して作成。 単に、ブック中のfmファイルを全部開くだけのクライアント。
ブックを印刷するとき、全部開いたまま行うと高速に処理できる・・・と
（記憶では）
ヘルプに書いてあったので...
たとえば、そんなときに役立つクライアント。
これで、ちまちまファイルを開く手間を省けます。
ブック内の fm ファイルを mif 形式で保存する(Adobe FrameMaker8 FDK Client)
仕上げ処理で、mif ファイルに対して一括処理をほどこすことがよくあります。
（小口に配置するツメの位置を章ごとに移動させる、など）
構造化FrameMakerでは、仕上げ段階では、XML文書からブックを生成しますが、
こうしてできた個々のファイルの形式は fm です。
この fm ファイルをひとつずつ開いて mif 保存しているのは苦痛なので
自動化しました。
処理内容は、ブックファイル中の fm ファイルを列挙して、 mif 拡張子を持つファイル名文字列を生成してから、 mif 形式で保存しているだけです。
保存形式の指定で FV_SaveFmtInterchange80 を使うのがポイントです。 もし、FV_SaveFmtInterchange を使うと、FrameMaker7 形式の mif になるようです。 FM8のfm形式ファイルを FM7 mif 形式に保存すると、 ユニコード関係で一部文字が化けることがあります。
現在開いているファイルを fm 形式で保存する(Adobe FrameMaker8 FDK Client)
先ほどの続きで、いったん mif 形式で保存して処理をした後、 再度 fm 形式で保存するときに使うことを想定したFDKクライアントです。
ただやっている内容は、現在開いてるファイルを全部取得して、パラメータとして、 FV_ModeSaveAs を指定して fm 拡張子で保存しているだけです。
EDDでフォントをArial指定しているのにＭＳ 明朝になってしまう、という問題 ... 一応 解決(Adobe FrameMaker)
構造化FrameMakerの話。
簡単に言えば、XMLをFrameMakerで開いてフォーマットしたときに、 EDD上で、TextRange指定した要素に対するフォント指定などの書式設定が上書きされて意図した書式設定がされない問題。
EDD設定は通常はCSSと同じように親のスタイルがカスケードされて子要素に反映されつつも、 子要素で設定された書式は優先されるはず・・・ 少なくとも、経験的にいって、 TextRangeではなく、ParagraphFormat 指定している場合はそのようにEDD(書式)設定が反映される。
しかし、今回の問題は、本来優先されるはずの子要素での書式設定が上書きされてしまう、という問題。 しかもどこにも指定していないはずのMS明朝が出現してしまう。
解決方法としては、書式のオーバライドを無効（元に戻す）にすればよい。 FrameMakerのGUIを使って、書式の上書きを削除するか、mifを経由して（いったんmif保存して） 上書きが起こっている箇所を削除することで問題が解消できる。
アクティブブックドキュメント中のfmファイル名を順番に取得する方法(Adobe FrameMaker8 FDK)
前回 は fmファイルを開いているときにそのファイル名（パス）を 得る方法を調べた。
その応用で今度は book形式のファイルを開いているときに、 そのbook内に含まれるすべてのfmファイルのファイル名（パス）を順に取得してみる。
AdobeFrameMaker8 FDK Bookを開いているとのメニューバーと通常のメニューバー
FDKを使うまで意識したことがなかったが、 bookがアクティブになっている場合のメニューと 通常のメニューは別になっていることが判明。
アクティブドキュメントのファイル名を取得する方法(Adobe FrameMaker8 FDK)
FDKを使ってやりたいことは、Book中のすべてのfmファイルを、mifファイルとして保存したい、 しかも拡張子だけ fm から mif に変えてファイル名のベース部分はそのままに。
しかし実際に取り組んでみると、そのためにはまだまだ道程は遠い。 まずは、アクティブドキュメント(fm形式)のファイル名を取得するところまでできたので、 そのメモ。
Adobe FrameMaker8 FDK 最初の一歩
FDKは、 CやVisualStudioの操作に慣れていないと、なかなか敷居が高い。 以下は、FDKのとっかかりのメモ。
YahooWebAPI"日本語形態素解析"を使って日本語文をひらがなに変換、索引用語のソートに利用
Adobe FrameMakerでの索引作成をしているのだが、 索引用語のソートをしなければならない。 しかし、索引用語は漢字混じりなので、よみ情報を付加しないと、ソートは できないどうすればいいのか（よみ情報を追加するのはとても面倒なので...なんとか楽できないか） という話。
このエントリはPythonを使っていますが、 Javaを使う場合は こちらのエントリ(Yahoo Web API 日本語形態素解析サービスをJavaから使う)をご覧ください。
StructuredFrameMaker テキストの回り込みの解除トリック
FrameMakerで画像とテキストのレイアウトしている場合で、 画像をRunin(段落内)扱いで配置した場合、 テキストの回り込みの解除方法がわからない。
HTMLのCSSで言えば、clear:both; に該当するスタイル指定をEDDなどでできないのか？ と思うのだが、今のところその方法がわかっていない。
そこで、いままでは、無理やりに強制改行または空行を追加して、 縦スペースを確保することで、見た目上テキストの回り込みを回避していたのだが、 この方法はいろいろと不都合が多い。
FrameMaker で横見出し領域(side head)の設定方法
横見出し領域を使うと、インデントレイアウトの管理が楽になる場合が多い。 特に手順を説明する場合の手順番号だけを付き出しインデント扱いしたい場合に、 重宝します。
mif2xml ... mif を XMLに変換(FrameMaker,jython)
Structured FrameMaker はルールベースで、レイアウトを作り出せるので、 ページ数が多いドキュメント作成に重宝しますが、 テンプレートのマスターページ管理が気に入りません... 具体的には以下の通り。
少しだけ異なるマスターページを管理する方法(Structured FrameMaker)
ツメの位置だけが章別に異なる場所にレイアウトされるものの、 その他部分は完全に共通なテンプレート（中のマスターページ）を 管理したい。
共通部分に変更はいつ入るかわからない。 もし、 マスターページを単純コピーして作成すると、 共通部分に入った変更をコピーした分だけ繰り返し入れる必要が生じてしまう。
こういった作業は単に精神的に辛いだけでなく、発見が難しいヌケモレ系のミスを 引き起こし品質上の問題になる。
ではどうすればいいか？
段落書式でフォント SimSun で指定してもMS明朝になってしまう問題その２(Adobe Structured FrameMaker8)
XML文書(Unicode,UTF-8)をFrameMaker8に読み込んでフォーマットして印刷用データを作成している。 しかし、多言語展開時に中国語（簡体字）の対応をしていて困ったことになってしまった。
FrameMakerのテンプレートで段落書式（本文）に SimSun を設定しているのに、 XML文書をそのテンプレートを使ってフォーマットすると、なぜか段落書式（本文）の 一部がMS 明朝に変わってしまうのだ。 全部 MS 明朝になるのではなく、設定通り SimSun になっているところもある。
他の言語展開（ドイツ語・フランス語・スペイン語など）ではこのような現象は起きないので （もっともそれら言語で使用してるフォントは Times New Roman だが）なんでだろうと。
いろいろ調べてみたものの原因がわからないので、 以下の方法で対処しました。
構造化FrameMakerでインライングラフィックを扱う方法
XML文書をFrameMakerに取り込んだときにグラフィック要素が、インライン上に配置されるように するにはどうしたらいいかの調査記録です。
DocBook + FrameMakerによるドキュメント制作、作業環境の構築
DocBook,FrameMaker,XMLを使って作業をしていると、
XMLインスタンスからDTDを作成したり、XSLTで変換したり、
XMLを読みやすい形式でインデント付けたり・その逆（不要なスペースの削除）、
といったことを頻繁に行います。
これらをCygwin上で簡単に実行できるようにコマンド化します。
構造化FrameMaker ... 目次用 XMLのフォーマット
構造化FrameMaker(Structured)には目次作成機能が付いていますが、それを使わないで、
事前にFrameMakerにXMLインポートするの前段階の処理として目次用のXMLを生成(というか、XSLTを使って変換)
してから、FrameMakerでフォーマットするという方法があります。
その場合、目次項目のパラグラフフォーマットをEDDで指定する方法がわからなかったので調査しました。
構造化FrameMaker 相互参照(cross-reference)の作成
構造化FrameMaker上での相互参照は、かなり簡単に実現できる。
- 参照元となる要素に id 属性を入れておく
- 詳しく調べていないが、おそらく属性名は id とすべきだと思う（どこかで指定できるのかもしれないが）
- 参照先に xref といった要素を置く（おけるようにDTD,EDDを設計）
- xref 要素は、EDD上で CrossReference として定義する必要がある→通常は Container だがそうではなく CrossReference
※注意点
参照先は、すべての要素の id 属性を調べているだけなので、 id の値はドキュメント中でユニークにする必要がある。 chapter, sectionなど異なる要素の id でも重複は許されない。
構造化FrameMaker グラフィックを取り扱う方法
構造化FrameMakerでグラフィック(イメージ)を扱う方法。難しくはないがひどく手順が面倒ではある。
構造化FrameMaker の基本的な開発・制作ワークフロー
ドキュメントを多言語で展開するために、いままでは、 InDesign+XMLを使って対処してきたが、 今度はFrameMaker+XMLの組合せで制作することになった。
FrameMaker(Structured)は、SGML時代から存在しているツールであり、
XMLを使った多言語展開には、InDesignよりずっとうまく対応できる設計になっている。
とはいえ、
ページ数が少なく、レイアウト要求が厳しい場合には、
やはり、InDesign+XMLの方がやりやすいと感じる。
EDDによるスタイルコントロールは、すこし気が重い。
DocbookのXMLから目次情報を抽出する toc.xsl の作成(改良版→番号の追加)
前回 Docbook で記述されたXML文書から目次情報の抽出をしましたが、 章番号やセクション番号がない状態だったので、今回はそれを追加します。
DocbookのXMLから目次情報を抽出する toc.xsl の作成
今回は、Docbookで記述されたXML文書から目次情報だけを抽出してみます。
テストで処理対象としたXML文書は、 こちら(Apache Velocity DocBook Framework ) から入手できる DBFUserGuide.xml を使用します。これは、Docbook4.5を使って記述されています。
Relaxng ... div と para 要素が任意の回数出現してよいという制約を記述する方法 →choice を使え
構造化FrameMaker での XML-Round-Trip のために DTD を自分で書かないといけない。 DTDを書くのは辛すぎるので、RelaxNGを書いてこれを変換してDTDとして使おうと。
今回は、div,para要素が 0回以上任意の回数出現していい、という制約を指定する方法。
Trangを使って、DTDを簡単に作成する(FrameMaker,InDesign)
XMLデータからDTDを作成するには trangを 使用すると簡単に作成できます。 完全に自分が意図したDTDにするには、Trangで得た出力からさらに修正する必要がありますが、 InDesign+XMLで使用するような簡単なXMLを扱う場合は、ほとんどこれで十分です。
※Trang は、構造化FrameMakerのEDD作成のための前処理でDTDを作成するときにとても便利です。
→ 構造化FrameMaker の基本的な開発・制作ワークフロー
自動組版を前提に考えた場合の InDesign と FrameMaker との比較
FrameMakerとInDesignを使って自動組版をすることについて ここ一年くらい具体的にマニュアルの制作にも関わりつつ検討している。
いずれも内容をXMLで表現し、それをFrameMaker/InDesignを使って、 自動的に（ルールベースで）レイアウトしていく、というアプローチを取るのだが、 両者はかなり得意分野が違う。
全体的に言えば、ページ数が多い印刷物の場合はFrameMakerが有利で、 それ以下であれば、レイアウトの柔軟性や最悪手作業でDTPになったとしても ちからわざで対応可能、という意味で、InDesignが有利な場合がある。
InDesignのうれしいところは、 InDesignは FrameMakerにくらべて 後発ということもあり、拡張しやすいという点です。
DOMっぽくJavaScriptでInDesignドキュメントにアクセスできますから。 FrameMakerのFDK経由でのAPIはDOMっぽくない、と思う。
一方、制作ビジネスとしてみた場合、 コストパフォーマンスを考える必要がある。
普通に考えると、 FrameMakerが得意とする領域の印刷物制作に、 InDesignをカスタマイズして使用すると、カスタマイズ分だけコストアップ要因になるので、 InDesignで対応できるからといってそうすべきではない。
しかし、ビジネスでは制作の都合以外に検討することがたくさんあって、たとえば...
- 単にお客さんがInDesignを好むから(顧客説得コストの問題)
- 制作する人を募集するときに、FrameMakerを扱える人が少ない・単価が高い(人的コストの問題)
とか、そういう理由によって、どちらを使うか決める必要が出てきます。
そんなこともまで考えはじめると、どこに最適解があるのか、混乱してきますね。 だから、ここでは、制作のことだけを考えることにします。
構造エラーはないはずなのにXML書き出しすると構造エラーが出る場合(FrameMaker7.0)...結論はコンディショナルのしわざ
FrameMakerデータをXML形式で保存すると、構造エラーが出る。 FrameMaker上では、構造図を見てもエラーはない（赤く表示されている部分はない）し、 メニューから 【エレメント-検証】を使用してもエラーは報告されない。 なにが問題なのだろうか？
FrameMakerにインポートしたXMLデータ文字化け対処方法
たとえば、ラテン文字のチルダ付aなどを含んだXMLデータ(UTF-8)を FrameMaker7.xにインポートすると文字化けが発生してしまう。
FrameMaker7.xでは、ユニコードを直接扱わないで、 各言語ごとの文字エンコードを使っているため、 たとえば、XMLデータがUTF-8でエンコードされたいた場合、FrameMakerに インポート時に文字の変換が行われ、 この時に文字化けが発生するようです。(あくまで推測ですが)
ちなみに、FrameMaker8では、FrameMaker自体がユニコードを 扱うため、インポート時に文字の変換が行われないため、 この手の文字化けが発生しないようです。