ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebCenter Contentのマネージング
11g リリース1 (11.1.1)
B72426-04
  ドキュメント・ライブラリへ移動
ライブラリ
目次へ移動
目次

前
 
次
 

21 Inbound Refineryの構成

Oracle WebCenter Content: Inbound Refineryは、Oracle WebCenter Content ServerおよびInbound Refinery上にインストールおよび有効化されているコンポーネントに応じて、様々な変換オプションを提供します。この章では、様々な変換オプションの概要を説明します。

基本的な変換を行うには、最低でも次のコンポーネントをインストールして有効化する必要があります。

コンポーネント名 コンポーネントの説明 有効にするサーバー

InboundRefinery

Inbound Refineryを有効にします。

Inbound Refineryサーバー

InboundRefinerySupport

コンテンツ・サーバーとInbound Refineryの併用を有効にします。

コンテンツ・サーバー


この章では、次の項目について説明します。

21.1 コンテンツ・サーバーとリファイナリの構成シナリオ

Inbound Refineryは、コンテンツ・サーバーによって管理されているコンテンツを調整するために使用できます。Inbound Refineryは、コンテンツ・サーバーと同じコンピュータまたは1台以上の別のコンピュータにインストールできます。インストール後に、同じまたは別のコンピュータ上のコンテンツ・サーバーに、プロバイダとしてリファイナリを追加する必要があります。詳細は、21.2.1項を参照してください。


注意:

Oracle Inbound Refineryでは、クラスタ環境での実行はサポートされていません。Inbound Refineryはコンテンツ・サーバー・クラスタに対する変換作業は実行できますが、それ自体をクラスタ環境で実行することはできません。Inbound Refineryは正しく機能するように、/queue/conversionディレクトリに対して長期ロックを作成し、維持します。Inbound Refineryが誤ってクラスタの一部として構成され、2つ目のInbound Refineryが起動して同じディレクトリのロックを試みると、2つ目のInbound Refineryは起動に失敗し、この試行はログに記録されます。


様々な構成が可能なため、リファイナリ環境の設定時には、次の一般ルールに留意してください。

次に一般的なシナリオを示します。この項で説明するリファイナリ構成に加え、その他の構成も可能です。特定のコンテンツ管理アプリケーションでは独自のリファイナリ設定が必要なことがあり、この項で紹介するいずれのシナリオとも合致しない場合があります。

これらの各シナリオについて、次の各項で、それぞれのシナリオのメリットおよび考慮すべき注意事項も含めて詳しく説明します。シナリオの図では、コンピュータ、コンテンツ・サーバーおよびInbound Refineryを表すために、次の記号を使用します。

21.1.1 シナリオA

シナリオAの図については、前後のテキストで説明されています。

これは最も基本的なシナリオです。同じコンピュータ上にインストールされた1つのコンテンツ・サーバーと1つのリファイナリから構成されます。

  • 長所:

    • 最も安価で、構成が最も容易です。

    • 購入する必要がある、リファイナリ変換に必要なサード・パーティ・アプリケーションは1つだけです。

  • 考慮事項:

    • 変換の数および速度が制限されています。

    • リファイナリがコンテンツ・サーバー・コンピュータにデプロイされていないシナリオほど処理能力は高くありません。これは、コンテンツ・サーバー・コンピュータ上でのリファイナリ処理は検索やWebサイトへのアクセス速度を低下させることがあり、その逆もまた同様のためです。ファイル・タイプとサイズに応じて、各変換には数秒から数分かかります。

21.1.2 シナリオB

シナリオBの図については、前後のテキストで説明されています。

このシナリオは、同じコンピュータ上にインストールされた複数のコンテンツ・サーバーと1つのリファイナリから構成されます。

  • 長所: 購入する必要がある、リファイナリ変換に必要なサード・パーティ・アプリケーションは1つだけです。

  • 考慮事項:

    • 変換の数および速度が制限されています。

    • リファイナリがコンテンツ・サーバー・コンピュータにデプロイされていないシナリオほど処理能力は高くありません。これは、コンテンツ・サーバー・コンピュータ上でのリファイナリ処理は検索やWebサイトへのアクセス速度を低下させることがあり、その逆もまた同様のためです。ファイル・タイプとサイズに応じて、各変換には数秒から数分かかります。

    • この構成では、リファイナリのデプロイ時には通常、次の選択を行います。

      • リファイナリをいずれかのコンテンツ・サーバーのプロバイダとして設定します。デプロイメント後に、このリファイナリを他のコンテンツ・サーバーに対してプロバイダとして追加する必要があります。詳細は、21.2.1項を参照してください。

21.1.3 シナリオC

シナリオCの図については、前後のテキストで説明されています。

このシナリオは、別々のコンピュータ上にインストールされた複数のコンテンツ・サーバーと1つのリファイナリから構成されます。

  • 長所:

    • 購入する必要がある、リファイナリ変換に必要なサード・パーティ・アプリケーションは1つだけです。

    • リファイナリがコンテンツ・サーバーと同じコンピュータ上にデプロイされている場合よりも、処理が高速です。

    • リファイナリの処理はコンテンツ・サーバーの検索およびWebサイトへのアクセスに影響しません。その逆もまた同様です。

  • 考慮事項:

    • 1つのコンテンツ・サーバーに付き1つのリファイナリが存在するシナリオほど処理能力は高くありません。

    • この構成では、リファイナリのデプロイ時には通常、次の選択を行います。

      • リファイナリは、各コンテンツ・サーバーに対してプロバイダとして追加する必要があります。詳細は、21.2.1項を参照してください。

21.1.4 シナリオD

シナリオDの図については、前後のテキストで説明されています。

このシナリオは、別々のコンピュータ上にインストールされた1つのコンテンツ・サーバーに付き1つのリファイナリから構成されます。

  • 長所:

    • 大量のコンテンツおよび大きなファイル・サイズに対して高速処理を行えます。

    • リファイナリの処理はコンテンツ・サーバーの検索およびWebサイトへのアクセスに影響しません。その逆もまた同様です。

  • 考慮事項:

    • 各リファイナリ・コンピュータに、変換に必要なすべてのサード・パーティ・アプリケーションのコピーが必要です。

    • 各リファイナリを、各コンテンツ・サーバーに対してプロバイダとして追加する必要があります。詳細は、21.2.1項を参照してください。

21.1.5 シナリオE

シナリオEの図については、前後のテキストで説明されています。

このシナリオは、別々のコンピュータ上にインストールされた1つのコンテンツ・サーバーに付き複数のリファイナリから構成されます。

  • 長所:

    • 大量のコンテンツおよび大きなファイル・サイズに対して最高速で処理を行えます。

    • リファイナリの処理はコンテンツ・サーバーの検索およびWebサイトへのアクセスに影響しません。その逆もまた同様です。

  • 考慮事項:

    • 各リファイナリ・コンピュータに、変換に必要なすべてのサード・パーティ・アプリケーションのコピーが必要です。

    • この構成では、リファイナリのデプロイ時には通常、次の選択を行います。

      • 各リファイナリを、各コンテンツ・サーバー・インスタンスに対してプロバイダとして追加する必要があります。詳細は、21.2.1項を参照してください。

21.2 コンテンツ・サーバーとリファイナリ間の通信の構成

このセクションのトピックは次のとおりです:

21.2.1 リファイナリ・プロバイダの構成

コンテンツ・サーバーは、プロバイダを通してリファイナリと通信します。1つのリファイナリは、1つまたは複数のコンテンツ・サーバー・インスタンスに対してプロバイダとして機能できます。一般的な構成の詳細は、第21.1項を参照してください。

