| Oracle® WebCenter Content Dynamic Converter管理者ガイド 11gリリース1 (11.1.1) B66698-01 |
|
 前 |
 次 |
この章では、Dynamic Converterを操作する際のより実際的な問題をいくつか取り上げます。次の項目について説明します。
クラシックHTML変換テンプレートでは、Dynamic Converterがマルチバイト環境(日本語、韓国語またはその他のローマ字以外の文字)で使用されていても、コンテンツID、セキュリティ・グループ、コンテンツ・タイプおよびアカウント名には、マルチバイト文字を使用しないことをお薦めします。このコンテンツ・メタデータ情報はコンテンツ・アイテムのURLに含まれており、現行のWebテクノロジでの制限により、WebサーバーとWebブラウザでマルチバイト文字URLを正しく処理できない場合があります。(たとえば、リンクが壊れている場合、Dynamic Converterではコンテンツ・アイテムを検索することができません。)
コンテンツID、セキュリティ・グループ、コンテンツ・タイプまたはアカウントにマルチバイト文字を使用する場合、Content Server環境全体(サーバーとクライアント)が、マルチバイト言語をサポートするオペレーティング・システム(たとえば、Microsoft Windowsの日本語または韓国語バージョン)で実行されていることを確認する必要があります。
|
注意: 新しいDynamic ConverterのHTMLテンプレート・エディタでは、変換中のテンプレートやコンテンツ・アイテムでのマルチバイトのコンテンツIDの使用はサポートされません。 |
UNIXでのPDFファイルの変換は遅く、3分(変換プロセスのデフォルトのタイムアウト値)後にタイムアウトする可能性があります。
変換タイムアウトの値を増やすには、次のようにします。
「Dynamic Converterの管理」ページを開きます(「「Dynamic Converterの管理」ページ」を参照)。
「構成設定」をクリックします。
「Dynamic Converterの構成」ページが表示されます(「「Dynamic Converterの構成」ページ」を参照)。
「タイムアウト」フィールドに新しい値を入力します(デフォルトの3分から増やします)。
「更新」をクリックして、変更を有効にします。
変更した設定はただちに有効になるため、Content Serverを再起動する必要はありません。
ソース・ドキュメントのなかには、埋込みOLEオブジェクトが含まれているものがあります。埋込みOLEオブジェクトには通常、Windowsメタファイルのフォームにスナップショット画像が添付されています。WindowsとUNIXのどちらでも、Dynamic Converterはメタファイル・スナップショットを使用して、OLEオブジェクトを変換できます。メタファイルが使用できない場合、Dynamic Converterは、変換のためにOLEテクノロジに復帰します。その場合、変換はWindowsでは成功しますが、UNIXでは失敗します。
ベクター画像を変換する場合、Dynamic Converterは実行中のXサーバーにアクセスする必要があります。これは、Dynamic Converterがピクセルの描画をXサーバー・システムに依存しているためです。
ベクター画像形式では、線と塗りを描画します。一般的な形式は、WMF、EMF、CorelDRAW、Adobe Illustrator、Excelのグラフ、WordのオートシェイプおよびPowerPointのプレゼンテーションです。一方、ラスター画像には、イメージのピクセル情報が含まれます。一般的なファイル形式は、BMP、JPEGおよびGIFです。
ベクター画像とラスター画像の違いを見分ける1つの方法は、イメージを拡大することです。ベクター画像は線を描画するため、線の配置が再計算され、イメージはそのままきれいに表示されます。しかし、ラスター画像は、サイズを変更すると画素化されます。
UNIXでの画像とフォントのレンダリングを設定する方法は、『Dynamic Converterインストレーション・ガイド』を参照してください。
ベクター画像を変換し、スプレッドシートの複数の列にまたがるテキストを正しく測定するために、Dynamic Converterでは、UNIXで実行されているXサーバーにアクセスする必要があります。
UNIXでの画像とフォントのレンダリングを設定する方法は、『Dynamic Converterインストレーション・ガイド』を参照してください。
Dynamic Converterでは、dcUrl('url', reserved_type) Idoc Script拡張関数ですべてのハイパーリンクおよびイメージ・ソース・リンク(src)を囲みます。このスクリプト関数のデフォルト実装では、単なるパススルーを実行しますが、外部統合テクノロジ(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 | 背景画像(ソース由来) |
イメージ・タグ<IMG SRC="image.gif">について考えます。Dynamic Converterの大部分の実装では、たいてい出力ファイルがテンプレート・ファイルとは異なる場所に格納されます。この状況で開発者がテンプレートを使用すると、作成される出力ファイルにはimage.gifへの参照が付き、ブラウザではこのファイルのパスが出力ファイルと同じとみなされます。問題は、image.gifが、テンプレート・ファイルのあるディレクトリに戻る可能性があることです。これは、相対URLを使用してテンプレートで参照されるすべてのものについての問題です。この問題には、いくつかの解決策が考えられます。
解決策1: 参照が正しいことの確認
すべてのテンプレートが参照するファイルを開発者が正確に知っている場合、正しいファイル(image.gifなど)を出力ディレクトリに移動または配置することができます。この解決策では、開発者がテンプレートのコンテンツに関する正確な知識を持っていることが必要であり、ファイルの同じセットが多くの出力場所に伝播される可能性があります。
解決策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)で画像(または関連ファイル)がチェックインされていれば、パスは解決されてページが正しく表示されます。
テンプレートの作成およびデバッグのプロセスでは、同じソース・ファイルを、多少異なるテンプレートでDynamic Converterを介して繰返し実行することになります。出力ファイルにどのように名前を付けるかによって、同じファイル名のセットが繰返し作成される場合があります。このような状況では(特に、出力をWebサーバーからではなく、ファイル・システムから直接読み取る場合)、ブラウザには新しい結果ではなく、キャッシュされた古い結果が表示される傾向があります。
出力が正しくないと思われる場合は、テンプレートまたはソフトウェアの問題と判断する前に、すべてのフレームで「リフレッシュ」をクリックしてください。
|
ヒント: テンプレートの作成およびテスト中に、ブラウザでキャッシュを空にして無効にする方が簡単な場合があります。 |
最終的にエクスポートされるイメージのサイズに影響を与える要素が多数あります。それらの要素がどのように作用するかのルールの優先順位は、次のとおりです。
テンプレートで{## graphic}マクロによって指定されたイメージは、特定のデック上で画像に使用可能な領域から差し引かれます。一般に、イメージはドキュメントの画像に使用できる領域の全体量を消費するため、デックごとにイメージが必要なテンプレートには注意する必要があります。
SCCOPT_EX_GRAPHICBUFFERSIZEオプション。必要に応じてイメージのサイズを縮小する場合にのみ使用します。イメージの縦横比は維持されます。
SCCOPT_GRAPHIC_SIZELIMITオプション。必要に応じてイメージのサイズを縮小する場合にのみ使用します。イメージの縦横比は維持されます。
SCCOPT_GRAPHIC_WIDTHLIMITオプションとSCCOPT_GRAPHIC_HEIGHTLIMITオプション。これらは、必要に応じてイメージのサイズを縮小する場合にのみ使用します。縦横比は、両方が指定されている場合でも維持されます。
テンプレートの{## INSERT}文の'Width='パラメータと'height='パラメータ。指定した寸法に一致するように、イメージを縮小または拡大します。イメージの縦横比は、両方のパラメータを指定した場合、変更されます。これらのパラメータを一方のみ指定した場合、またはどちらも指定しなかった場合、縦横比は変わりません。
ソース・ファイルとDPI設定の情報に基づいた元のイメージの寸法(該当する場合)。
この項で説明するスタイルは、スクリプト・テンプレート(第7章「スクリプト・テンプレート」を参照)関連のみです。クラシックHTML変換テンプレート(第5章「HTML変換テンプレート」を参照)のスタイルは別途記載します。
Cascading Style Sheet (CSS)の最も強力な機能の1つは、様々な方法で提案されたスタイルをオーバーライドする機能です。Dynamic Converterでは、ユーザーが作成されたスタイル・シートをオーバーライドできるようにCSSサポートが設計されています。つまり、ユーザーは、多数の作成者のドキュメントを融合し、より見た目が統一されたコレクションにすることができます。このオーバーライドを機能させるには、まずスタイル名を理解する必要があります。
さらに、Dynamic Converterからの出力は多くのHTMLファイルに配置されることにも留意する必要があります。特に、<LINK REL=STYLESHEET HREF="{## INSERT ELEMENT=Pragma.cssFile}">文が必ず適切な場所に置かれるように、注意が必要です。
スタイル名は、ソース・ドキュメントでの元のスタイル名から取られます。スタイル名には、CSS標準で認められる継承制限があります。標準で使用が認められる文字は、a?z、A?Z、0?9およびダッシュ(-)のみです。ソース・ドキュメントのスタイル名には、必ずしもこの制限がありません。実際には、Unicode文字が含まれていることさえあります。このため、元のスタイル名は、この標準に従うために変更が必要になる場合があります。不正なスタイル名を回避するために、Dynamic Converterでは、すべてのソース・スタイル名で次の置換が行われます。
文字が「-」の場合は、「--」に置き換えられます。
文字が残りの文字(a?z、A?Zまたは0?9)のいずれでもない場合、「-xxxx」に置き換えられます。xxxxは、その文字の16進Unicode値です。
前述の状況のいずれにも当てはまらない場合は、文字はそのスタイル名で正常に表示されます。
この置換の最も一般的な例の1つに、スタイル名の空白が「-0020」で置き換えられるというものがあります。スタイル名における文字置換のより包括的な例として、ソース・スタイル名My Special H1-Style!について考慮します(名前に空白と感嘆符が含まれています)。これはMy-0020Special-0020H1--Style-0021に変換されます。
このシステムは明らかに見た目の美しさに欠けますが、ブラウザが重複または無効なスタイル名を取得した場合に、ドキュメントの外観についての問題を回避できます。開発者にとって、これらのスタイル名を解析または作成するために必要なコードが簡単であることも評価できます。
さらに、Dynamic Converterでは、スタイルの特別なリスト・バージョンが作成されます。これらは、元になっているスタイルと同じ名前で、最後に--Listが付いています。これらのスタイルは、ブロックレベルのCSSが含まれていないという点で、元のスタイルとは異なります。
スタイル名がわかれば、Dynamic Converterで作成されるCSSファイルのオーバーライドは簡単です。CSSオーバーライド・ファイルへの別のリンクがあるテンプレートで、CSSファイル・リンクをたどります。Dynamic ConverterのCSSファイルへのリンクの詳細は、「Pragma.CSSFileと{## LINK}」を参照してください。このオーバーライド・ファイルには、Dynamic ConverterのCSSファイルで使用されているものと同じ名前のスタイルが含まれている必要があります。
多くのファイル形式では、以前に定義された他のスタイルに基づいたスタイルが許可されていることに留意してください。Dynamic Converterでは、スタイルをネストすることでこれをサポートします。このようにして、ネストされた各スタイルでは、周囲のスタイルで定義されているアイテムが継承されます。また、それらをオーバーライドすることもあります。
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つしかありません。
Dynamic Converterの出力は、整形式であることを確認するためにテストされています。しかし、Dynamic Converterによって使用されるテンプレートも整形式でなければ、無意味です。整形式のテンプレートの作成を支援するために、整形式でないドキュメントが作成される原因となる一般的な問題を次に示します。
すべてのタグは正しくネストする必要があります。
開始したタグはすべて閉じる必要があります。これには、通常は閉じタグが必要とは考えられない<META>、<LINK>、<FRAME>、<HR>および<BR>などのタグが含まれます。
等号(=)の後のものはすべて二重引用符で囲む必要があります。したがって、<FONT COLOR="0000FF">はOKですが、<FONT COLOR=0000FF>はそうではありません。
& をドキュメントで表示するには、<!DOCTYPE>文をHTMLコードにすることが必要です。Dynamic Converterでは、SCCHTML_FLAG_STRICT_DTDフラグが設定されている場合に、テンプレートに<!DOCTYPE>文が含まれていたかどうかはわからないため、 のかわりに必ず が使用されます。
0x80?0xFFの範囲の文字は、&&#xxx;の形式で書かれます。
どのドキュメントでも使用可能な0x20未満の文字は、\t、\nおよび\rの3文字のみです。
タグのすべての属性の後には、=valueが続きます。したがって、<Table NoWrap>のNoWrapは整形式ではありません。Dynamic Converterでは、かわりに<Table NoWrap=NoWrap>が使用されます。
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フレーバでのみ機能します。
各デックの領域の量が制限される場合、Dynamic Converterで作成される各デックにおける使用可能なデータの量を最大化することが重要です。各デックで無駄に消費される領域の量を減らすには、次の方法があります。
テンプレートで不要な空白文字を削除します。これらの文字の存在は、テンプレートの読取り、編集、メンテナンスを容易にしますが、これらは各出力デックにもそのまま書き込まれます。デック・サイズが小さいデバイス用のテンプレートを作成する場合、各デックで使用可能なデータの量を増やすために、余分な空白文字を削除することに価値があることがわかります。SCCOPT_EX_COLLAPSEWHITEPSACEオプションは、テンプレートの空白には影響を与えないことに注意してください。
デック間の余分なリンクは削除します。ナビゲーションのよさが不可欠である一方で、重複するリンクや不要なリンクは、データの各デックで残された領域の量を侵食します。ナビゲーションに使用されるマークアップに加えて、SCCOPT_EX_MAXURLLENGTHオプションによって決まるリンクのURL用に領域が確保されます。現在のところ、URLがこの長さより短くても、空白は回収されません。さらに、URLがこの長さより長い場合、デックのオーバーフローが発生する可能性があります。
