JP6736440B2

JP6736440B2 - クラウドシステムにおける文書ファイルの生成サービスを提供する装置、方法及びプログラム

Info

Publication number: JP6736440B2
Application number: JP2016188119A
Authority: JP
Inventors: 南陽母里
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-09-27
Filing date: 2016-09-27
Publication date: 2020-08-05
Anticipated expiration: 2036-09-27
Also published as: US20180089202A1; US10747715B2; JP2018055241A

Description

クラウドシステム上で文書ファイルを生成する技術に関する。

近年、サーバコンピュータ側で業務データの管理や各種処理を行う形態として、クラウドコンピューティングシステム（以下、「クラウドシステム」）が普及し始めている。ユーザは、クライアント装置のWebブラウザからインターネットを介してクラウドサーバのWebページにアクセスし、そのWebページ上で業務データを生成・閲覧・編集することができる。具体的には、ユーザがWebページを介して業務データをアップロードすると、クラウドサービスによって所定フォーマットの文書ファイルが生成されてWebブラウザ上に表示される。また、生成された文書ファイルはストレージに保存され、ユーザは保存された文書ファイルをダウンロードしてWebブラウザ上に表示させて、当該文書の編集を行うことができる。

クラウドサービスが生成する文書ファイルの所定フォーマットの一例としてSVG(Scalable Vector Graphics)が挙げられる。SVGは、XML (Extensible Markup Language)をベースとした、ベクタ形式で画像を描画するフォーマットであり、Webブラウザでの表示に関して親和性が高いと言われている。また、SVGは、同じベクタ形式のフォーマットであるPDF(Portable Document Format)とは異なり、各種リソースを別ファイルとしても構成できるという特徴を持っている。そのため、同じ描画内容でもSVGの構成によってファイル数が異なるという特徴がある。具体的には、複数のリソースを、インライン方式で記述する場合にはファイル数が少なく、外部参照方式で記述する場合にはファイル数が多くなる。

上述の通り、クラウドサービスによって生成された文書ファイルは、クラウドサーバの構成要素としてのストレージに保存され、クライアント装置はWebブラウザで表示する際にストレージにアクセスして文書ファイルを取得する。ストレージは、クラウドシステム上の複数のクライント端末からのアクセスを受け付けるため、一定以上の負荷が掛かるとアクセスが制限されるようになっている。ストレージに保存されているファイルへのアクセス数が単位時間あたりで一定数を超過してアクセス制限が生じると、ユーザは、現在処理中のファイルの読み込みや書き込み処理が完了するまで待機を余儀なくされてしまう。この点、アクセスが集中しても可能な限りアクセス制限が生じないようにするには、SVG形式で文書ファイルを生成する際にインライン方式を適用すればよいということになる。しかしながら、インライン方式の場合には、ファイル数が少なくなる分だけ１ファイルあたりのデータサイズが大きくなり、生成された文書ファイルのページをクライアント装置で表示する際の処理が重くなるという欠点がある。したがって、クラウドシステム上で文書ファイルを生成・保存するにあたっては、ファイル数の抑制と表示処理のパフォーマンス維持というトレードオフの関係にある事項の両立を図る必要がある。

特開２０１５−５１５０号公報

クラウドシステム上で扱われる文書ファイルの構成を条件に基づいて変更する手法としては、例えば、特許文献１がある。これは、PDF形式で文書ファイルを生成する際に、描画データ中のリソースの一種であるフォントの埋め込み指定の有無を判定し、指定があった場合はフォントを文書ファイルに埋め込むというものである。しかし、この特許文献１の手法は、生成される文書ファイルのファイル数に変化はなく、SVGのような構造の文書ファイルを生成するケースにおける、ファイル数の抑制と表示処理パフォーマンスとの両立という課題解決には役立たない。

本発明に係るサーバ装置は、文書ファイルの生成サービスを提供するサーバ装置であって、文書ファイルの元になる元データをクライアント装置から受け取る通信手段と、前記元データに含まれる複数のリソースに基づいて文書ファイルを生成するファイル化手段と、生成された文書ファイルをストレージに保存する保存手段と、を備え、前記ファイル化手段は、前記ストレージへのアクセス状況に応じて、前記元データに含まれる複数のリソースそれぞれに対してインライン方式又は外部参照方式のいずれを適用するか判定し、当該判定の結果に基づいて前記文書ファイルを生成する、ことを特徴とする。

本発明によれば、クラウドシステム上で文書ファイルの生成・保存のサービスを提供する場合において、ストレージへのアクセス状況に応じ、生成する文書ファイルの構成が変更される。これにより、ファイル数の抑制と表示パフォーマンスの維持を両立させることが可能になる。