リファイナリは、同じコンピュータ上のコンテンツ・サーバー・インスタンスにプロバイダとして追加するか、デプロイメント後に別のコンピュータ上のコンテンツ・サーバー・インスタンスに追加できます。

このセクションのトピックは次のとおりです:

21.2.1.1 リファイナリ・プロバイダの追加または構成

リファイナリをプロバイダとしてコンテンツ・サーバー・インスタンスに追加する手順は次のとおりです。

  1. 管理者としてコンテンツ・サーバーにログインします。

  2. 「メイン」メニューで、「管理」「プロバイダ」を選択します。

  3. 「プロバイダ」ページの「新規プロバイダの作成」セクションで、「送信」プロバイダ・タイプの「アクション」列にある「追加」をクリックします。

  4. 送信ソケット・プロバイダの追加/「送信ソケット・プロバイダの編集」ページで、次のフィールドに入力します。

    • プロバイダ名(必須): リファイナリ・プロバイダの名前。

    • プロバイダの説明(必須): わかりやすいプロバイダの説明。

    • プロバイダ・クラス(必須): プロバイダのJavaクラスの名前。デフォルトは、intradoc.provider.SocketOutgoingProviderクラスです。

    • 接続クラス: 必須ではありません。

    • 構成クラス: 必須ではありません。

    • サーバー・ホスト名(必須): リファイナリがインストールされているサーバーのホスト名。

    • HTTPサーバー・アドレス: リファイナリのHTTPサーバー・アドレス。リファイナリがコンテンツ・サーバーと同じコンピュータ上に存在している場合は、必須ではありません。

    • サーバー・ポート(必須): リファイナリ・プロバイダが通信するポート。このエントリは、Inbound Refineryのデプロイメント時にインストール後の構成ページで構成したサーバー・ソケット・ポートと一致する必要があります。構成後の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』を参照してください。デフォルトのリファイナリ・ポートは5555です。

    • インスタンス名(必須): リファイナリのインスタンス名。たとえば、ref2です。

    • 相対Webルート(必須): リファイナリの相対Webルートは/ibr/です。

  5. 接続先のリファイナリでコンテンツ・サーバーに対する認証が要求される場合は、「接続パスワードの使用」チェック・ボックスを選択します(コンテンツ・サーバーはリファイナリのユーザー・ベースを共有するようになります)。選択した場合は、使用するユーザー名とパスワードを指定し、リファイナリ上にProxyConnectionsコンポーネントをインストールして構成する必要があります。

  6. 「Inbound Refinery変換ジョブの処理」チェック・ボックスを選択します。これは必須です。

  7. 「Inbound Refineryの読取り専用モード」チェック・ボックスの選択を解除します。コンテンツ・サーバーで新規の変換ジョブをリファイナリに送信しない場合にのみ、このチェック・ボックスを選択します。

  8. 必要な場合は、コンテンツ・サーバーの事前変換されたキューで許可されるジョブの最大数を変更します。デフォルトは1000ジョブです。

  9. 「追加」をクリックします。

    「プロバイダ」表に追加した新しいリファイナリ・プロバイダが入った「プロバイダ」ページが開きます。

  10. コンテンツ・サーバーを再起動します。

既存のリファイナリ・プロバイダの情報を編集するには、「プロバイダ」ページにアクセスし、編集するプロバイダの「アクション」メニューの「情報」をクリックします。送信ソケット・プロバイダの追加/「送信ソケット・プロバイダの編集」ページで、必要な変更を加えます。完了したら、コンテンツ・サーバー・インスタンスを再起動します。

21.2.1.2 リファイナリ・プロバイダの有効化/無効化

既存のリファイナリ・プロバイダを有効または無効にする手順は次のとおりです。

  1. 管理者としてコンテンツ・サーバーにログインします。

  2. 「メイン」メニューで、「管理」「プロバイダ」を選択します。

  3. 「プロバイダ」ページの「プロバイダ」表で、有効または無効にするリファイナリ・プロバイダの「アクション」列の「情報」をクリックします。

  4. 「プロバイダ情報」ページで、「無効化」または「有効化」をクリックします。

  5. コンテンツ・サーバーを再起動します。

21.2.1.3 リファイナリ・プロバイダの削除

既存のリファイナリ・プロバイダを削除する手順は次のとおりです。

  1. 管理者としてコンテンツ・サーバーにログインします。

  2. 「メイン」メニューで、「管理」「プロバイダ」を選択します。

  3. 「プロバイダ」ページの「プロバイダ」表で、削除するリファイナリ・プロバイダの「アクション」列の「情報」をクリックします。

  4. 「プロバイダ情報」ページで、「削除」をクリックします。

    確認メッセージが表示されます。

  5. 「OK」をクリックします。

21.2.2 リファイナリのIPセキュリティ・フィルタの編集

リファイナリへのアクセスを制限するためにIPセキュリティ・フィルタを使用します。指定された条件に一致するIPまたはIPv6アドレスのホストのみにアクセスが許可されます。デフォルトでは、IPセキュリティ・フィルタは127.0.0.1|0:0:0:0:0:0:0:1です。これは、Inbound Refineryはlocalhostからの通信のみをリスニングすることを意味します。コンテンツ・サーバーがそのすべてのリファイナリと通信できるようにするには、リファイナリのIPセキュリティ・フィルタに、各コンテンツ・サーバー・コンピュータのIPまたはIPv6アドレスを追加する必要があります。これは、リファイナリがコンテンツ・サーバー・インスタンスと同じコンピュータ上で実行されている場合も同様です。リファイナリのIPセキュリティ・フィルタを編集する手順は次のとおりです。

  1. リファイナリ・コンピュータにアクセスします。

  2. システム・プロパティ・アプリケーションを起動します。

    • Windows: 「スタート」「プログラム」を選択します。Oracle Content Server/Inbound Refineryinstance_name「ユーティリティ」「システム・プロパティ」を選択します。

    • UNIX: リファイナリのインストール・ディレクトリの/binサブディレクトリにあるSystemPropertiesスクリプトを実行します。

  3. 「サーバー」タブを選択します。

  4. 「IPアドレス・フィルタ」フィールドには、各コンテンツ・サーバー・コンピュータのIPまたはIPv6アドレスが含まれている必要があります(これが、リファイナリ・サーバーも実行されているのと同じ物理コンピュータである場合も)。このフィールドのデフォルト値は127.0.0.1|0:0:0:0:0:0:0:1 (localhost)ですが、有効なIPまたはIPv6アドレスをいくつでも追加できます。パイプ記号(|)で区切ることにより複数のIPアドレスを指定できます。また、ワイルドカード(0個以上の文字を表す*、および1文字を表す?)も使用できます。次に例を示します。

    127.0.0.1|0:0:0:0:0:0:0:1|10.10.1.10|62.43.163.*|62.43.161.12?
    

    重要:

    localhostのIPアドレス(127.0.0.1)は必ず含めてください。


  5. 完了したら「OK」をクリックし、リファイナリ・サーバーを再起動します。


    ヒント:

    または、IntradocDir/configディレクトリにあるconfig.cfgファイルで、IPセキュリティ・フィルタにIPアドレスを直接追加することもできます。IPまたはIPv6アドレスを、SocketHostAddressSecurityFilter変数に追加します。例: SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1|10.10.1.10|62.43.163.*


21.2.3 UNIXプラットフォームに対するライブラリ・パスの設定

