35 実装に関する考慮事項

この章では、Dynamic Converterを操作する際のより実際的な問題について説明します。

この章の内容は、次のとおりです。

35.1 マルチバイト文字のメタデータ・フィールド

新しいDynamic Converter HTMLテンプレート・エディタは、変換するテンプレートまたはコンテンツ・アイテムでのマルチバイト・コンテンツIDの使用をサポートしていません。Dynamic Converterをマルチバイト環境(日本語、韓国語または他のローマ字以外の文字)で使用する場合でも、コンテンツID、セキュリティ・グループ、コンテンツ・タイプおよびアカウント名にマルチバイト文字を使用しないことをお薦めします。このコンテンツ・メタデータ情報はコンテンツ・アイテムのURLに埋め込まれますが、現在のWebテクノロジの制約により、WebサーバーとWebブラウザではマルチバイト・キャラクタが含まれるURLは正しく処理されない可能性があります。(たとえば、Dynamic Converterはリンクが機能しなければコンテンツ・アイテムを特定できません。)

コンテンツID、セキュリティ・グループ、コンテンツ・タイプまたはアカウントでマルチバイト・キャラクタを使用する場合、Oracle WebCenter Content Server環境全体(サーバーとクライアント)が、マルチバイト言語をサポートするオペレーティング・システム(Microsoft Windowsの日本語版または韓国語版など)で実行されていることを確認する必要があります。

35.2 UNIXでのPDFファイルの変換

UNIXでのPDFファイルの変換には時間がかかり、3分後(変換プロセスのデフォルトのタイムアウト値)にタイムアウトする可能性があります。

変換タイムアウトの値を増やすには、次のようにします。

「Dynamic Converterの管理」ページを開きます。
「構成設定」をクリックします。
「Dynamic Converterの構成」ページで、「タイムアウト」フィールドに新しい値を入力します(デフォルトの3分より大きくします)。
「更新」をクリックして、変更を有効にします。

変更された設定はすぐに有効になるので、コンテンツ・サーバーを再起動する必要はありません。

35.3 UNIX上の埋込み画像

一部のソース・ドキュメントには、埋込みOLEオブジェクトが含まれています。埋込みOLEオブジェクトには通常、Windowsメタファイル形式のグラフィック・「スナップショット」が付随しています。Dynamic Converterは、WindowsとUNIXの両方で、メタファイル・スナップショットを使用してOLEオブジェクトを変換できます。メタファイルを使用できない場合は、Dynamic ConverterはOLEテクノロジで変換を行います。その場合の変換は、Windows上では成功しますが、UNIX上では失敗します。

35.4 ベクターおよびラスター画像形式の使用

ベクター画像を変換する場合、Dynamic Converterは実行中のXサーバーにアクセスする必要があります。これは、Dynamic Converterがピクセルの描画をXサーバー・システムに依存しているためです。

ベクター・グラフィック書式では、線と塗りつぶしを描画します。一般的な書式として、WMF、EMF、CorelDRAW、Adobe Illustrator、Excelのグラフ、WordのオートシェイプおよびPowerPointのプレゼンテーションがあります。一方、ラスター・グラフィックには、イメージのピクセル情報が格納されています。一般的なファイル形式として、BMP、JPEGおよびGIFがあります。

ベクター・グラフィックとラスター・グラフィックの違いを見分ける1つの方法は、イメージを拡大することです。ベクター・グラフィックは線を描画するので、線の配置が再計算され、イメージの見た目は変わりません。しかし、ラスター・グラフィックは、サイズを変更すると、ピクセルが見えるようになります。

UNIXでグラフィックのレンダリングとフォントを設定する手順は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』を参照してください。

35.5 UNIXでのベクター画像とスプレッドシート・テキストの変換

ベクター・グラフィックを変換する場合およびスプレッドシートの複数の列にまたがるテキストを正しく測定する場合、Dynamic ConverterはUNIXで実行中のXサーバーにアクセスする必要があります。