クラウドシステムの構成例を示す図である。クラウドサーバ及びクライアント装置のハードウェア構成の一例を示すブロック図である。クラウドシステムを実現するソフトウェアの構成例を示す図である。ファイル生成サービスの内部構成を示す図である。 SVG文書のファイル構成の一例を示す図であり、（ａ）は外部参照方式、（ｂ）はインライン方式を示す。データストレージがSVG文書を格納する際のデータ構造の一例を示す図である。実施例１に係る、ファイル化処理の流れを示すフローチャートである。実施例１に係る、同一の元データから生成される3種類のSVG文書のファイル構成を説明する図である。実施例１の変形例によって生成される、SVG文書のファイル構成を説明する図である。実施例２に係る、ファイル化処理の流れを示すフローチャートである。実施例２によって生成される、SVG文書のファイル構成を説明する図である。実施例３に係る、ファイル化処理の流れを示すフローチャートである。実施例３によって生成される、SVG文書のファイル構成を説明する図である。

以下、添付図面を参照して、本発明を好適な実施例に従って詳細に説明する。なお、以下の実施例において示す構成は一例にすぎず、本発明は図示された構成に限定されるものではない。

＜システム構成＞
本実施例では、クライアント装置からの要求に従い、クラウドサーバがSVG形式の文書ファイルを生成・保存するクラウドサービスを提供する場面を前提として説明を行うものとする。図１は、クラウドコンピューティングシステム（クラウドシステム）の構成例を示す図である。クラウドシステム１００は、クラウドサービスを提供するサーバ装置（クラウドサーバ）１０２と、複数のクライアント装置１０３とで構成され、これらがLAN１０４とインターネット１０１を介して相互に接続されている。インターネット１０１は、ファイアウォールを越えてクラウドサーバ１０２とクライアント装置１０３との間で、SVG形式の文書ファイルを生成する際の元になるデータ（以下、「元データ」と呼ぶ。）やユーザ指示をやり取りするための通信回線である。クライアント装置１０３は、各ユーザに割り当てられたパーソナルコンピュータやタブレット、スマートフォンなどの端末を指す。また、LAN１０４、インターネット１０１は、例えば、TCP／IPプロトコルなどをサポートする通信回線網であり有線・無線は問わない。尚、クラウドサーバ１０２は、1台のコンピュータでもよいし、機能・役割に応じた複数のコンピュータで構成してもよい。例えば、Webサービスを担うWebサーバ、文書ファイルの生成サービスを担うアプリケーションサーバ、データ保存を担うストレージサーバといったように複数のコンピュータで構成してもよい。また、複数のコンピュータでクラウドサーバ１０２を実現する場合は、その一部が仮想ＰＣとして構成されていても構わない。

図２は、クラウドサーバ１０２及びクライアント装置１０３のハードウェア構成の一例を示すブロック図である。CPU２０１は、ROM２０６内部のプログラム領域に記憶されたプログラム、ハードディスク２０３からRAM２０２にロードされたOS、汎用アプリケーションなどのプログラムを実行する。RAM２０２は、CPU２０１の主メモリ、ワークエリア等として機能する。ハードディスク２０３は、ブートプログラム、種々のアプリケーション、フォントデータ、ユーザファイル、電子原稿ファイルなどを記憶する。本実施例におけるSVG形式の文書ファイル（以下、単に「SVG文書」と呼ぶ。）の生成・保存サービスを実現するプログラムは、クラウドサーバ１０２のハードディスク２０３に記憶されており、RAM２０２に読み出されCPU２０１によって実行される。ディスプレイコントローラ２０４は、不図示のディスプレイの表示制御を行う。ネットワークコントローラ２０５は、ネットワークに接続された他の機器との通信制御を行う。

図３は、クラウドシステム１００を実現するソフトウェアの構成例を示す図である。クライアント装置１０３は、Webページを閲覧するためのWebブラウザ３０１と、帳票などの元データを作成・編集するための文書編集アプリケーション（以下、「文書編集アプリ」と呼ぶ。）３０２とを備える。ユーザは、Webブラウザ３０１を用いてクラウドサーバ１０２にアクセスする。そして、SVG文書の生成指示（文書編集アプリ３０２で作成した元データのアップロード）や、自身のクライアント装置１０３にSVG文書を表示させる指示（保存されたSVG文書のダウンロード）を、クラウドサーバ１０２に対して行う。

クラウドサーバ１０２は、Webサービス３１１によって、Webブラウザ３０１と通信し、クライアント装置１０３からの要求、すなわち、SVG文書の生成や表示といったユーザ指示を処理する。例えばSVG文書の生成が要求された場合、クラウドサーバ１０２は、当該要求に対応する元データを、SVG形式でのファイル化を指示するジョブ（以下、単に「ジョブ」と呼ぶ。）と共に、ファイル生成サービス３１２へと渡す。ファイル生成サービス３１２は、受け取った元データとジョブに基づいてSVG文書を生成する。生成されたSVG文書は、データストレージ３１３にそのジョブと共に格納される。また、クライアント装置１０３からの要求がSVG文書の表示（取得）であれば、指定されたSVG文書がデータストレージ３１３からWebサービス３１２を介して読み出され、クライアント装置１０３に送られる。クライアント装置１０３では、Webブラウザ３０１を介して受け取ったSVG文書に基づき各ページをその画面上に表示する。ユーザは、自身のクライアント装置１０３に表示されたページを編集し、編集後の内容で新たなSVG文書の生成をWebブラウザ３０１を介して再び指示して、再保存させることができる。