コンテンツ・サーバーおよびInbound Refineryでは、Outside In Technologyを使用します。Ouside In Technologyは、すべてのLinuxプラットフォームに加えて、SolarisプラットフォームとHPUX ia64の両方で、GCCライブラリ(libgcc_sとlibstdc++)に動的にリンクされます。コンテンツ・サーバーはこれらのライブラリにアクセスできる必要がありますが、SolarisとHPUXではこれらのライブラリはデフォルトでは利用できません。コンテンツ・サーバーまたはInbound RefineryをSolarisまたはHPUXのいずれかで実行している場合は、GCCライブラリを入手してインストールし、それらを検出するようにコンテンツ・サーバーを構成する必要があります。ライブラリ・パスの構成の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』を参照してください。

21.3 コンテンツ・サーバーでのリファイナリへのジョブ送信の構成

コンテンツ・サーバーでは、ファイル拡張子、ファイル形式および変換を使用して、コンテンツ・アイテムがInbound Refineryおよびその変換アドオンによってどのように処理されるべきかを定義します。また、アプリケーション開発者はカスタム変換を作成することもできます。

このセクションのトピックは次のとおりです:

21.3.1 ファイル形式と変換について

通常、ファイル形式はそのMultipurpose Internet Mail Extension (MIME)タイプにより識別され、各ファイル形式は特定の変換にリンクされます。各ファイル拡張子は、特定のファイル形式にマップされます。したがって、チェックインされたファイルの拡張子に基づいて、コンテンツ・サーバーは、ファイルがリファイナリによって処理されるかどうか、およびどのように処理されるかを制御できます。リファイナリの変換設定は、リファイナリが承認する変換を指定し、変換の出力を制御します。

次の例を考えてみます。docファイル拡張子がファイル形式application/mswordにマップされており、これは変換Wordにリンクされています。これは、コンテンツ・サーバーが、コンテンツ・サーバーにチェックインされたすべてのMicrosoft Wordファイル(拡張子がdocのファイル)を、変換用にリファイナリに送信しようとすることを意味します。

別の例として、xlsファイル拡張子がファイル形式application/vnd.ms-excelにマップされており、これは変換PassThruにリンクされているとします。この場合、Microsoft Excelファイルはリファイナリには送信されません。かわりに、ネイティブ・ファイルのコピーまたはネイティブ・ボールト・ファイルを指すHCSTファイルを/weblayoutディレクトリに配置するように、コンテンツ・サーバーを構成できます。つまり、ユーザーがこのファイルを表示するには、ネイティブ・ファイルを開くことができるアプリケーションがユーザーのコンピュータにインストールされている必要があります。

図21-1 変換へのファイル形式のマッピング

この図については、前後のテキストで説明されています。

ファイルがコンテンツ・サーバーにチェックインされ、そのファイル形式が変換にマップされていると、コンテンツ・サーバーは、その変換を承認して変換ジョブを実行できるリファイナリ・プロバイダがあるかどうかを確認します。これは、次のことを意味します。

  • コンテンツ・サーバーに対してリファイナリ・プロバイダが設定されている必要があります。詳細は、21.2.1項を参照してください。

  • 1つ以上のリファイナリが変換を承認するように構成されている必要があります。詳細は、21.5.2項を参照してください。

変換では、実行すべき変換ステップや使用すべき変換エンジンも含め、特定のファイル形式をどのように処理すべきかを指定します。詳細は、21.3.2項を参照してください。

コンテンツ・サーバーで使用可能な変換は、リファイナリで使用可能な変換と一致する必要があります。あるファイル形式がコンテンツ・サーバーで変換にマップされると、そのフォーマットのファイルは、チェックイン時に変換用に送信されます。その変換を承認するように、1つ以上のリファイナリが設定されている必要があります。詳細は、21.5.2項を参照してください。

次のデフォルト変換を使用できます。変換アドオンをインストールすると、追加の変換が使用可能になります。詳細は、特定の変換アドオンのドキュメントを参照してください。

変換 説明

PassThru

ファイルが変換されないようにするために使用します。この変換がファイル形式にリンクされていると、そのファイル形式にマップされているすべてのファイル拡張子は変換用に送信されません。ネイティブ・ファイルのコピーまたはネイティブ・ボールト・ファイルを指すHCSTファイルを/weblayoutディレクトリに配置するように、コンテンツ・サーバーを構成できます。詳細は、21.3.3項を参照してください。

Word

Microsoft Word、Microsoft Writeおよびリッチ・テキスト形式(RTF)ファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

Excel

Microsoft Excelファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

PowerPoint

Microsoft PowerPointファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

MSProject

Microsoft Projectファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

Distiller

PostScriptファイルを変換用に送信するために使用します。ファイルは指定されたPostScript Distillerエンジンを使用してPDFに変換されます。

MSPub

Microsoft Publisherファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

FrameMaker

Adobe FrameMakerファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

Visio

Microsoft Visioファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

WordPerfect

Corel WordPerfectファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

PhotoShop

Adobe Photoshopファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

InDesign

Adobe InDesign、Adobe PageMakerおよびQuarkXPressファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

MSSnapshot

Microsoft Snapshotファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

PDF Refinement

チェックインされたPDFファイルを調整用に送信するために使用します。リファイナリの変換設定に応じて、これには指定されたPostScript Distillerエンジンを使用した、高速Web表示用のPDFファイルの最適化が含まれます。

Ichitaro

このバージョンのInbound Refineryでは、一太郎の変換はサポートされていません。

OpenOffice

OpenOfficeおよびStarOfficeファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。

ImageThumbnail

選択したグラフィック・フォーマットを単純なサムネイルのみの作成用に送信するために使用します。これは、Inbound Refineryはインストールされていないが、グラフィック・フォーマットのサムネイル・イメージが必要な場合に有用です。返されるWeb表示可能ファイルは、ネイティブ・ファイルのコピーであり、オプションでサムネイル・イメージになります。

Inbound Refineryがインストールされている場合は、ImageThumbnail変換のかわりに、イメージ・レンディションおよびサムネイルの作成も含め、変換用にグラフィック・フォーマットを送信するために使用できます。

NativeThumbnail

中間のPDF変換からではなく、ネイティブ・フォーマットからのサムネイルの作成用に、選択したファイル形式を送信するために使用します。通常、この変換は、テキスト・ファイル(TXT)、Microsoft Outlook電子メール・ファイル(EMLとMSG)およびOfficeドキュメントのサムネイルを、先にPDFに変換せずに作成するために使用します。返されるWeb表示可能ファイルは、ネイティブ・ファイルのコピーであり、オプションでサムネイル・レンディションやXMLレンディションになります。XMLレンディションを作成するには、XMLConverterがインストールされており、XMLステップが構成および有効化されている必要があります。

MultipageTiff

Outside In Image Exportを使用した複数ページのTIFFファイルへの直接変換用にファイルを送信するために使用します。ファイル形式がこの変換にマップされている場合、リファイナリの変換設定は無視され、ファイルはTIFFファイルへの変換用にImage Exportに直接送信されます。

OutsideIn Technology

リファイナリ・サーバー上でのWinNativeConverterを使用した変換用に、サポートされているフォーマットをPostScriptに印刷するためにOutside In Xを使用します。

Direct PDFExport

Outside In PDF Exportを使用したPDFへの直接変換用にファイルを送信するために使用します。

FlexionXML

XML Converterを使用した変換用にファイルを送信するために使用します。

SearchML

XML Converterを使用した変換用にファイルを送信するために使用します。