35.6 URLリライティング

Dynamic Converterは、すべてのリンクとイメージ・ソース・リンク(src)を、dcUrl('url', reserved_type) Idoc Script拡張関数でラップします。このスクリプト関数のデフォルトの実装は単純なパススルーを実行しますが、外部統合テクノロジ(CISなど)はフィルタ・プラグインdcUrlFilterを定義することによってこの動作を変更できます。

Dynamic Converterは、リンクURLを評価し、dcUrlFilterフィルタが存在する場合はそれを適用して、URL値を返します。dcUrlFilterフィルタが定義されていない場合、元のURLは変わりません。内部ブックマークへのリンクは常に変わりません。

予約タイプ

関数の引数reserved_typeは、1001、1002などの数値であり、Dynamic Converterコア・エンジンでURLが書き込まれる場所を示します。この値を使用して、URLのタイプを識別できます。たとえば、ギャラリ・グラフィック、ドキュメント間リンクなどです。予約タイプの値とその説明は、次のとおりです。

値	説明
1001	リンク(異なる分割)
1002	前の要素(異なる分割)
1003	前のページ(TOCフレーム)
1004	前のページ
1005	次のページ(TOCフレーム)
1006	次のページ
1007	次の要素(異なる分割)
1008	前のページ(TOCフレーム)
1009	前のページ
1010	次のページ(TOCフレーム)
1011	次のページ
1018	イメージ・リンク
1019	イメージ・リンク
1020	イメージ・リンク
1021	イメージ・リンク
1022	背景画像(非ソース由来)
1023	背景グラフィック(ソースから)

35.7 テンプレートおよびレイアウト・ファイル内の相対URL

イメージ・タグ<IMG SRC="image.gif">について考えてみます。Dynamic Converterの多くの実装では、出力ファイルは通常、テンプレート・ファイルとは異なる場所に作成されます。そのような環境で開発者が前述のタグを含むテンプレートを使用した場合、出力ファイルにimage.gifへの参照が含まれることになり、ブラウザはそれが出力ファイルと同じパスに存在すると想定します。問題は、image.gifがおそらくテンプレート・ファイルと同じ場所に存在するということです。これは、テンプレート内のすべての相対URLによる参照で問題になります。この問題に対して考えられる複数の解決策を次に示します。

解決策1: 参照が正しいことの確認

すべてのテンプレートでどのファイルが参照されているかを開発者が正確に認識している場合、正しいファイル(image.gifなど)を(1つ以上の)出力ディレクトリに移動または配置できます。この解決策を実行するには、開発者がテンプレートの内容を正確に知っている必要があり、同じファイル・セットが多数の出力先に伝播される可能性があります。

解決策2: 絶対URLの使用

開発者は、どの参照ファイルに対しても絶対URLが含まれるようにテンプレートを設計できます。例のテンプレートは、次のようなものになります。