＜ファイル生成サービス＞
次に、本実施例の特徴である、ファイル生成サービス３１２について詳しく説明する。ファイル生成サービス３１２は、クライアント装置１０３からの要求の多寡に応じてその起動数が変動する。つまり、要求が多いほどそれを処理するためにより多くのファイル生成サービス３１２が起動されることになる。図４は、ファイル生成サービス３１２の内部構成を示す図である。ファイル生成サービス３１２は、データ取得モジュール４０１、アクセス解析モジュール４０２、ファイル化モジュール４０３、ファイル保存モジュール４０４から構成されている。

データ取得モジュール４０１は、クライアント装置１０３から送信された元データを、Webサービス３１１を介して取得するモジュールである。ここで、元データには、例えば帳票のフォームデータや、ユーザがクライアント装置１０３上で当該帳票のフォームデータに入力した氏名や住所等の情報が含まれる。また、元データの形式は文書編集アプリ３０２に依存したもの（例えばword等）で構わない。ファイル化モジュール４０３が処理可能な形式と元データの形式とが異なる場合は、データ取得モジュール４０１において、所定の中間データ（例えばPDF）に変換するような構成であってもよい。アクセス解析モジュール４０２は、データストレージ３１３に対するアクセス状況を解析し、インライン方式でSVG文書を生成する場合におけるリソースの条件を決定するモジュールである。ファイル化モジュール４０３は、元データからリソースを取得して、インライン方式又は外部参照方式を適用してSVG文書を生成する処理（ファイル化処理）を行うモジュールである。ファイル化処理の詳細は後述する。ファイル保存モジュール４０４は、生成されたSVG文書を、データストレージ３１３に保存する処理を行うモジュールである。

＜外部参照方式とインライン方式＞
ここで、SVG文書のファイル構成について確認しておく。図５はSVG文書のファイル構成の一例を示す図であり、（ａ）は外部参照方式の場合、（ｂ）はインライン方式の場合を示している。図５の（ａ）及び（ｂ）において、矩形は1つのファイルを表しており、１つ１つの矩形が何らかの情報を表している。また、矩形同士を結ぶ線はファイル間で参照関係があることを表している。

はじめに、インライン方式と外部参照方式との共通点について説明する。図５の（ａ）及び（ｂ）から明らかなように、いずれの方式においても、ツリー構造のルートがHTMLファイル５０１又は５１１となっている。HTMLファイルは、SVG文書をクライアント装置１０３のWebブラウザ３０１で表示するために必要なファイルである。そして、このHTMLファイル５０１又は５１１の下流にあるファイルが、SVGファイル５０２又は５１２である。ここで、SVGファイルは、拡張子が“.svg”のファイルであり、１ページに付き１つ存在する。

続いて、外部参照方式のファイル構成について説明する。外部参照方式では、描画で使用するリソースがSVGファイル５０２の外に別のファイル（外部ファイル）５０３として存在する。そして、当該外部ファイル５０３がSVGファイル５０２から参照されるというファイル構成である。図５（ａ）では、スタイル情報を表す“css”、画像情報を表す“jpg”及び“png”、フォント情報を表す“ttf”が外部ファイルとして個別に存在し、SVGファイル５０２から参照されている。外部参照方式の特徴として、ファイル１個あたりのデータサイズが小さくなり、且つ、オブジェクト単位で表示が可能である点が挙げられる。その結果、クライアント装置１０３にページを表示する際に、読み込みが済んだオブジェクトから段階的に表示されるため、インライン方式と比較すると、ユーザが感じるストレスが小さい。一方で合計ファイル数が多くなるため、データストレージ３１３へのファイルの書き込みや読み出しといったアクセス負荷が高くなってしまう。

次に、インライン方式のファイル構成について説明する。インライン方式では、描画で使用するリソースがSVGファイルの中に含まれている構成である。図５（ｂ）では、図５（ａ）で外部参照されていたスタイル情報、画像情報、フォント情報がSVGファイル５１２内に記述されている。インライン方式の特徴として、ファイル１個あたりのデータサイズが大きくなり、１ページを表示するのに全てのリソースを読み込む必要があるという点が挙げられる。そのため、外部参照方式よりも１ページの表示に時間が掛かる。一方、同一内容のデータで比較するとファイル数が外部参照方式より少なくて済むため、データストレージ３１３へのアクセス負荷は外部参照方式よりも小さくなる。

上述の通り、外部参照方式とインライン方式にはそれぞれに長所と短所があり、両者はトレードオフの関係にある。本実施例に係る発明は、双方の長所を極力生かすために最適な構成でファイル化処理を行うことを目的としている。

続いて、ファイル化モジュール４０３で生成されたSVG文書が、データストレージ３１３にどのように格納・管理されるかについて説明する。図６は、データストレージ３１３がSVG文書を格納する際のデータ構造の一例を示す図である。図６に示すように、生成されたSVG文書は、「ジョブID」６０１、「ファイル名」６０２、「URL」６０３、「アクセス済フラグ」６０４の4つの項目で管理される。