XML-XSLT Transformation

XML Converterを使用したXSLT変換用にファイルを送信するために使用します。XSLT変換は、XMLデータを別のフォーマットに出力するために使用します。

LegacyCustom

このバージョンのInbound Refineryでは、LegacyCustom変換はサポートされていません。

Digital Media Graphics

Digital Asset Managerがインストールされている場合、Image Managerを使用した複数のイメージ・レンディションへの変換用にデジタル・イメージを送信するために使用します。

Digital Media Video

Digital Asset Managerがインストールされている場合、Video Managerを使用した複数のビデオまたはオーディオ・レンディションへの変換用にデジタル・ビデオを送信するために使用します。

TIFFConversion

ドキュメント内でのテキストの索引付けが可能なPDFフォーマットへの変換用にTIFFファイルを送信するために使用します。

Word HTML

ネイティブMicrosoft Wordアプリケーションを使用したHTMLへの変換用にMicrosoft Wordファイルを送信するために使用します。

PowerPoint HTML

ネイティブMicrosoft PowerPointアプリケーションを使用したHTMLへの変換用にMicrosoft PowerPointファイルを送信するために使用します。

Excel HTML

ネイティブMicrosoft Excelアプリケーションを使用したHTMLへの変換用にMicrosoft Excelファイルを送信するために使用します。

Visio HTML

ネイティブMicrosoft Visioアプリケーションを使用したHTMLへの変換用にMicrosoft Visioファイルを送信するために使用します。


21.3.1.1 コンテンツ・アイテムのリファイナリ通過と失敗した変換

ファイル形式が変換PassThruにリンクされていると、そのファイル形式にマップされているすべてのファイル拡張子は変換されません。ファイル拡張子がPassThruにマップされているコンテンツ・アイテムがコンテンツ・サーバーにチェックインされると、そのファイルはリファイナリには送信されず、Web表示可能ファイルは作成されません。ネイティブ・ファイルのコピー、またはネイティブ・ファイルを指すHCSTファイルをweblayoutディレクトリに配置するように、コンテンツ・サーバーを構成できます。これは、ユーザーがファイルを表示するには、ファイルの作成に使用されたアプリケーション、またはファイルを開くことができるアプリケーションが、各クライアント上にインストールされている必要があることを意味します。詳細は、21.3.3項を参照してください。

ファイルがリファイナリに送信され、変換が失敗したことがリファイナリによってコンテンツ・サーバーに通知される場合、ネイティブ・ファイルのコピーをWebレイアウト・ディレクトリに配置するようにコンテンツ・サーバーを構成できます。この場合、ユーザーがこのファイルを表示するには、ネイティブ・ファイルを開くことができるアプリケーションがユーザーのコンピュータにインストールされている必要があります。詳細は、21.3.4項を参照してください。

21.3.1.2 MIMEタイプについて

新しいファイル形式には、ファイル拡張子に対応するMIME (Multipurpose Internet Mail Extensions)タイプによって名前を付けることをお薦めします(たとえば、docファイル拡張子にマップされるフォーマットはapplication/mswordにするなど)。

コンテンツ・アイテムがコンテンツ・サーバーにチェックインされると、そのコンテンツ・アイテムのフォーマットは、ネイティブ・ファイルのファイル拡張子にマップされているフォーマットに従って割り当てられます。ネイティブ・ファイルが変換されない場合、コンテンツ・サーバーでは、コンテンツ・アイテムをクライアントに配信する際にこのフォーマットを含めます。フォーマットにMIMEタイプを使用すると、クライアントでは、ファイルのデータのタイプや使用する必要があるヘルパー・アプリケーションなどの判断に役立ちます。

ネイティブ・ファイルが変換されると、Inbound RefineryはWeb表示可能ファイルに適切なフォーマットを割り当て(たとえば、リファイナリがPDFファイルを生成した場合、このファイルをapplication/pdfと識別します)、コンテンツ・サーバーはクライアントへのWeb表示可能ファイルの配信時に(ネイティブ・ファイルに対して指定されているフォーマットではなく)このフォーマットを含めます。

Inbound Refineryには、インストール時に自動的に構成されるファイル形式の広範なリストが含まれます。コンテンツ・サーバー・プロバイダの構成マネージャ・アプレットでリストを確認してください。新しいフォーマットは、珍しいフォーマットまたは独自のフォーマットで作業する場合にのみ追加する必要があります。

ファイル形式に対する正しいMIMEタイプを判別するために有用なリソースがインターネットで提供されています。次に例を示します。

21.3.2 ファイル・タイプの管理

ファイル・タイプとファイル形式の構成の詳細を管理するには、「ファイル形式ウィザード」ページまたは構成マネージャを使用します。「ファイル形式ウィザード」ページは、一般的なほとんどのファイル・タイプの変換を構成するために使用できますが、構成マネージャ・アプレットのすべての機能が複製されるわけではありません。


重要:

「ファイル形式ウィザード」ページを有効にするには、コンテンツ・サーバーにInboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。また、変換オプション・コンポーネントによって、ファイル・タイプが「ファイル形式ウィザード」ページに追加される場合があります。


「ファイル形式ウィザード」ページを使用する手順は次のとおりです。

  1. 管理者としてログインします。

  2. 「メイン」メニューで「管理」「リファイナリ管理」「ファイル形式ウィザード」を選択します。

  3. 「ファイル形式ウィザード」ページで、変換用にリファイナリに送信される各ファイル・タイプに対するチェック・ボックスを選択します。すべてのチェック・ボックスを選択または選択解除するには、見出し行でチェック・ボックスを選択または選択解除します。


    重要:

    このバージョンのInbound Refineryでは、一太郎の変換はサポートされていません。


  4. 最後に保存した設定に戻すには、「リセット」をクリックします。

  5. 「更新」をクリックします。

    選択したファイル・タイプに対して、対応するデフォルトのファイル拡張子、ファイル形式および変換が、自動的にマップされます。

構成マネージャを使用する手順は次のとおりです。

  1. 管理者としてログインします。

  2. 「メイン」メニューから「管理」「管理アプレット」を選択します。

  3. 「構成マネージャ」を選択します。

  4. 「オプション」「ファイル形式」を選択します。

21.3.2.1 ファイル形式の追加または編集

ファイル形式を追加して変換にリンクする手順は次のとおりです。

  1. 「ファイル形式」ページで、「ファイル形式」セクションの「追加」をクリックします。

  2. 新しいファイル形式の追加/「ファイル形式の編集」ページで、「フォーマット」フィールドにファイル形式の名前を入力します。任意の名前を使用できますが、対応するファイル拡張子(複数の場合あり)に関連付けられているMIMEタイプを使用することをお薦めします。

  3. 「変換」リストから適切な変換を選択します。


    重要:

    このバージョンのInbound Refineryでは、一太郎の変換はサポートされていません。


  4. 「説明」フィールドにファイル形式の説明を入力します。

  5. 「OK」をクリックして設定を保存します。

ファイル形式を編集するには、ファイル形式を選択して「編集」をクリックします。新しいファイル形式の追加/「ファイル形式の編集」ページで、適切な変更を加えます。

21.3.2.2 ファイル拡張子の追加または編集

ファイル拡張子を追加し、ファイル形式にマップする(およびそれによりファイル拡張子を変換に関連付ける)手順は次のとおりです。

  1. 「ファイル形式」ページで、「ファイル拡張子」セクションの「追加」をクリックします。

  2. ファイル拡張子の追加/「ファイル拡張子の編集」ページで、ファイル拡張子を入力します。

  3. 「マップ先フォーマット」リストで、定義済ファイル形式のリストから適切なファイル形式を選択します。ファイル形式を選択すると、指定した拡張子を持つすべてのファイルが、そのファイル形式にリンクされている特定の変換に直接割り当てられます。

  4. 「OK」をクリックして設定を保存します。