<HTML>
<BODY>
<P><IMG SRC="http://www.company.com/templates/image.gif"></P>
{## INSERT ELEMENT=Sections.1.Body}
</BODY>
</HTML>

かわりに<$HTTPWEBROOT$>を使用すると、特定のドメインに関係する出力ファイルの問題はなくなります。

解決策3: 別のファイルでのパス文の作成

開発者は、次の例のように、パスを指定する別のIdoc Scriptファイルを作成できます。

<@dynamichtml Image_Dir@><$HttpWebRoot$>groups/public/documents/graphic/<@end@>

開発者は次に、Idocリソースおよび参照に、組み込まれたIdoc Scriptファイルのパス文を次のようにロードできます。

<img src="<$include Image_Dir$>logo.gif">

グラフィック(または関連ファイル)が、記述されているパスに一致するセキュリティ・グループとドキュメント・タイプ(この例ではセキュリティ・グループPublicとドキュメント・タイプGraphic)でチェックインされているかぎり、パスが解決され、ページは正しく表示されます。

35.8 ブラウザのキャッシュ

テンプレートを作成およびデバッグする過程ではおそらく、テンプレートを少しずつ変更しながら、同じソース・ファイルを繰り返しDynamic Converterで処理します。出力ファイルの名前の付け方によっては、同じファイル名が繰り返し使用される可能性が高くなります。この場合、特にWebサーバーではなくファイル・システムから直接出力が読み込まれる場合、ブラウザには、新しい出力ではなく、キャッシュされている古い出力が表示される傾向があります。

出力が正しくないと思われる場合、テンプレートまたはソフトウェアに問題があると判断する前に、すべてのフレームで「更新」をクリックしてください。

ヒント:

場合によっては、テンプレートを作成およびテストする間はブラウザのキャッシュをすべて消去して無効にするほうが簡単です。

35.9 イメージのサイズ設定ルール

最終的にエクスポートされるイメージのサイズは、非常に多くの要因によって決まります。それらの要因がどのように影響を及ぼすかを決めるルールの優先順位は、次のとおりです。

テンプレートで{##graphic}マクロによって指定されたイメージは、特定のデック上で画像に使用可能な領域から差し引かれます。一般に、すべてのデックにイメージを必要とするテンプレートは、ドキュメントのグラフィック用空き領域の合計容量を減らすことになるので、注意する必要があります。
SCCOPT_EX_GRAPHICBUFFERSIZEオプション。必要に応じてイメージ・サイズを減らす場合にのみ使用します。イメージのアスペクト比は維持されます。
SCCOPT_GRAPHIC_SIZELIMITオプション。必要に応じてイメージ・サイズを減らす場合にのみ使用します。イメージのアスペクト比は維持されます。
SCCOPT_GRAPHIC_WIDTHLIMITオプションとSCCOPT_GRAPHIC_HEIGHTLIMITオプション。これらは、必要に応じてイメージ・サイズを減らす場合にのみ使用します。両方が指定された場合も、イメージのアスペクト比は維持されます。
テンプレートの{##INSERT}文の'Width='パラメータと'height='パラメータ。これにより、指定された寸法に一致するようにイメージを縮小または拡大します。両方が指定された場合、イメージのアスペクト比は変更されます。これらのパラメータがどちらか一方でも指定されない場合、アスペクト比は維持されます。
ソース・ファイルの情報とDPI設定に基づく元のイメージの寸法(該当する場合)。

35.10 CSSの考慮事項

この項では、スクリプト・テンプレートのみに関連するスタイルについて説明します(「スクリプト・テンプレートの管理」を参照)。

カスケーディング・スタイルシート(CSS)の最も強力な機能の1つは、様々な方法で提案されるスタイルをオーバーライドする機能です。Dynamic Converterでは、生成されるスタイルシートをユーザーがオーバーライドできるように、CSSサポートが設計されています。したがって、複数の作成者が作成したドキュメントを組み合せて、より統一された外観で表示できます。このオーバーライドを機能させるには、まずスタイル名を理解する必要があります。

また、Dynamic Converterからの出力は、複数のHTMLファイルに組み込まれる可能性があることに注意する必要があります。特に、<LINK REL=STYLESHEET HREF="{## INSERT ELEMENT=Pragma.cssFile}">文が適切な位置に配置されることを確認する必要があります。

35.11 Dynamic Converterで使用されるスタイル名

スタイル名は、ソース・ドキュメントの元のスタイル名が引き継がれます。CSS標準で認められるスタイル名には、継承制限があります。標準で使用できる文字は、a-z、A-Z、0-9およびダッシュ(-)のみです。ソース・ドキュメントのスタイル名は、必ずしもこの範囲に制限されていません。実際、Unicode文字が使用される場合もあります。そのため、場合によっては、元のスタイル名を前述の標準に準拠するように変更する必要があります。不正なスタイル名が生成されないように、Dynamic Converterは、ソースのすべてのスタイル名に対して次の置換を実行します。

文字が「-」の場合、「--」で置換されます。
文字が残りの文字(aからz、AからZまたは0から9)のいずれでもない場合、「-xxxx」に置き換えられます。xxxxは、その文字の16進Unicode値です。
前述の状況のいずれにも当てはまらない場合は、文字はそのスタイル名で正常に表示されます。

スタイル名の空白が「-0020」で置換されるのは、最も一般的な例の1つです。スタイル名の文字の置換をより詳細に示す例として、ソース・スタイル名「My Special H1-Style!」(名前に空白と感嘆符が使用されています)について考えます。これは、「My-0020Special-0020H1--Style-0021」と変換されます。

このシステムは明らかに見た目はよくありませんが、ブラウザが取得したスタイル名が重複するか、または無効な場合に、ドキュメントの外観がどうなるかという問題は避けられます。また、開発者にとって、このようなスタイル名を解析または作成するために必要なコードが単純であることは評価できます。

さらに、Dynamic Converterは、特別なリスト・バージョンのスタイルを作成します。このスタイルには、元になるスタイルの名前の末尾に「--List」が付加された名前が付けられます。このスタイルには、元のスタイルと違って、ブロックレベルのCSSは含まれていません。

35.12 Dynamic Converterのスタイルのオーバーライド

スタイル名について理解すると、Dynamic Converterによって生成されるCSSファイルのオーバーライドは簡単です。テンプレートのCSSファイル・リンクの後に、CSSオーバーライド・ファイルへの別のリンクを追加します。Dynamic ConverterのCSSファイルへのリンクの詳細は、「Pragma.CSSFileおよび{## LINK}」を参照してください。この場合、オーバーライド・ファイルには、Dynamic ConverterのCSSファイルで使用されている名前と同じ名前のスタイルが設定されている必要があります。

様々なファイル形式では、スタイルを、定義済の他のスタイルに基づいて指定できることに注意してください。Dynamic Converterは、スタイルをネストすることで、これをサポートしています。この場合、ネストされている各スタイルは、それをネストしているスタイルで定義されているアイテムを継承しますが、それをオーバーライドすることもできます。

35.13 Pragma.CSSFileおよび{## LINK}

HTMLでCSS風の記述が検出されると、生成されるHTMLファイルごとに、その先頭に{##INSERT Element=Pragma.CSSFile}文が1つ追加されます。したがって、##LINK文は、別のHTMLファイルの作成をトリガーするために使用できることに注意する必要があります。その結果、##Linkでリンクされた各テンプレートには、通常、生成されるCSSファイルを参照する<Link>タグが存在します。

しかし、##LINK文を使用すると、CSSファイルを参照する必要のある{##}文のないテンプレートへのリンクが可能です。その場合は、CSSファイルを参照する<Link>を省略でき、それで問題が発生することはありません。たとえば、2つの##文しかないテンプレートについて考えた場合、どちらも##リンク(おそらくは個別の2つのフレームに結果を配置するためのもの)です。このテンプレート・ファイルには、CSSファイルを参照する<Link>は必要ありません。

Dynamic Converterで生成されるHTMLファイルの数に関係なく、CSSファイルは1つしか生成されません。また、何度も繰り返しますが、CSSファイルを参照する<Link>はドキュメントの<HEAD>セクションに記述する必要があり、生成される各HTMLファイルには<HEAD>セクションが1つしか存在しません。

35.14 整形式のHTML

Dynamic Converterの出力は、整形式であることを保証するためにテスト済です。ただしこれは、Dynamic Converterで使用するテンプレートも整形式でなければ、意味がありません。整形式テンプレートの作成を支援するために、整形式ではないドキュメントが生成される原因となる可能性がある一般的な問題のリストを次に示します。

すべてのタグは、正しくネストされる必要があります。
開始されたタグはすべて、終了する必要もあります。これには、通常は終了タグが必要と考えられていない、<META>、<LINK>、 <FRAME>、<HR>および<BR>などのタグも含まれます。
等号(=)の後はすべて二重引用符で囲む必要があります。したがって、<FONT COLOR="0000FF">は認められますが、<FONT COLOR=0000FF>は認められません。
 がドキュメントに表示されるためには、HTMLコードに<!DOCTYPE>文が必要です。Dynamic Converterでは、SCCHTML_FLAG_STRICT_DTDフラグが設定されている場合に、テンプレートに<!DOCTYPE>文が含まれていたかどうかはわからないため、 のかわりに必ず が使用されます。
範囲0x80-0xFFの文字は、&#xxx;という形式で記述されます。
どのドキュメントでも使用可能な0x20未満の文字は、\t、\nおよび\rの3文字のみです。
タグのすべての属性の後に「=value」と続ける必要があります。したがって、<Table NoWrap>のNoWrapは整形式ではありません。Dynamic Converterでは、かわりに<Table NoWrap=NoWrap>が使用されます。

35.15 位置フレームのサポート

Dynamic Converter 7.7以上では、オブジェクトの位置付けにDHTMLを使用します。ただし、サポートされているオブジェクトの位置付けのタイプは、段落アンカー・オブジェクトとページ・アンカー・オブジェクトの2つのみです。位置フレームの初期サポートに関するいくつかの重要な注意事項を次に示します。

Dynamic Converterでは、たとえ同じ場所に配置されるように見えても、パラグラフ・オブジェクトはページ・オブジェクトとは別に生成されます。
別々のグラフィック・アイテムがお互いに重なって配置される場合、透過性はサポートされません。SCCOPT_EX_PREVENTGRAPHICOVERLAPオプションは、これらの画像には適用されません。グラフィックは、ドキュメントのテキストからの相対ではなく、アンカー・ポイントからの相対で表示されます。また、Dynamic Converterでは、回転や伸縮など、一部のグラフィック効果がサポートされません。
最良の結果を得るために重要なことは、SCCOPT_EX_GRAPHICOUTPUTDPIオプションを正しく設定する必要があることに注意することです。
入力ドキュメントに位置フレーム・オブジェクトが存在する場合、Dynamic Converterからオブジェクトの配置が不正確な出力が生成される場合があります。ただし、この場合の最終結果は、7.7以前のバージョンのDynamic Converterで位置フレーム・オブジェクトを処理した場合の最終結果と同じです(すなわち、グラフィックが長い列に配置されます)。
この要素は、HTML 4.0でのみ機能します。

35.16 テンプレート作成のヒント

各デックの空き容量に制限がある場合、Dynamic Converterによって生成される各デックで使用可能なデータ量を最大化することが重要です。各デックで無駄に消費される空き容量を減らすためのいくつかの方法を次に示します。

テンプレート内の不要な空白文字を削除します。それらの空白文字が存在することで、テンプレートの読取り、編集および管理は簡単になりますが、各出力デックにもそのまま書き込まれます。デック・サイズが少ないデバイスで使用するテンプレートを作成する場合、各デックの使用可能なデータ量を増やすために余分な空白文字を削除することに意味がある可能性があります。SCCOPT_EX_COLLAPSEWHITEPSACEオプションは、テンプレートの空白には影響を与えないことに注意してください。
デック間の余分なリンクをすべて削除します。ナビゲーションしやすいことは必要不可欠ですが、冗長なリンクや不要なリンクは各デックのデータ用の空き容量を減らします。ナビゲーションに使用されるマークアップに加えて、SCCOPT_EX_MAXURLLENGTHオプションによって決まるリンクのURL用に領域が確保されます。現在は、URLがその長さより短い場合、領域は再利用されません。また、URLがその長さより長い場合、デック・オーバーフローが発生する可能性があります。