「ジョブID」６０１は、ファイル化モジュール４０３におけるファイル化処理を一意に識別するための識別子である。データストレージ３１３に保存されている複数のレコードのうち、「ジョブID」６０１が同一のものは同じファイル化処理で生成されたファイルである。

「ファイル名」６０２は、ファイル化処理で生成されたSVG文書の名称を表す。「ジョブID」６０１が同じレコード内に「ファイル名」６０２が同じファイルは存在しないが、「ジョブID」６０１が異なる場合は「ファイル名」６０２が同じファイルが存在する場合がある。

「URL」６０３は、各ファイルが格納されている位置を表すパスである。この「URL」６０３は各ファイルで一意である。また、「URL」６０３によりファイル間の階層関係が表される。Webブラウザ３０１はこのURLにアクセスすることでSVG文書を表示することができる。

「アクセス済フラグ」６０４は、各ファイルがクライアント装置１０３のWebブラウザ３０１によって既にアクセスされたか否かを表すフラグである。本実施例では、“TRUE”が設定されていればアクセス済みを表し、“FALSE”が設定されていれば未だアクセスされていないことを表す。図６の例では、「ジョブID」６０１が“1”のジョブに属するファイルはアクセス済みであり、“2”のジョブに属するファイルは未アクセスということになる。ここで、「アクセス済フラグ」６０４に“TRUE”が設定されているということは、生成・保存されたSVG文書がクライアント装置１０３上に表示されたことを意味する。クライアント装置１０３に表示されたSVG文書のページ内容をユーザが編集し、その都度、新たなSVG文書の生成・保存を行うようなユースケースでは、同じファイルに再びアクセスされることはない。したがって、このようなユースケースにおいて、「アクセス済フラグ」６０４に“FALSE”が設定されている場合は、これから編集のためにアクセスされる可能性の高いSVG文書の構成ファイルであることがわかる。したがって、「アクセス済フラグ」６０４は、データストレージ３１３へのアクセスが同時期にどの程度発生し得るか（同時アクセスが一定数以上見込まれるかどうか）を推し量る指標となり得る。

次に、ファイル生成サービス３１２における、元データからSVG文書を生成し保存するファイル化処理について説明する。図７は、本実施例に係る、ファイル化処理の流れを示すフローチャートである。

ステップ７０１では、データ取得モジュール４０１が、クライント端末１０３から送られた元データを取得する。

ステップ７０２では、アクセス解析モジュール４０２が、データストレージ３１３に対するアクセス状況を解析する。具体的には、前述の「アクセス済フラグ」６０４及び「ジョブID」６０１を参照し、“FALSE”が設定されているファイルを有するジョブの数を取得し、当該取得したジョブ数と予め定めた閾値とを比較して、アクセス状況をレベル分け（例えば3段階に分類）する。上述の通り“FALSE”が設定されているファイルは未だクライアント装置１０３上で表示されていないため、今後表示を行うためにファイルアクセスが発生する可能性が高い。よって、“FALSE”が設定されているファイルを有するジョブの数が多いときは、多くのファイルアクセス数が同じタイミングで発生する可能性が高いことを意味する。ここで、アクセス状況を例えば「多」「中」「少」の3段階に分類するとする。この場合、例えばジョブ数が50以上は「多」、25未満は「少」、その間は「中」といった具合に2つの閾値を用意しておけばよい。仮に「多」と「少」の2段階に分類する場合であれば閾値は1つで済むことになる。もちろん、分類数をもっと多くしても構わない。さらには、ジョブ数に代えて、端的に“FALSE”が設定されているファイル数に基づいてアクセス状況を判定してもよい。この場合の閾値は、入力される元データにも拠るがジョブ数の10倍から100倍程度の値とすればよい。

ステップ７０３では、アクセス解析モジュール４０２が、アクセス状況の解析結果に基づき、インライン方式を適用する場合のリソースの条件を決定する。ここでは、データサイズを条件とする場合について説明する。この場合、アクセス状況の解析結果に応じたデータサイズの閾値が決定される。例えば、アクセス状況が「多」であった場合は600KB、「中」であった場合は250KB、「少」であった場合は30KBといった具合である。データサイズの閾値が大きくなるほどインライン方式のファイル構成となるリソースが増え、その結果、SVG文書の総ファイル数が減ることになる。

ステップ７０４では、ファイル化モジュール４０３が、元データに含まれるヘッダ情報等を解析し、元データ内のすべてのリソースを取得する。

ステップ７０５では、ファイル化モジュール４０３が、注目するページを決定する。通常は、1ページ目が最初の注目ページに決定される。

ステップ７０６では、ファイル化モジュール４０３が、注目ページについてのリソースの中から注目するリソースを決定する。

ステップ７０７では、ファイル化モジュール４０３が、注目リソースがステップ７０３で決定した条件を満たすか否かを判定する。ここでは、注目リソースのデータサイズと、アクセス状況に応じて決定された閾値とが比較される。判定の結果、注目リソースのデータサイズが閾値以下であれば、ステップ７０８に進む。一方、注目リソースのデータサイズが閾値を越える場合は、ステップ７０９に進む。