ファイル拡張子を編集するには、「ファイル形式」ページでファイル拡張子を選択し、「編集」をクリックします。適切な変更を行います。

21.3.3 PassThruファイル用のコンテンツ・サーバーの構成

ファイル形式が変換PassThruにリンクされていると、そのファイル形式にマップされているすべてのファイル拡張子は変換用に送信されません。デフォルトでは、コンテンツ・サーバーはネイティブ・ファイルのコピーをweblayoutディレクトリに配置します。ただし、かわりにネイティブ・ボールト・ファイルを指すHCSTファイルをWebレイアウト・ディレクトリに配置するように、コンテンツ・サーバーを構成することもできます。これは、変換しない大きなファイルがあり、Webレイアウト・ディレクトリに大きなファイルをコピーしたくない場合に有用です。

次の重要な注意事項に留意してください。

  • HCSTファイルの内容は、redirectionfile_template.htmファイルの内容によって制御されます。

  • ファイルの配信にはGET_FILEサービスが使用されるため、PDFハイライトやバイト・サービングは利用できません。これは、テンプレートをオーバーライドし、Webサーバーを再構成することにより解決できます。

  • 単純なテンプレートを使用します。ブラウザの「戻る」ボタンが機能せず、レイアウトの相違が発生することがあります。これは、テンプレートをオーバーライドし、Webサーバーを再構成することにより解決できます。

  • Webレイアウト・ディレクトリにHCSTファイルがあるため、ファイル数は減りません。ただし、ネイティブ・ボールト・ファイルが大きい場合は、ディスク領域を節約できます。

  • この設定は、変換用にリファイナリに送信されるファイルには影響しません。つまり、ファイルが変換用にリファイナリに送信される場合、別のコンテンツ・サーバー設定によって、Web表示可能ファイルとネイティブ・ファイルのコピーのいずれがWebレイアウト・ディレクトリに配置されるかが制御され、HCSTファイルは使用できません。詳細は、第21.3.4項を参照してください。

ネイティブ・ファイルのコピーではなくHCSTファイルをWebレイアウト・ディレクトリに配置するようにコンテンツ・サーバーを構成する手順は次のとおりです。

  1. テキスト・エディタを使用して、IntradocDir/config/ディレクトリにある、コンテンツ・サーバーのconfig.cfgファイルを開きます。

  2. IndexVaultFile変数を追加し、値をtrueに設定します。

    IndexVaultFile=true
    
  3. config.cfgファイルへの変更内容を保存します。

  4. コンテンツ・サーバーを再起動します。

21.3.4 コンテンツ・サーバーのリファイナリ変換オプションの構成

変換前および変換後ジョブをコンテンツ・サーバーでどのように処理するかなど、コンテンツ・サーバーとそのリファイナリ・プロバイダとの対話方法を構成できます。


重要:

「Inbound Refinery変換オプション」ページを使用するには、コンテンツ・サーバーにInboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。


コンテンツ・サーバーが変換前および変換後ジョブをどのように処理するかを構成する手順は次のとおりです。

  1. 管理者としてコンテンツ・サーバーにログインします。

  2. 「メイン」メニューで「管理」「リファイナリ管理」「変換オプション」を選択します。

  3. リファイナリ変換オプション・ページで、次の情報を入力します。

    • 次に転送を試みるまでに変換前ジョブを待機する秒数を入力します。デフォルトは10(秒)です。

    • ネイティブ・ファイル圧縮しきい値サイズを入力します(MB単位)。デフォルトのしきい値サイズは1024MB (1GB)です。ネイティブ・ファイルは、しきい値サイズを超えないかぎり、圧縮されてから、コンテンツ・サーバーによってリファイナリに転送されます。この設定を使用すると、非常に大きなファイル(たとえば、大規模なビデオ・ファイル)の圧縮に伴うオーバーヘッドを回避できます。転送前にネイティブ・ファイルを圧縮しないようにする場合は、ネイティブ・ファイル圧縮しきい値サイズを0に設定します。

    • ジョブ転送の有効期限が切れた場合に変換が失敗するようにするには、該当するチェック・ボックスを選択します。

    • コンテンツ・サーバーが失敗した変換をどのように処理するかを指定します。ファイルがリファイナリに送信され、変換が失敗した場合に、ネイティブ・ファイルのコピーを/weblayoutディレクトリに配置するようにコンテンツ・サーバーを構成できます(「Refinery通過」)。通過を有効にするには、チェック・ボックスを選択します。通過を無効にするには、チェック・ボックスの選択を解除します。

      次の重要な注意事項に留意してください。

      • ファイルが変換用にリファイナリに送信される場合、ネイティブ・ファイルのコピーのかわりにHCSTファイルを使用することはできません。コンテンツ・サーバーがリファイナリに送信されないファイルをどのように処理するかを構成する方法の詳細は、第21.3.3項を参照してください。

      • この設定は、IntradocDir\config\ディレクトリにあるconfig.cgfファイル内のAllowPassthru変数を使用して手動でオーバーライドすることもできます。

  4. 最後に保存した設定に戻す場合は「リセット」をクリックし、変更を保存するには「更新」をクリックします。

  5. コンテンツ・サーバーを再起動します。

21.3.5 プレビューをバイパスするためのイメージ・ファイルの構成

一般的な形式のイメージ・ファイルについて、ネイティブ11gユーザー・インタフェースでは、通常、ほとんどのWebブラウザで表示できるネイティブ・ドキュメントのプレビューが表示されます。対照的に、Oracle WebCenter Contentユーザー・インタフェースでは、通常、ドキュメントの表示ページでドキュメントのプレビューを表示する前に、Outside In Technologyを使用してネイティブ・ドキュメントがページ・イメージに変換されます。

複数レイヤーのイメージ・ファイル(動画の.gifファイルなど)では、Outside Inによって、複数レイヤー・ファイルの各レイヤーについて、それぞれ1つのイメージが作成されます。この結果、元のイメージの各レイヤーについて、別々のページが存在することになります。ほとんどのWebブラウザで動画の.gifファイルおよび複数レイヤーの他の形式を適切に表示できるため、コンテンツ・サーバーでOutside Inをバイパスして、アニメーションを適切に表示することもできます。

Outside Inをバイパスしてネイティブ・ファイルを表示するには、管理者は、コンテンツ・サーバーのintradoc.cfgファイルのSimplePreviewFormatList変数に形式をリストします。これは、コンテンツ・サーバーにアクセスするブラウザでサポートされる形式(標準的なイメージ形式など)について行う必要があります。これによって、ブラウザでネイティブ・ファイルが表示され、複数レイヤーの動画ファイル形式が適切に解釈されます。

単純なプレビューを使用するために任意のイメージ形式を指定する手順は次のとおりです。

  1. テキスト・エディタを使用して、コンテンツ・サーバーのDomainDir/ucm/cs/binディレクトリにあるintradoc.cfgファイルを開きます。

  2. 単純なプレビューを使用するためのイメージ形式を、カンマ区切りリストで指定します。次に例を示します。

    SimplePreviewFormatList=image/gif,image/png
    
  3. intradoc.cfgファイルに加えた変更を保存します。

  4. コンテンツ・サーバーを再起動します。