ステップ７０８では、ファイル化モジュール４０３が、注目リソースに対しインライン方式を適用してファイル化する。すなわち、注目リソースをSVGファイル内に埋め込む。

ステップ７０９では、ファイル化モジュール４０３が、注目リソースに対し外部参照方式を適用してファイル化する。すなわち、注目リソースをSVGファイルとは別の外部ファイルとして構成する。

ステップ７１０では、注目ページについての全リソースについて処理が完了したか否かが判定される。未処理のリソースがあればステップ７０６に戻って次の注目リソースを決定して処理を続行する。一方、注目ページについての全リソースについて処理が完了していれば、ステップ７１１に進む。

ステップ７１１では、元データの全ページについて処理が完了したか否かが判定される。未処理のページがあればステップ７０５に戻って次の注目ページを決定して処理を続行する。一方、元データの全ページについて処理が完了していれば、ステップ７１２に進む。

ステップ７１２では、ファイル保存モジュール４０４が、出来上がったSVG文書をデータストレージ３１３に格納する。図８は、本実施例に係る、同一の元データから生成される3種類のSVG文書のファイル構成を説明する図である。図８（ａ）は、SVG文書生成前の元データの構成を示す図である。図８（ａ）の元データは2ページで構成され、1ページ目は500KBと100KBの画像情報（jpg1及びjpg2）と50KBのフォント情報（ttf1）の計3つのリソースが含まれている。また、2ページ目には300KBと100KBの画像情報（png1及びpng2）と200KBのフォント情報（ttf2）の3つのリソースが含まれている。このような元データからアクセス状況の解析結果に応じて、図８（ｂ）〜（ｄ）に示す3種類のSVG文書が生成される。図８（ｂ）は、アクセス状況「少」の下でデータサイズ閾値「30KB」の場合に生成されるSVG文書であり、30KB以下のリソースがインライン方式でファイル化される。図８（ａ）の元データには30KB以下のデータは存在しないため、全てのリソースが外部参照方式でファイル化されている。図８（ｃ）は、アクセス状況「中」の下でデータサイズ閾値「250KB」の場合に生成されるSVG文書であり、250KB以下のリソースがインライン方式でファイル化される。この場合は、1ページ目のjpg1の画像情報と2ページ目のpng1の画像情報のみ外部参照方式でファイル化され、その他のリソースはインライン方式でファイル化されている。図８（ｄ）は、アクセス状況「多」の下でデータサイズ閾値「600KB」の場合に生成されるSVG文書であり、600KB以下のリソースがインライン方式でファイル化される。いま、元データの全てのリソースが600KB以下のサイズであるため、全てのリソースがインライン方式でファイル化されることになる。ここで、図８（ｂ）〜（ｄ）のファイル数を比べてみると、それぞれ9個、5個、3個である。すなわち、データストレージ３１３へのアクセスが少ない状況ではファイル数は多くても構わないため、外部参照方式が適用されやすくなっている。一方、アクセスが多い状況ではファイル数を少なくしてアクセスされるファイル数が増えないように、インライン方式が適用されやすくなっている。

以上が、本実施例におけるファイル化処理の内容である。

＜変形例＞
上述の例では、同一内容のリソースが複数存在した場合に、それぞれが別個独立に扱われる結果、別々の外部ファイルとして構成され得た。そこで、同一内容のリソースが複数存在する場合に、リソースの共有を行ってより効率的なファイル構成を実現する態様を変形例として説明する。

本変形例では、上述のステップ７０４で元データ内のすべてのリソースを取得した段階で同一内容のリソースの有無を判定し、同一内容のリソースがあれば、共有リソースとして1個のリソースに整理・統合する。ステップ７０５以降の処理は、上述の通りであるので説明を省く。

図９は、本変形例によって生成される、SVG文書のファイル構成を説明する図である。図９（ａ）は、SVG文書生成前の元データの構成を示す図である。図９（ａ）の元データは2ページで構成され、1ページ目は500KBと100KBの画像情報（jpg1及びjpg2）と50KBのフォント情報（ttf1）の計3つのリソースが含まれている。2ページ目は1ページ目と同じ500KBの画像情報（jpg1）と100KBの画像情報（png1）と200KBのフォント情報（ttf2）の3つのリソースが含まれている。このように、1ページ目のjpg1の画像情報と2ページ目のjpg1の画像情報とが同一内容のリソースである。この元データから生成されるSVG文書の一例が図９の（ｂ）と（ｃ）に示されている。なお、インライン方式を適用するリソースのデータサイズの閾値はいずれも250KBであるものとする。

そして、図９（ｂ）が上述の実施例によって生成されるSVG文書のファイル構成であり、図９（ｃ）が本変形例によって生成されるSVG文書のファイル構成を示している。図９（ｂ）では各ページのSVGファイルから参照されているjpg1が別々の外部ファイルであるのに対し、図９（ｃ）では1つのjpg1の外部ファイルが共有参照されていることがわかる。その結果、図９（ｃ）のSVG文書ではファイル数が4個になり、ファイル数を削減することができている。ここでは説明の便宜上、最も単純な例を説明したためファイル数の削減効果が大きくないが、同一内容のリソースが3個以上あったり、複数種類、複数ページで存在する場合は効果が大きくなる。また、ここでは共有リソースが外部参照方式による別ファイルとなる場合について説明したが、インライン方式の場合であっても同一ページ内であれば共有は可能である。この場合、ファイル数に変更はないためファイル数の抑制には寄与しないがファイルサイズが小さくなるため、システム上の処理負荷が軽減される。

なお、本実施例では、アクセス状況を判定する際の基準に未表示のジョブ数（或いはファイル数）といったアクセス履歴を用いたが、これに限定されない。例えば、クラウドサーバ１０２上で起動しているファイル生成サービス３１２の数を指標としてもよい。あるいは、データストレージ３１３への単位時間あたりのアクセス数を指標としても構わない。すなわち、データストレージ３１３にどれだけのアクセスが同時に発生し得るかを判断できるものであればどのような指標でもよい。

また、インライン方式を適用する場合の条件としてリソースのデータサイズを用いたが、例えばリソース数を条件とし、一定のリソース数以下であればSVGファイル内に記述するようにしてもよい。この手法によっても、SVG文書のファイル数を抑制することができる。

以上のとおり本実施例によれば、インライン方式を適用する際のリソースの条件がデータストレージへのアクセス状況に応じて決定される。これにより、クラウドシステム上で生成する文書ファイルの構成を動的に変更することができ、ファイル数の抑制と表示パフォーマンスの維持というトレードオフの関係にある両者のバランスを最適に保つことが可能になる。

実施例１において、図８（ｂ）のようなファイル構成は、保存されている文書ファイルに対する同時多数のアクセスが見込まれない場合に生成されるため、データストレージ３１３のアクセス制限が発生する可能性は低い。しかしながら、元データのページ数やリソース数によっては想定以上のファイル数でSVG文書が構成されてしまう可能性がある。そこで、保存されている文書ファイルに対する同時多数のアクセスが見込まれない場合において、先頭ページのみを外部参照方式でファイル化する態様について、実施例２として説明する。なお、実施例１と共通する部分は説明を省略ないしは簡略化し、本実施例では差異点を中心に説明するものとする。

図１０は、本実施例に係る、ファイル化処理の流れを示すフローチャートである。ステップ１００１〜ステップ１００５は、実施例１に係る図７のフローのステップ７０１〜７０５と同じである。ステップ１００５で注目ページが決定されると、ステップ１００６において、ファイル化モジュール４０３が、当該注目ページが先頭ページであるかどうかを判定する。注目ページが先頭ページであれば、ステップ１００７に進む。一方、注目ページが先頭ページ以外のページであれば、ステップ１００８に進む。ステップ１００７では、ステップ１００２での判定の結果、多くのファイルアクセスが見込まれない状況であるかどうか（ここでは、アクセス状況が「少」であったかどうか）によって処理が切り分けられる。アクセス状況が「少」であった場合はステップ１０１３に進み、「少」でなかった場合はステップ１００８に進む。

ステップ１００８〜ステップ１０１２は、図７のフローのステップ７０６〜ステップ７１０にそれぞれ相当する。すなわち、注目ページについて注目リソース毎にステップ１００３で決定した条件を満たすかどうかが判定され、判定結果に応じてインライン方式又は外部参照方式による注目リソースのファイル化処理がなされる。

ステップ１０１３では、ファイル化モジュール４０３が、先頭ページ内のすべてのリソースについて、外部参照方式によるファイル化処理を行う。先頭ページについてのファイル化処理が完了すると、ステップ１０１４に進む。

ステップ１０１４及びステップ１０１５は、図７フローのステップ７１１及びステップ７１２に相当する。すなわち、元データの全ページについて処理が完了するまでステップ１００５以下の処理が繰り返され、出来上がったSVG文書がデータストレージ３１３に格納される。

図１１は、本実施例によって生成される、SVG文書のファイル構成を説明する図である。図１１（ａ）は、SVG文書生成前の元データの構成を示す図である。図１１（ａ）の元データは2ページで構成され、1ページ目は500KBと100KBの画像情報（jpg1及びjpg2）と50KBのフォント情報（ttf1）の計3つのリソースが含まれている。2ページ目は300KBと100KBの画像情報（png1及びpng2）と200KBのフォント情報（ttf2）の3つのリソースが含まれている。この元データから生成されるSVG文書の一例が図１１の（ｂ）と（ｃ）に示されている。なお、インライン方式を適用するリソースのデータサイズの閾値はいずれも30KBであるものとする。