21.3.6 チェックイン時の変換のオーバーライド

環境によっては、特定のファイル拡張子が複数の方法で使用されている場合があります。よい例がZIPファイル拡張子です。たとえば、次のようなファイルをチェックインすることが考えられます。

  • TIFF Converterを含むリファイナリに、OCRを使用して単一のPDFファイルに変換させる、単一のZIPファイルに圧縮された複数のTIFFファイル。

  • 変換用にリファイナリに送信しない、単一のZIPファイルに圧縮された複数のファイル・タイプ(ZIPファイルはそのネイティブ・フォーマットのまま通過させる必要があります)。

複数の方法でファイル拡張子を使用する場合は、ユーザーがファイルをコンテンツ・サーバーにチェックインするときにそのファイルをどのように変換するかを選択できるように、コンテンツ・サーバーを構成できます。これを、「チェックイン時にフォーマットのオーバーライドを許可」と呼びます。このコンテンツ・サーバーの機能を有効にする手順は次のとおりです。

  1. 管理者としてログインします。

  2. 「メイン」メニューから「管理」「管理サーバー」「一般構成」を選択します。

  3. 「チェックイン時にフォーマットのオーバーライドを許可」チェック・ボックスを選択します。

  4. 「保存」をクリックします。

  5. 構成マネージャを使用して、ファイル拡張子を最も一般的に使用される変換にマップし、それをデフォルト変換にします。たとえば、ZIPファイル拡張子では、次のようなデフォルト変換を設定できます。

    • ZIPファイル拡張子をapplication/zipファイル形式にマップし、application/zipファイル形式をTIFFConversion変換にマップします。したがって、デフォルトでは、ZIPファイルには複数のTIFFファイルが含まれ、OCRを使用したPDFへの変換用にTIFF Converterを含むリファイナリに送信すべきであることが想定されます。

  6. 構成マネージャを使用して、ユーザーがチェックイン時に選択できるようにする代替ファイル形式および変換を設定します。前述のZIPファイル拡張子の例では、次のような代替変換を設定できます。

    • application/zip-passthruファイル形式をPassThru変換にマップします。これで、変換用にリファイナリに送信すべきではない様々なファイルを含むZIPファイルに対して、チェックイン時にこのオプションを選択できるようになります。ZIPファイルはそのネイティブ・フォーマットで渡されることになります。

  7. コンテンツ・サーバーを再起動します。ユーザーはファイルのチェックイン時に、設定されているいずれかの変換を選択することにより、デフォルト変換をオーバーライドできます。

複数の専用のリファイナリやカスタム変換を使用している場合に、このようにユーザーがチェックイン時に変換をオーバーライドできるようにすることがあります。前述のZIPファイル拡張子の例を使用すると、TIFF Converterを持つ1つのリファイナリを、複数のTIFFファイルを含むZIPファイルをOCRを使用してPDFに変換するために使用し、2つ目のリファイナリを、Microsoft Officeファイルを含むZIPファイルをPDFに変換するために設定できます。

21.3.6.1 サムネイルのサイズの変更

デフォルトでは、サムネイルは100x100ピクセルで表示されます。異なるサイズで表示する手順は次のとおりです。

  1. IntradocDir/config/ディレクトリにあるconfig.cfgファイルをテキスト・エディタで開きます。

  2. 次の変数を必要に応じて変更し、サムネイルの高さと幅を変更します。

    • ThumbnailHeight=xxx (xxxはピクセル値)

    • ThumbnailWidth=xxx (xxxはピクセル値)

    小さい方の設定に基づいて(設定が等しい場合は高さ設定を使用)、縦横比を維持するようにスケーリングが実行されます。

  3. 変更内容を保存します。

  4. コンテンツ・サーバーを再起動します。


注意:

これにより、すべてのサムネイルのサイズが更新されます。


ThumbnailHeight変数およびThumbnailWidth変数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』を参照してください。

21.4 ステータスの詳細の表示

この項では、変換ジョブのステータスを表示する方法を説明します。次の内容について説明します。

21.4.1 リファイナリの変換ステータス

リファイナリの変換ステータスを表示するには、メイン・メニューを使用して、「管理」「リファイナリ管理」「変換オプション」を選択します。「IBRプロバイダのステータス」ページの「変換ジョブのステータス」タブをクリックすることもできます。


重要:

このページを使用するには、InboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。


このページには、次の情報が表示されます。

要素 説明

リフレッシュ

表示されたジョブのステータスを更新します。

ジョブ・キューのチェックの強制

コンテンツ・サーバーにジョブをリファイナリ・プロバイダに配信させます。これは、リファイナリが停止し、保留中のジョブが失敗した場合に特に有用です。この状況では、保留中のジョブは定期的に変換用にプロバイダに再送信されます。このボタンは、送信を強制的に行います。

変換ジョブID

Inbound Refineryによって送信された各ジョブに割り当てられる一意の識別子。

コンテンツID

変換用に送信されたコンテンツ・アイテムの一意のコンテンツ・サーバー識別子。

変換ジョブの状態

ジョブが変換処理内のどこにあるかを示します。

プロバイダに送信されたジョブ

ジョブの送信先のプロバイダを示します。

最終アクション

ジョブの状態の最後の変更日時をリストします。

アクション

変換用に送信されたコンテンツ・アイテムに対するコンテンツ・サーバーの「コンテンツ情報」ページにリンクします。


21.4.2 IBRプロバイダのステータス

IBRプロバイダのステータスを表示するには、メイン・メニューを使用して、「管理」「リファイナリ管理」「IBRプロバイダのステータス」を選択します。リファイナリ変換ジョブのステータス・ページの「IBRプロバイダのステータス」タブをクリックすることもできます。


重要:

このページを使用するには、コンテンツ・サーバーにInboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。


「IBRプロバイダのステータス」ページに、次の情報が表示されます。

要素 説明

ステータスの更新の強制

表示されたプロバイダのステータスを更新します。

プロバイダ

各プロバイダの名前。

使用可能

プロバイダがコンテンツを変換用に承認しているかどうかを示します。

読取り専用

プロバイダが読取り専用であること、つまりジョブを変換用にこれ以上承認できないことを示します。コンテンツ・サーバーに変換を返すことしかできません。

キューに格納されたジョブ

各プロバイダで変換を待機しているジョブの数を示します。

最終メッセージ

プロバイダによって最後に配信されたステータス・メッセージを表示します。

接続状態

プロバイダがコンテンツ・サーバーに接続されているかどうかを示します。

最終アクティビティの日付

最後のプロバイダ・アクティビティの日時をリストします。

アクション

特定のプロバイダに関する情報を示す「プロバイダ情報」ページを表示します。


21.5 リファイナリの変換設定の構成

リファイナリの変換設定を構成する前に、次の作業を実行する必要があります。

リファイナリ変換設定は、リファイナリがどの変換を承認し、各変換をどのように処理するかを制御します。Inbound RefineryにはOutside In Image Exportが含まれ、これは次の目的で使用できます。

また、Inbound Refineryではいくつかの変換オプションを使用できます。変換オプションを有効にすると、その変換設定がリファイナリに追加されます。

このセクションのトピックは次のとおりです:

21.5.1 タイムアウトの計算

リファイナリでの処理時に、コンテンツには、ファイルのサイズと「タイムアウトの設定」ページの設定に基づいて、一定の処理時間が割り当てられます。タイムアウト値(分単位)は、次のように計算されます。

タイムアウト値[分単位] = ([バイト単位のファイル・サイズ] × タイムアウト・ファクタ) / 60,000