そして、図１１（ｂ）が実施例１によって生成されるSVG文書のファイル構成であり、図１１（ｃ）が本実施例によって生成されるSVG文書のファイル構成を示している。図１１（ｂ）では1ページ目と2ページ目ともにすべてのリソースが外部参照方式でファイル化されている。これに対し、図１１（ｃ）では先頭ページのみリソースが外部参照方式でファイル化され、2ページ目はインライン方式でSVGファイル内に記述されている。また、図１１（ｂ）と（ｃ）とでファイル数を比較してみると、それぞれ9個と6個であり、本実施例を適用した方がよりファイル数を削減することができている。そして、先頭ページ内のリソース数が多いほどその効果は大きくなる。

本実施例によれば、アクセス状況が多くないと判定された場合に先頭ページのみを外部参照方式でファイル化し、先頭ページ以外のページについてはインライン方式でファイル化する。このような制御を行うことで、先頭ページについては表示パフォーマンスの良好なファイル構成となり、迅速に表示させることができる。こうすることで、ユーザが先頭ページを閲覧している間に2ページ目以降の描画データの読み込みができるため、ユーザの感じるストレスが軽減される。また、トータルのファイル数が減るため、ファイルアクセス負荷をさらに抑制することができる。

次に、元データの各ページに含まれる画像リソースについて、スプライト画像を作成する態様について実施例３として説明する。ここで、スプライト画像とは、複数の画像を連結して1つにまとめた画像である。このスプライト画像に対しCSSで表示範囲を指定することによって個々の画像を表示する手法が「CSSスプライト」であり、本実施例はこれを利用するものである。なお、実施例１と共通する部分は説明を省略ないしは簡略化し、本実施例では差異点を中心に説明するものとする。

図１２は、本実施例に係る、ファイル化処理の流れを示すフローチャートである。ステップ１２０１〜ステップ１２０４は、実施例１に係る図７のフローのステップ７０１〜７０４と同じである。ステップ１２０４で元データからすべてのリソースが取得されると、ステップ１２０５において、ファイル化モジュール４０３が、取得されたリソース内に同一種類の画像情報が複数あるかどうかを判定する。この場合において、同一種類とは画像形式が同じであることを意味し、例えばjpgとpngとは異なる画像形式であるため同一種類ではない。同一種類の画像情報が複数あれば、ステップ１２０６に進む。一方、同一種類の画像情報が複数なければ、ステップ１２０７に進む。

ステップ１２０６では、ステップ１２０４で取得したリソースのうち複数の画像情報に関し、上述のスプライト画像を作成する。作成されたスプライト画像のデータは、以降のステップにおいて1つのリソースとして扱われる。

ステップ１２０７及びステップ１２０８は、図７のフローのステップ７０５及び７０６に相当し、注目ページと注目リソースがそれぞれ決定される。そして、ステップ１２０９では、注目リソースが上述のスプライト画像であるかどうかによって処理が切り分けられる。注目リソースがスプライト画像でなければステップ１２１０に進み、スプライト画像であればステップ１２１２に進む。

ステップ１２１０〜ステップ１２１５は、図７のフローのステップ７０７〜ステップ７１０にそれぞれ相当する。すなわち、注目ページについて注目リソース毎にステップ１２０３で決定した条件を満たすかどうかが判定され、判定結果に応じてインライン方式又は外部参照方式による注目リソースのファイル化処理がなされる。この場合において、スプライト画像については外部参照方式が適用され、外部ファイルとして構成されることになる。そして、元データの全ページについて処理が完了するまで処理が続行され、出来上がったSVG文書がデータストレージ３１３に格納される。

図１３は、本実施例によって生成される、SVG文書のファイル構成を説明する図である。図１３（ａ）は、SVG文書生成前の元データの構成を示す図である。図１３（ａ）の元データは2ページで構成され、1ページ目は500KBと100KBの画像情報（jpg1及びjpg2）と50KBのフォント情報（ttf1）の計3つのリソースが含まれている。2ページ目は300KBと100KBの画像情報（jpg3及びjpg4）と200KBのフォント情報（ttf2）の3つのリソースが含まれている。つまり、1ページ目と2ページ目を合わせて同一種類の画像情報が4個存在している。そして、図１３（ｂ）がこの元データから実施例１によって生成されるSVG文書のファイル構成であり、図１３（ｃ）が本実施例によって生成されるSVG文書のファイル構成を示している。図１３（ｂ）では各画像情報が別々の外部ファイルとして構成されているのに対し、図１３（ｃ）では4つの画像情報を結合した1個のスプライト画像ファイルが共有参照されている。そして、図１３（ｂ）と（ｃ）とでファイル数を比較してみると、それぞれ7個と4個であり、ファイル数を大きく削減することができている。

本実施例によれば、元データ内に同一種類の画像リソースが含まれる場合に1個のスプライト画像にまとめられるので、同一種類の画像リソースが多いほどファイル数削減の効果が大きい。したがって、元データの構成によっては、トータルのファイル数をより大きく減らせることができ、ファイルアクセス負荷をさらに抑制することができる。

以上、3つの実施形態に分けて説明を行ったが、各実施例はそれぞれが独立しているものではなく、各実施例の内容を組み合わせることも可能である。例えば、実施例１の変形例と実施例２とを組み合わせて、リソースの共有を行うとともに先頭ページのみインライン方式を適用するといったことも可能である。

また上述の各実施例では、SVG形式の文書ファイルを生成する場合を例に説明を行ったが、これに限定されない。さらに、SVGと同様にXMLをベースとしたJDF(Job Definition Format)など、SVG類似の構造を持つフォーマットの文書ファイルの生成に幅広く適用可能である。

（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

Claims

文書ファイルの生成サービスを提供するサーバ装置であって、
文書ファイルの元になる元データをクライアント装置から受け取る通信手段と、
前記元データに含まれる複数のリソースに基づいて文書ファイルを生成するファイル化手段と、
生成された文書ファイルをストレージに保存する保存手段と、
を備え、
前記ファイル化手段は、前記ストレージへのアクセス状況に応じて、前記元データに含まれる複数のリソースそれぞれに対してインライン方式又は外部参照方式のいずれを適用するか判定し、当該判定の結果に基づいて前記文書ファイルを生成する、
ことを特徴とするサーバ装置。
前記アクセス状況を、所定の指標に基づいて判定する解析手段をさらに備えたことを特徴とする請求項１に記載のサーバ装置。
前記所定の指標は、前記ストレージに保存されている複数の文書ファイルへのアクセス履歴であることを特徴とする請求項２に記載のサーバ装置。
前記アクセス履歴は、前記ストレージに保存されている複数の文書ファイルのうち、前記クライアント装置から未だアクセスがなされていない文書ファイルについての、前記クライアント装置からのファイル化の要求に対応するジョブの数であることを特徴とする請求項３に記載のサーバ装置。
前記アクセス履歴は、前記ストレージに保存された複数の文書ファイルのうち、前記クライアント装置から未だアクセスがなされていない文書ファイルを構成するファイルの数であることを特徴とする請求項３に記載のサーバ装置。
前記通信手段、前記ファイル化手段及び前記保存手段は、前記クライアント装置からの要求の数に応じて起動数が変動するソフトウェアによって実現され、
前記所定の指標は、前記サーバ装置において起動している前記ソフトウェアの数である
ことを特徴とする請求項３に記載のサーバ装置。
前記所定の指標は、前記ストレージへの単位時間あたりのアクセス数であることを特徴とする請求項３に記載のサーバ装置。
前記ファイル化手段は、前記アクセス状況に応じて、前記元データに含まれる複数のリソースそれぞれに対して、インライン方式又は外部参照方式のいずれを適用するか判定し、各リソースに当該判定結果の方式を適用してファイル化することで、前記生成する文書ファイルの構成を変更することを特徴とする請求項１に記載のサーバ装置。
前記ファイル化手段は、前記アクセス状況に応じて、前記インライン方式を適用する際の条件を決定し、
前記ファイル化手段は、前記元データに含まれるリソースが前記条件を満たす場合には前記インライン方式を適用して当該リソースをファイル化し、前記元データに含まれるリソースが前記条件を満たさない場合には前記外部参照方式を適用して当該リソースをファイル化する
ことを特徴とする請求項８に記載のサーバ装置。
前記条件は、前記リソースのデータサイズが閾値以下であることを特徴とする請求項９に記載のサーバ装置。
前記条件は、前記リソースの数が閾値以下であることを特徴とする請求項９に記載のサーバ装置。
前記ファイル化手段は、前記元データの複数のページに同一内容のリソースが存在する場合、当該リソースが当該複数のページで共有されるようにファイル化することを特徴とする請求項１に記載のサーバ装置。
前記ファイル化手段は、保存されている文書ファイルに対する同時アクセスが一定数以上見込まれない場合に、先頭ページのみを外部参照方式でファイル化することを特徴とする請求項１に記載のサーバ装置。
前記リソースは、画像情報、フォント情報、スタイル情報であることを特徴とすることを特徴とする請求項１に記載のサーバ装置。
前記ファイル化手段は、前記元データに、同一種類の画像情報が複数存在した場合、結合して１つの画像情報としてファイル化することを特徴とする請求項１４に記載のサーバ装置。
前記サーバ装置は、クラウドコンピューティングシステムにおける仮想サーバであることを特徴とする請求項１に記載のサーバ装置。
前記ストレージは、クラウドコンピューティングシステムにおけるストレージであることを特徴とする請求項１に記載のサーバ装置。
文書ファイルの生成サービスを提供する方法であって、
文書ファイルの元になる元データをクライアント装置から受け取るステップと、
前記受け取るステップにて受け取った前記元データに含まれる複数のリソースに基づいて文書ファイルを生成するステップと、
前記生成するステップにて生成された文書ファイルをストレージに保存するステップと、
を含み、
前記生成するステップでは、前記ストレージへのアクセス状況に応じて、前記元データに含まれる複数のリソースそれぞれに対してインライン方式又は外部参照方式のいずれを適用するか判定し、当該判定の結果に基づいて前記文書ファイルを生成する、
ことを特徴とする方法。
コンピュータを、請求項１乃至１７のいずれか１項に記載のサーバ装置として機能させるためのプログラム。