まずInbound Refineryは、使用するファイルを特定するために、前のステップでファイルが生成されたかどうかを確認します。該当する場合、そのファイルがタイムアウトの計算に使用されます。そうでない場合は、ネイティブ・ファイルを使用します。前のステップで複数のファイルが出力される場合は(たとえばExcelからPostScriptへの変換)、ファイル・サイズの合計を使用します。処理対象のコンテンツ・アイテムは、「最低 (Minimum)」列以上、「最高 (Maximum)」列未満の分数に割り当てられます。計算されたタイムアウト値が最低値を下回ると、最低値が適用されます。計算されたタイムアウト値が最高値を超えると、最高値が適用されます。

21.5.1.1 タイムアウト計算

次の各例は、タイムアウトの計算方法を示しています。

  • 例1

ファイル・サイズ = 10 MB (10485760バイトまたは10240 KB)
最低 = 2
最高 = 10
ファクタ = 3
計算されるタイムアウト = 10485760×3 / 60000 = 524.288分 = 8.74時間

この場合、Inbound Refineryは最高値の10分間のみ待機します。

  • 例2

ファイル・サイズ = 200 KB (204800バイト)
最低 = 2
最高 = 30
ファクタ = 2
計算されるタイムアウト = 204800×2 / 60000 = 6.83分

この場合、Inbound Refineryは最高値の30分間ではなく、計算された6.83分間のみ待機します。

  • 例3

ファイル・サイズ = 50 KB (51200バイト)
最低 = 2
最高 = 30
ファクタ = 2
計算されるタイムアウト = 51200×2 / 60000 = 1.71分
この場合、Inbound Refineryは計算されるタイムアウト値または最高値の30分間ではなく、最低値の2分間のみ待機します。

21.5.2 承認される変換の設定

リファイナリが承認し、キューに入れる変換の最大数を設定する手順は次のとおりです。

  1. リファイナリにログインします。

  2. 「変換設定」「変換リスト」を選択します。

  3. 「変換リスト」ページで、リファイナリでキューに入れることのできる変換ジョブの合計数を設定します。デフォルトは0 (無制限)です。

  4. コンテンツ・サーバーによるピックアップを待機可能な変換の最大数を入力します。この数を超えると、Inbound Refineryはそのコンテンツ・サーバーからの変換ジョブを承認しなくなります。デフォルトは1000です。

  5. 変換が最大数に達しているとき、リファイナリをビジー状態とみなす秒数を入力します。デフォルトは120 (秒)です。リファイナリの変換ジョブが最大数に達した場合、コンテンツ・サーバーはこの時間待機してから、リファイナリとの通信を再度試行します。

  6. リファイナリが同時に処理する変換の最大数を入力します。デフォルトは5です。

  7. リファイナリが承認するように設定する各変換に対するチェック・ボックスを選択します。

    • デフォルトでは、すべての変換が選択され、承認されます。

    • すべての変換を選択するには、列見出しの「承認」チェック・ボックスを選択します。

    • すべての変換の選択を解除するには、列見出しの「承認」チェック・ボックスの選択を解除します。


      重要:

      このバージョンのInbound Refineryでは、一太郎およびLegacyCustomの変換はサポートされていません。


  8. 変換タイプごとに(すべてのリファイナリ・キューにわたる)ジョブの最大数を設定します。デフォルトは0 (無制限)です。

  9. 「更新」をクリックして変更を保存します。

  10. リファイナリに対するエージェントである各コンテンツ・サーバーを再起動して、コンテンツ・サーバーのキューに対する変更を即時に有効にします。そうしない場合、リファイナリの承認済の変換に対する変更は、次回にコンテンツ・サーバーがリファイナリをポーリングするときまでコンテンツ・サーバーに認識されません。

21.5.3 プライマリWeb表示可能レンディションとしての複数ページTIFFファイルの設定

Inbound Refineryには、ファイルをプライマリWeb表示可能レンディションとして複数ページのTIFFファイルに変換するために使用される、Outside In Image Exportが含まれています。これにより、ユーザーはTIFFビューア・プラグインを備えた標準的なWebブラウザでファイルを表示できます。

PDF Exportなどのその他の変換オプションを使用すると、プライマリWeb表示可能レンディションとしてその他のタイプのレンディションを作成できます。Web表示可能レンディションを生成できる変換オプションが有効になっていると、追加のオプションが指定可能になります。

複数ページのTIFFファイルをリファイナリが生成するプライマリWeb表示可能レンディションとして設定する手順は次のとおりです。

  1. リファイナリにログインします。

  2. 「変換設定」「プライマリWebレンディション」を選択します。

  3. プライマリWeb表示可能レンディションとしてファイルを複数ページのTIFFファイルに変換するには、「プライマリWeb表示可能レンディション」ページで「Outside Inを使用して複数ページのTIFFに変換」を選択します。

  4. 「更新」をクリックして変更を適用します。

21.5.4 サムネイルの設定

サムネイルは、コンテンツの小さなプレビュー・イメージとして検索結果のページで使用され、通常は、それらが表すWeb表示可能ファイルにリンクしています。サムネイルによって、実際にファイル自体を開くことなく確認できる、視覚的なサンプルがコンシューマに示されます。これにより、より大きい元のファイルのダウンロードを行う前に、ファイルを確認できます。

Inbound RefineryにはOutside In Image Exportが含まれ、これを使用してファイルのサムネイルを作成できます。次の重要な注意事項に留意してください。

  • サムネイル作成用にリファイナリにファイルを送信するには、各コンテンツ・サーバーでファイル形式および変換を構成する必要があります。詳細は、21.3項を参照してください。リファイナリが変換を承認するように構成されている必要があります。詳細は、21.5.2項を参照してください。

  • Outside In Image Exportサムネイル・エンジンは、Type 3フォントを含むPDFファイルのサムネイルを正常に作成することはできません。チェックインされたPDFファイルにType 3フォントが含まれると、Outside In Image Exportサムネイル・エンジンは空白ページのサムネイルを作成します。

  • サムネイル・ファイルは、JPEG、GIFまたはPNGファイルとして、コンテンツ・サーバーのweblayoutディレクトリに格納され、そのファイル名には文字@tが含まれます。たとえば、Report2001@t~2.jpgファイルはReport2001~2.pdf(Report2001.xxxというファイルのリビジョン2)に属するサムネイルです。

  • 暗号化またはパスワード保護されているファイルに対してサムネイルを作成することはできません。

  • EMLファイルに対するサムネイルを作成できます。Internet Explorerを使用していて、Outlook Express用の累積的な修正プログラム(2003年4月)をインストールしている場合、サムネイルをクリックしてEMLファイルを表示しようとするとエラーが発生します。これは、プライマリWeb表示可能ファイルがEMLファイルである場合(リファイナリによってプライマリWeb表示可能ファイルとして複数ページのTIFFまたはEMLファイルのPDFバージョンが作成されておらず、ネイティブEMLファイルがプライマリWeb表示可能ファイルとしてWebレイアウト・ディレクトリにコピーされている場合)にのみ当てはまります。

  • EMLファイルのサムネイルは、Outlook ExpressでそのEMLファイルを開いたときのルック・アンド・フィールと正確に一致しません。これは、サムネイルはプレーン・テキスト・レンディションに基づいて作成されるのに対し、Outlook Expressではファイルは独自の形式で開かれるためです。

  • コンテンツ・サーバーに表示されるサムネイル・サイズの変更方法の詳細は、第21.3.6.1項を参照してください。

  • Inbound Refineryでサムネイルをオフにしても、作成済のサムネイルは検索結果ページに表示され続けることに注意してください。

サムネイルは、Inbound Refineryでデフォルトで使用可能な唯一の追加のレンディションです。その他の変換オプションやカスタム変換を使用すると、追加のレンディションを作成できます。

サムネイルを有効にし、サムネイルの設定を構成する手順は次のとおりです。

  1. リファイナリにログインします。

  2. 「変換設定」「追加レンディション」を選択します。

  3. 「追加レンディション」ページで、「Outside Inを使用するサムネイル・イメージの作成」を選択します。

  4. 「更新」をクリックして変更を保存します。

  5. 「オプション」をクリックします。

  6. 「サムネイル・オプション」ページで、必要なサムネイル・オプションを選択します。終了後、「更新」をクリックします。


    注意:

    Solarisを実行するSPARCシステム、またはLinuxを実行するいずれかのシステム上でのInbound Refineryの使用時には、Outside In Image Exportはフォントおよびグラフィックのレンダリングにデフォルトでその内部グラフィック・コードを使用します。かわりに、オペレーティング・システムのネイティブ・グラフィック・サブシステムを使用することも選択できます。詳細は、21.5.5項を参照してください。


次のリストに、使用可能なオプションを示します。

要素 説明

「ネイティブ・ボールト・ファイルからサムネイル・イメージを作成」チェック・ボックス

サムネイル・イメージをネイティブ・ファイルから作成するか、Web表示可能プライマリ・ファイルから作成するかを指定します。

「サムネイル・イメージ作成に使用するネイティブ・ボールト・ファイルのページ番号」フィールド

サムネイル・イメージの作成に使用するネイティブ・ファイルのページを指定します。デフォルト設定は1です。ネイティブ・ファイルの最初のページが、サムネイル・イメージの作成に使用されます。

「クイック・サイジングを使用」ラジオ・ボタン

最も高速のカラー・グラフィック変換を指定しますが、変換されたグラフィックの品質は若干低下します。

「スムーズ・サイジングを使用」ラジオ・ボタン

元のグラフィックのより正確な表現を指定しますが、複雑な処理が必要になるため、変換速度が若干低下します。これがデフォルトの設定です。

「グレイスケール・グラフィック用のスムーズ・サイジング」ラジオ・ボタン

グレイスケール・グラフィックにスムーズ・サイジング・オプションを使用し、すべてのカラー・グラフィックにクイック・サイジング・オプションを使用します。

「jpgのサムネイルの生成」ラジオ・ボタン

すべてのサムネイルがJPGファイルとして作成されるように指定します。これは、サムネイルのファイル・タイプのデフォルト設定です。

「gifのサムネイルの生成」ラジオ・ボタン

すべてのサムネイルがGIFファイルとして作成されるように指定します。

「pngのサムネイルの生成」ラジオ・ボタン

すべてのサムネイルがPNGファイルとして作成されるように指定します。

「更新」ボタン

設定に加えた変更内容を保存します。

「リセット」ボタン

前回保存した設定に戻します。


21.5.5 UNIXでのレンダリング・オプションの構成

LinuxまたはSolaris SPARCでInbound Refineryを実行している場合に複数ページのTIFFファイルまたはサムネイルを作成するとき、Outside Inはフォントおよびグラフィックのレンダリングにデフォルトでその内部グラフィック・コードを使用します。したがって、実行中のX Window Systemディスプレイ・サーバー(Xサーバー)へのアクセスおよびMotif (Solaris)またはLessTif (Linux)は必要ありません。システムで実行する必要があるのは、使用可能なフォントを検出することだけです。フォントはOutside Inには付属していません。使用可能なフォントへのパスの設定方法の詳細は、第21.5.6項を参照してください。

Image Exportがフォントとグラフィックのレンダリングに、その内部グラフィック・コードではなくオペレーティング・システムのネイティブのグラフィック・サブシステムを使用するようにInbound Refineryを構成する手順は次のとおりです。

  1. Inbound RefineryコンピュータにInbound Refineryユーザーとしてログインします。

  2. Inbound Refineryコンピュータが実行中のX Window Systemディスプレイ・サーバー(Xサーバー)にアクセスでき、Motif (Solaris)またはLessTif (Linux)が存在する必要があります。

  3. Inbound Refineryの起動スクリプト(.profile.login.bashrcなど)内のDISPLAY変数が実行中のXサーバーを指していることを確認します。次に例を示します。

    DISPLAY=:0.0
    export DISPLAY
    
  4. 新しい.profileをソースします。たとえば/usr/bin/shを使用して次のコマンドを実行します。

    ..profile
    
  5. 次のコマンドを実行して、実行中のXサーバーを使用するパーミッションをOutside In Image Exportに付与します。

    xhost +localhost
    
  6. Inbound Refineryユーザーはログインした状態のまま、コンソールをロックします。

  7. リファイナリにログインします。

  8. 「変換設定」「サードパーティ・アプリケーションの設定」を選択します。

  9. 「サードパーティ・アプリケーションの設定」ページで、「標準のOutsideInフィルタ・オプション」セクションの「オプション」をクリックします。

  10. 「ネイティブ・オペレーティング・システムのネイティブ・グラフィック・サブシステムを使用」を選択します。

  11. 「更新」をクリックします。

21.5.6 フォント・パスの指定

Inbound Refineryが正常に機能するには、フォント・イメージを生成するために使用されるフォントへのパスを指定する必要があります。デフォルトでは、フォント・パスはInbound Refineryで使用されるJVM内のフォント・ディレクトリ(java.home/lib/fonts)に設定されます。ただし、デフォルト・ディレクトリに含まれるフォントは限定されているため、レンディションが低下する可能性があります。また、非標準のJVMを使用した場合、デフォルトで指定されているJVMのフォント・パスと異なることがあります。この場合、エラー・メッセージがInbound Refineryとコンテンツ・サーバーの両方から表示されます。これが発生した場合は、変換を正しくレンダリングするために必要なフォントを含むディレクトリにフォント・パスが設定されていることを確認してください。

使用可能なフォントを検出するようにInbound Refineryを構成する手順は次のとおりです。

  1. Inbound RefineryコンピュータにInbound Refineryユーザーとしてログインします。

  2. 「変換設定」の下の「サードパーティ・アプリケーションの設定」をクリックします。

  3. 「サードパーティ・アプリケーションの設定」ページで、「標準のOutsideInフィルタ・オプション」セクションの「オプション」をクリックします。

  4. テキスト・フィールドに、Outside Inで使用するフォント・ディレクトリへのパスを入力します。たとえばLinuxでは、次のように指定します。

    /usr/lib/X11/fonts/TTF
    

    Windowsでは次のように指定します。

    C:\WINDOWS\Fonts
    

    フォントがコールされた場合に見つからないと、Outside Inはエラーを表示して終了します。TrueTypeフォント(*.ttfまたは*.ttcファイル)のみがサポートされています。

  5. 「更新」をクリックします。

21.5.7 グラフィック変換に対するタイムアウト設定の構成

グラフィック変換に対するタイムアウト設定を構成する手順は次のとおりです。

  1. リファイナリにログインします。

  2. 「変換設定」「タイムアウトの設定」を選択します。

  3. 「タイムアウトの設定」ページで、「グラフィック」変換に対する「最低(Minimum)」(分単位)、「最高(Maximum)」(分単位)および「ファクタ」を入力します。詳細は、21.5.1項を参照してください。

  4. 「更新」をクリックして変更を適用します。