(57)【要約】【課題】コマンドの解釈とコンテンツ等の情報の出力制御を並行して実行することを可能とし、出力制御装置側の処理負担を軽減する。【解決手段】ページやコンテンツ全体を単位として一括して属性値の管理を行うのではなく、コマンドライン間における属性値の継承管理を行ってコマンドライン毎に属性値を管理し、コマンドの解釈と情報の出力制御を並行して実行することを可能とする。【選択図】  図１７
2005004281.tif 000002
【特許請求の範囲】
【請求項１】
情報を入力する入力手段と、
前記入力手段より入力した前記情報内のコマンドライン間における属性値の継承管理を行う管理手段と、
前記情報に含まれるコマンドライン及び前記管理手段による管理内容を解釈する解釈手段と、
前記解釈手段による解釈結果に基づいて、出力手段に対して前記情報の出力制御を行う出力制御手段とを有することを特徴とする出力制御装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、デジタルデータ放送や、インターネットを始めとするデータ通信において配信されるコンテンツを印字する技術に関するものである。
【０００２】
【従来の技術】
従来、ＸＨＴＭＬなどのマークアップ言語で記述したコンテンツの解釈実行および印字処理は、大規模な資源を駆使できるコンピュータ等で行なわれていた。このケースでは、まず、コンテンツ単位で継承マップを先行して一括構築し、しかる後に、印字データを作成する方式が採られていた。
【０００３】
また、デジタルデータ放送を受信し、テレビ画面に放送の表示を行う画像情報処理装置において、データ放送画面を構成するＢＭＬファイルを解析し、印刷機能を備える技術が存在している（例えば、特許文献１参照）。
【０００４】
【特許文献１】
特開２００３−０３７８１２号公報
【０００５】
【発明が解決しようとする課題】
デジタルテレビ、携帯電話やデジタルカメラ等も、マークアップ言語で記述したコンテンツを取り扱うことが多くなってきている。ところが、このような機器では資源が限られているため、例えば、コンテンツを印字データに変換するに当たり、コンテンツ全体の印字データを保持することが困難である。
【０００６】
本発明は、上記問題点に鑑みてなされたものであり、コマンドの解釈とコンテンツ等の情報の出力制御を並行して実行することを可能とし、出力制御装置側の処理負担を軽減することを目的とする。
【０００７】
【課題を解決するための手段】
斯かる目的を達成するために、本発明の出力制御装置は、情報を入力する入力手段と、前記入力手段より入力した前記情報内のコマンドライン間における属性値の継承管理を行う管理手段と、前記情報に含まれるコマンドライン及び前記管理手段による管理内容を解釈する解釈手段と、前記解釈手段による解釈結果に基づいて、出力手段に対して前記情報の出力制御を行う出力制御手段とを有することを特徴としている。
【０００８】
【発明の実施の形態】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
図１は、本発明の一実施形態に係る印字システムの構成を概略的に示したブロック図である。まず、本実施形態に係る印字システムは、チューナ（ＳＴＢ）１０、メモリカード１２、表示装置１１、及び、プリンタコントローラ（ＳＣＢ）２１とプリンタエンジン２２を含むプリンタ２０によって構成される。
【０００９】
さらに、チューナ１０は、ＢＭＬ／Ｐ（印字用のＢｒｏａｄｃａｓｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）で表現されるコンテンツを、ＩＥＥＥ１３９４  Ｉｎｔｅｒｆａｃｅ上で動作する、ＤＰＰ（Ｄｉｒｅｃｔ  Ｐｒｉｎｔ  Ｐｒｏｔｏｃｏｌ）およびＤＰＣ（Ｄｉｒｅｃｔ  Ｐｒｉｎｔ  Ｃｏｍｍａｎｄ  Ｓｅｔ）によって、プリンタコントローラ２１に転送する。プリンタコントローラ２１は、パッケージ化してあるＢＭＬ／Ｐコンテンツを、複数のファイルに分離し、Ｐａｒｓｅｒ（ここでは、字句解析・構文解析・意味解析を含む）の働きにより、印字可能ファイルに変換する。さらに、印字コマンド列に変換し、プリンタエンジン２２に出力する。
【００１０】
ここで、前述のように、ＢＭＬ／Ｐコンテンツを、予めチューナにて画像とレイアウト表現部をマルチパート化してからプリンタコントローラ２１に転送しても良いが、レイアウト表現部のみをプリンタコントローラ２１に送り、プリンタコントローラ２１がレイアウト表現部で参照しているファイルをチューナ１０に要求して、取得することもできる。
【００１１】
図２は、本実施形態において適用するＩＥＥＥ１３９４  Ｉｎｔｅｒｆａｃｅプロトコル・スタックを説明するための図である。
ＩＥＥＥ１３９４のリンク層のからアシンクロナス転送モードを用い、トランザクション、セッッション層の上にＤＰＰ（ｄｉｒｅｃｔ  ｐｒｉｎｔ  ｐｒｏｔｏｃｏｌ）／ＤＰＣ（ｄｉｒｅｃｔ  ｐｒｉｎｔ  ｃｏｍｍａｎｄ）を搭載したものである。
【００１２】
図３は、本実施形態におけるＤＰＰ／ＤＰＣパケット  Ｐａｃｋｅｔを用いた“Ｓｅｎｄ”データ構造を模式的に示した図である。また、図４は、本実施形態におけるＤＰＰ／ＤＰＣパケットのヘッダー各要素に対する意味付けを示した図である。
本実施形態ではｓｅｎｄ  ｄａｔａ＝“ｉｍａｇｅ”として利用する。図３中の“Ｐａｄｄｉｎｇ”とは、マルチパート化したコンテンツのバイト総数が４の倍数バイトでない場合に００ｈで埋めることである。
【００１３】
図５は、本実施形態におけるチューナ（ＳＴＢ）内部でのデータ処理フローを示した図である。
ここで、コンテンツデータはＭＰＥＧ−２方式により他のメディアと共に多重化され、さらに単一搬送波でＰＳＫデジタル変調後、アンテナから送信される。“Ｂｌｏｃｋ−０１”では、受信した電波ＲＦをチューナで選局・復調し、多重化ストリームであるＭＰＥＧ−２  ＴＳ  ｐａｃｋｅｔを得る。
【００１４】
続く“Ｂｌｏｃｋ−０２”では、多重化ストリームからＰＩＤフィルタリング処理／ＰＳＩ分析処理に基づき、データ放送コンテンツを他のメディアから分離する。“Ｂｌｏｃｋ−０３”では、前分離されたデータ放送コンテンツだけを含むＴＳパケットをＤＳＭ−ＣＣ方式で定義される１周期分のデータ列としてカルーセルバッファにて一時保存する。“Ｂｌｏｃｋ−０４”では、カルーセルバッファで一時保存したデータ列（複数のＤＩＩ＋ＤＤＢ）から、複数のフアイルを得て、チューナ内のフラッシュメモリ等の記憶装置に蓄える。すなわち、送出側が、一体（マルチパート）化した「モジュール」を再び、▲１▼静止画ｊｐｅｇ▲２▼図形ｐｎｇ▲３▼文字ｔｅｘｔ▲４▼制御コードｔｅｘｔを分離する。ＢＭＬブラウザソフトウェアは前記フアイルを順次読み出し、画面表示やリモコンとのデータの受け渡しおよび、印字の起動を行う。
【００１５】
図６は、本実施形態に係るデジタルテレビチューナ（ＳＴＢ）のシステム構成を模式的に示した図である。
ハードウェアはＣＰＵを始めとしたメモリ、チューナ・フロントエンド処理およびＩｎｔｅｒｆａｃｅ制御用デバイス群からなる。ＳＴＢシステム  ＬＳＩ  ｂａｓｅ  ｈａｒｄｗａｒｅはシステム全体の制御用ロジックを集積したＬＳＩチップセットある。オペレーティングシステムはデバイスドライバ、カーネル、ライブラリから構成されるソフト群である。デバイスドライバはインタフェースのリンク層・下位プロトコルを制御する。カーネルはタスクの制御、タスク間通信、資源の管理を行う。ライブラリはファイルシステムやインタフェースの上位プロトコルを制御するモジュールの集合である。ミドルウエアはデジタルテレビチューナに必須のアプリケーションで、ブラウザ（表示プログラム）など常駐ソフト群から成る。
【００１６】
図７は、本実施形態におけるプリント専用ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を説明するための図である。
アプリケーションはＡＰＩで定義された「手続き」を用いて、ミドルウエア層と共同して、各機種依存の制御を担当する。たとえば、ＢＭＬ／ＰコンテンツとのＡＰＩとして図６に示すようにＤＯＭ（ｄｏｃｕｍｅｎｔ  ｏｂｊｅｃｔ  ｍｏｄｅｌ）を利用する。
【００１７】
図８は、デジタルテレビ放送のチューナ内部におけるＢＭＬ／Ｐコンテンツのファイル構成を示した図である。
なお、ここでは、「モジュール」を複数の独立したフアイルを含む「フォルダ」に近い意味で用いている。以下にＢＭＬ／Ｐコンテンツのファイル構成を説明する。
【００１８】
まず、放送される一つの番組を“イベント”と呼ぶ。イベント（ここでは、“ＡｆｔｅｒｎｏｏｎＴｅａ”）は複数のモジュールから構成される。モジュール名は“１６進文字列４桁”で表現される。特別の番号“０ｘ００００”で区別されるモジュールは、番組群のうち最初に起動され、通常は全体のメインメニュー（複数のフアイルを含む）を収容する。
【００１９】
次に、モジュール番号“０ｘ００００”の中には“ｓｔａｒｔｕｐ．ｂｍｌ”と言う名前のフアイルが必ず存在する。表示ブラウザ（ソフト）はこのフアイルを最初に処理する。ところで、イベント全体に対する最大サイズの規定はないが、１モジュールの最大は約１ＭＢである。また、１イベントあたりの最大モジュール数は２５６個である。チューナに実装するＲＡＭのサイズは最小２ＭＢと規定されているので、放送するコンテンツのサイズもそれ以下である必要がある。
【００２０】
図９は、図８のモジュール群から印字用モジュール（ここでは、９９９９番）だけを書き出した図である。
このモジュールは、１個の「プリント用レイアウト情報」（ここでは、ｐｒｉｎｔ．ｂｍｌ）と複数の付属する「画像ファイル」から成る。なお、印字用モジュールは全体で約３００ＫＢを最大の目安としている。また、このモジュール中にはｘｘｘｘ．ｂｍｌが一個のみ存在することになっている。
【００２１】
図１０は、マルチパート化したファイルの一構成例を示した図である。以下に、前記複数のファイルからなるモジュールが１つにまとめられた（マルチパート化した）状態について説明する。
マルチパート化は電子メールなどでもよく利用される技術で、ＲＦＣ１５２１（ＭＩＭＥ）で規定されている。本実施形態における主な構成要素とその配列を説明する。まず、それぞれのファイルを区切るための文字（ｂｏｕｎｄａｒｙ）を定義する。次にモジュール全体のサイズが示される。さらに“Ｂｏｕｎｄａｒｙ”に続き、リソースリスト“ｒｅｓｏｕｒｃｅＬｉｓｔ”という情報が付加される。“ｒｅｓｏｕｃｅＬｉｓｔ”にはモジュールに含まれる全てのファイルの情報（メディアの型、ファイルの長さ、符号化方式、ファイルの名前等）が含まれる。さらに、“ｂｏｕｎｄａｒｙ”、ファイルの長さ、ファイルの名前など、さらに実ファイルデータの繰り返しとなる。
【００２２】
図１１は、デジタルテレビによるプリント実行処理を簡略化して示した図である。以下に、プリント実行のシーケンスを説明する。
プリンタの電源ｏｎで待機状態となったとき“ｏｎｌｉｎｅ”がチューナに対して通知される。続いて、アプリケーションは、ＢＭＬ／Ｐのマルチパート化したコンテンツを準備する。
【００２３】
次に、チューナは、前記コンテンツを１３９４  ｉ／ｆ  Ｂｏａｒｄに予め定めるデータ・パケット形式で出力する。もし印刷実行中に不具合があった場合には、プリンタはチューナに対してエラーを通知する。通知を受けたチューナはその内容に対応するメッセージを表示する。エラーが復旧したとき、プリンタからチューナに対して“ｏｎｌｉｎｅ”が通知される。
【００２４】
図１２は、デジタルデータ放送における著作権保護に関する一実施形態を説明するための図である。
まず、デジタルデータ放送によって配信されるコンテンツのうち、著作権および技術上の観点から「印字も可能」としてユーザに通知されたものであれば、ユーザの操作指示により、該データが印字装置に出力可能である。
【００２５】
次に、著作権保護に関する第１の実施形態について説明する。
放送されたコンテンツは、一旦そのチューナ固有のファイルフォーマットに基づき、内部に一時記憶される。この記憶領域はチューナ内部に固定される媒体にのみマップされていて、ユーザが取り外しできない構造になっている。チューナはこのデータに基づき表示・画面制御用データを作成する。
【００２６】
一方、ユーザが印字を指示したコンテンツは、著作権取り扱い判定・課金処理（セキュリティ  シールド）で予め定める手段にて予めダウンロードされていた判定情報（ＳＲＭ：  Ｓｙｓｔｅｍ  Ｒｅｎｅｗ−ａｂｉｌｉｔｙ  Ｍｅｓｓａｇｅｓ）に基づき、選別・加工されバッファに転送される。
【００２７】
ここで「加工」とは、画像データの解像度変換や不正・偽造防止用ウォーターマークの付加などを含む。印字用コンテンツは最終的にバッファに蓄えられる。このバッファ領域はチューナ内部に固定される媒体、或いは、ユーザが取り外しできるメモリカードにマップされる。なお、前記シールドを通過したファイル名は履歴として保存し、課金情報として利用する。前記バッファの内容は削除・重ね書きができる。一般にプリンタにファイル出力した時点でバッファの内容は削除される。
【００２８】
次に、著作権保護に関する第２の実施形態である、セッションによる方法について説明する。
印刷命令が実行された後、チューナ側からプリンタに対してセッションを張る。セッションが張られた後は、プリンタ側からのファイル要求に応じて、チューナはファイルを転送する。全てのファイル転送が終了したら、プリンタ側から速やかにセッションを切断する。このように、セッションを張らないクライアントからのファイル要求は行えない。
【００２９】
さらに、著作権保護に関する第３の実施形態である、名前空間による方法について説明する。
“印刷用ＡＰＩで指定された名前空間以下のファイルへのアクセスのみ許す”というような名前空間による制限も課す。例えば、ｐｒｉｎｔ（“￣／０００３／ｎｅｗ．ｂｍｌ”）という命令を実行した場合、０００３モジュールのファイルにしかアクセスを許さない。
【００３０】
また、ｐｒｉｎｔ（“ａｒｉｂ−ｆｉｌｅ：／／ｍｙｄｉｒｅｃｔｏｒｙ／ｍｙｓｕｂｄｉｒｅｃｔｏｒｙ／ｒｅｃｉｐｉｅ．ｂｍｌ”）という命令の場合は“ａｒｉｂ−ｆｉｌｅ：／／ｍｙｄｉｒｅｃｔｏｒｙ／ｍｙｓｕｂｄｉｒｅｃｔｏｒｙ／”以下に格納されているファイルにしかアクセスできない。
【００３１】
図１３は、本実施形態で用いた、印字レイアウト用マークアップ言語ＢＭＬ／ＰとＢＭＬとの関係を説明する図である。まず、ＢＭＬ／ＰとＢＭＬとの違いを説明する。
ＢＭＬ／ＰはＢＭＬマルチメディア符号化方式に基づき、デジタルテレビチューナが出力する、印字コンテンツのレイアウトを表現する。すなわち、ＢＭＬ１．０  における＜ｅｌｅｍｅｎｔ・ｐｒｏｐｅｒｔｙ・ｖａｌｕｅ＞およびＣＳＳ２．０におけるｓｅｌｅｃｔｏｒ  ［ｐｒｏｐｅｒｔｙ・ｖａｌｕｅ］のうちから、簡易な構成の出力デバイスでも処理可能なものを抽出している。ＢＭＬ／Ｐでは、ｏｌ／ｕｌ／ｌｉや簡易はテーブル要素をＢＭＬ拡張機能として搭載している。逆に、ＢＭＬで使えたスクリプトやイベントハンドラ、あるいはＤＯＭインタフェースは使えない。本実施形態では、チューナおよびＢＭＬ／Ｐパーサ搭載のプリンタコントローラとプリンタエンジンの構成となっている。
【００３２】
次に、ＸＭＬ系コンテンツを印字に応用する場合に想定される制限事項について説明する。
ＸＭＬ系コンテンツは、表示系の表現形式として発展・普及してきたが、最近印字にも応用しようとの動きがある。特にプリンタドライバを用いない、非ＰＣプリンタ系にとってソリューションの候補となる。だだし、表示系と印字系の間の溝を、いかにして埋めるかが課題であった。たとえば、表示系ではスクロールという概念はあるがページの区切りはなない。一方印字系ではその逆でスクロールという概念はなく、ページのボックスの概念を適用する必要がある。
【００３３】
なお、印字用コンテンツはＳＴＢ内部のアプリケーションソフトウエアの働きにより表示コンテンツに変換すれば表示可能である。逆に表示用コンテンツを印字用に加工もできる。一般に、表示用の画像は印字に必要な解像度を持たないため印字結果には制限が生じる。
【００３４】
さらに、本実施形態では、表現可能なコンテンツ・オブジェクトは「テキストと画像」の各要素の組み合わせを用いている。ＢＭＬは表示レイアウトの保持、とりわけオブジェクトの絶対位置の再現性が保たれると言う特徴を有する。ＢＭＬ／Ｐもその特性に準拠している。本実施形態では、最終的な媒体上のサイズはＡ４またはＡ３の縦または、横としている。
【００３５】
図１４は、本実施形態で用いた、印字範囲の指定について説明するための図である。以下は、ＢＭＬ／Ｐにおける、メディアの大きさや形、メディア上での位置指定について説明している。
ＢＭＬではブロック要素を画面上で配置する場合、左上を原点とし、ピクセル単位で与えたグリッド上でのＸＹ座標（ｌｅｆｔ・ｔｏｐ）、縦（ｈｅｉｇｈｔ）、横幅（ｗｉｄｔｈ）の絶対位置で指定する。
【００３６】
一方、ＢＭＬ／Ｐでは、左上端を原点とするＸＹ座標（ｌｅｆｔ・ｔｏｐ）、縦（ｈｅｉｇｈｔ）、横幅（ｗｉｄｔｈ）の絶対位置はｍｍを単位とし指定する。例えば、印字方向（オリエンテーション）及びメディアサイズは以下のように指定する。
出力メディアＡ４縦置きの場合は・・・＠ｐａｇｅ［ｓｉｚｅ：  ２１０．１ｍｍ  ２９７．１ｍｍ；  ｐｏｒｔｒａｉｔ］
出力メディアＡ４横置きの場合は・・・＠ｐａｇｅ［ｓｉｚｅ：  ２９７．１ｍｍ  ２１０．１ｍｍ；  ｌａｎｄｓｃａｐｅ］
また、ブロック要素、例えばオブジェクトの場合は以下のようになる。
＜ｏｂｊｅｃｔ  ｄａｔａ＝“ｘｘ．ｊｐｇ”ｔｙｐｅ＝“ｉｍａｇｅ／ｊｐｇ”  ｓｔｙｌｅ＝“ｔｏｐ：ｘｘｍｍ；  ｌｅｆｔ：ｘｘｍｍ；  ｗｉｄｔｈ：ｘｘｍｍ；  ｈｉｇｈｔ：ｘｘｘｍｍ；”  ／＞
【００３７】
図１５は、ＢＭＬ／ＰをＸＭＬドキュメントとして、木構造で表現した図である。まず、ＢＭＬ／Ｐ文書の構造について以下に説明する。
“ＢＭＬ”が最上位に位置し、その下に“ｈｅａｄ”と“ｂｏｄｙ”が配置される。“ｈｅａｄ”部分には“ｔｉｔｌｅ”や“ｓｔｙｌｅ”等が配置され、実際のコンテンツは“ｂｏｄｙ”要素の下に位置することになる。ある要素の上に表される要素が親（ブロック）、その下は子（ブロック）となる。特定の場合を除き、属性は親（上位ブロック）から子（下位ブロック）に継承される。
【００３８】
ところで、本実施形態のような民生用機器においては、リソースの制限により、ＰＣで用いられているような大型のパーサは導入できない。従って、小規模のパーサで処理可能なレイアウト表現である必要がある。そこで、ＢＭＬとの相互変換が容易なＢＭＬ／Ｐを考案した。ＢＭＬ／Ｐのパーサが分担する機能は、記号表の管理や木構造の検索・処理とか、記号表やリスト構造体の検索・管理などである。ここで、字句解析には、「？」、「！」、「＜＞」、「＜／＞」、「＝  」、「“  ”」、「；」、「：」等を検索キーとしている。
【００３９】
図１６は、ＢＭＬ／Ｐの表現・記述例を示した図である。以下はプリンタ側の処理についてそのＣＳＳスタイルシートの管理を説明したものである。
まず、属性値は親から子に「継承」される。スタイルの記述方法にはドキュメント全体の設定（リンク読み込み型スタイル）、ページ全体の設定（埋め込み型スタイル）、インラインの設定（インライン型スタイル）の三段階がある。同じ属性に対して異なる方法が設定されている場合、より小さい部分（ブロック）での設定が優先される。デバイス固有のスタイルは、ドキュメント木構造におけるルートのイニシャル値（既定値）として作用する。
【００４０】
さらに、属性値の継承を管理するには、各ノードに対する属性マップを予め作成し、実作業に備える。ここで、属性：属性値は各処理単位（ドキュメント）で完結し、その枠外（ボリューム）には継承しない。そこで、上記属性値のマップを用いてレイアウト情報を事前に作成する。次に、注目バンド幅（例＝１インチ幅、最小＝キャラクター１ライン、最大＝１ページ）にヒットする画像やキャラクターを切り出して、描画し印字バッフアに蓄える。上記印字バッフアのデータを印字エンジンに対応するフォマットに変換し、所定の形式・手順・プロトコルで送出する。
【００４１】
図１７は、第１の属性値の継承管理法について説明するための図である。
ここにおいて、先ずＢＭＬ／Ｐのツリーを解釈して属性値を調べる方法がある。このやり方は、ｏｎｅ  ｐａｓｓ逐次処理方式に比べ、理にかなった効率的な方法である。ただし、ドキュメントデータが全て揃うまで処理を待たなければならない。ただし、Ｏｂｊｅｃｔ（画像など）であらかじめ、レイアウト・大きさが解決できれば実体のダウンロードは後でもかまわない。
【００４２】
Ｐａｓｓ  Ｏｎｅ（下準備）：
Ｎｏｄｅ毎に属性名→値のＭａｐを保持する。
１）各Ｎｏｄｅを順に辿ってゆき、
２）そのＮｏｄｅに合致するＣＳＳを検索してＭａｐに格納
３）そのＭａｐをインラインのスタイルで上書き
＊Ｍａｐの中身は例えばＦｏｎｔ：ｘｘ；  Ｗｉｄｔｈ：ｘｘ；  Ｈｅｉｇｈｔ：ｘｘ；  Ｃｏｌｏｒ：ｘｘｘ；などである。以下に「下準備」で作成した構造体のリンク状態例を示した。
【００４３】
Ｐａｓｓ  Ｔｗｏ（実作業）：
１）実際に描画するときには、必要な属性名をＭａｐから検索する。
２）Ｍａｐから検索できたらその値を使えばよい。
３）見つからない場合はデフォルトスタイルシートを参照する。
４）もし、デフォルトスタイルの値が“Ｉｎｈｅｒｉｔ”である場合は、親Ｎｏｄｅをたどり、その親Ｎｏｄｅに対して上記手順を繰り返す。
【００４４】
なお、ルートにたどり着いても“Ｉｎｈｅｒｉｔ”のまま解決がつかない場合は、「埋め込みスタイル」を、さらには「デバイス固有のスタイル」を適用する。「デバイス固有のスタイル」は実装されるプラットフォーム・機器によって予め決められたものである。
【００４５】
図１８は、第２の属性値の継承管理法について説明するための図である。
この方式は、子ｎｏｄｅを描画するときには、必ず親ｎｏｄｅの情報は確定していることに注目した方式である。この方式に拠れば、ドキュメント情報が全て揃わななくとも処理を開始できる利点がある。ただし、テーブル要素などレイアウトに重大な結果をもたらすセレクタの処理等は注意が必要である。この場合は、事前に仕様の取り決め・制限を設ける。
【００４６】
属性値の有効範囲は値が宣言されたブロックの内側で有効となる。そのブロックで宣言されていない属性が参照された時は、デフォルトスタイルシートを参照する。もし、デフォルトが「ｉｎｈｅｒｉｔ」となっていたら、宣言が最初に存在する外側のブロックの値を採用する。ここで、前記ブロックの「内側・外側」はドキュメントの木構造における、ノードの「下位・上位」に対応する。
【００４７】
以下に、本発明に一実施形態における継承の管理をリスト構造体で行う方法について説明する。
“ｓｃｃ＿ｃｏｎｔ＿ｔｂｌ”はスタイル管理テーブル、“ｓｃｃ＿ｔｂｌ＿ｘｘ”はスタイル登録テーブルをそれぞれ表す。すなわち、“ｓｃｃ＿ｃｏｎｔ＿ｔｂｌ”は“ｓｃｃ＿ｔｂｌ”を管理するためのテーブルであり、“ｓｃｃ＿ｔｂｌ”へのリンクポインタや登録有効数などを記憶する。また、“ｔａｉｌ＿ｐｔｒ”はリンクしているテーブルの最後のテーブルを示すポインタであり、“ｃｕｒｒｅｎｔ＿ｐｔｒ”は現在処理中のブロック内で有効なテーブルのポインタであり、“ｎｕｍｂｅｒ”は現在有効な登録テーブルの数をそれぞれ表す。
【００４８】
“ｓｃｃ＿ｔｂｌ＿００”はデバイス固有のスタイルを記憶する。次の“ｓｃｃ＿ｔｂｌ＿０１”はドキュメントヘッダにおいて＜ｓｔｙｌｅ＞・・・＜／ｓｔｙｌｅ＞で宣言する「埋め込Ｓｔｙｌｅ」を記憶する。“ｓｃｃ＿ｔｂｌ＿０２”以降は「インライン  スタイル」を記憶する。“ｎｅｘ＿ｐｔｒ”は各テーブルの前方リンクである。一方、“ｐｒｅ＿ｐｔｒ”は各テーブルの後方リンクである。“ｓｃｃ＿ｔｂｌ”の初期値は「ｉｎｈｅｒｉｔ」で、Ｉｎｌｉｎｅで属性が宣言される度にその値を上書きする。もし、内側のブロックに処理対象が遷移して、新たにインラインスタイルが宣言されれば、その内容を含むテーブルをリンクする。外側のブロックに処理対象が遷移する時は、現在のブロックに対応するテーブルを削除する。そこで、属性値が新たに宣言されたなら、その内容を含むテーブルをリンクする。
【００４９】
以下では、プリンタ側の処理について、そのページレイアウトの管理を説明する。
プリンタが一度に受け入れることの出来るコンテンツの大きさは、コンテンツを保持できるメモリ容量に依存する。本実施形態では、プリンタは最低１ページ分のコンテンツを保持できるものとする。ところで、プリンタが上記保持容量を越えたとき、プリンタはその時点でページレイアウトを確定して、一旦印字する。しかる後に残りのコンテンツを受け入れてレイアウト処理を再開する。このケースではページ間でレイアウトの不連続が起きることがある。このレイアウトの不連続を改善するために、先行するページのレイアウト情報を後続するページに継承する。
【００５０】
図１９は、テーブル要素を実現するための実施形態を説明するための図である。
本実施形態では、テーブル外枠の幅をスタイルで指定できる。
例：＜ｔａｂｌｅ  ｓｔｙｌｅ＝“ｔｏｐ：１０ｍｍ；  ｌｅｆｔ：１５ｍｍ；  ｗｉｄｔｈ：１５０；”／＞
テーブル外枠の高さ指定もできる。
例：＜ｔａｂｌｅ  ｓｔｙｌｅ＝“ｔｏｐ：１０ｍｍ；  ｌｅｆｔ：１５ｍｍ；  ｗｉｄｔｈ：１５０；  ｈｉｇｈｔ：２００；”／＞
【００５１】
ただし、前記ケースでは、出力メディアがある特定の形態に規定されるため、本来の「様々なメディア合わせてオートで配置する機能」を使う利便性は得られない。この場合、コンテンツ製作者の責任で、結果を予め確認することが前提となる。また、セルサイズを個々に指定することは出来ない。
【００５２】
ところで、画像をセル内に配置する場合、予め画像サイズの指定があればそれに従う。無ければ、画像サイズは初期値であるセル幅均等割付を適用したセルサイズにフィティングされる。セルサイズが仮決定している状態で、そのセルサイズより大きい画像を配置するときは、画像のサイズを縮小する。
【００５３】
さらに、テーブルはそのページ内で完結させることを前提とする。もし、コンテンツ表現におけるテーブル要素の作用する範囲が複数ページにまたがっていて、かつ、レイアウトの処理中にプリンタのリソースが不足したときは、処理を中断し、その時点での作表・レイアウトを決定する。そのページの印字が完了し、前リソースが開放した時点で、残りの表を新たにレイアウトし、印字する。この場合、表のセルサイズが前記ケースの前後で変化することがある。この場合、ページ送り後のセルサイズは直前のサイズを初期値とすることにより、スタイルの不連続が緩和する。
【００５４】
また、本実施形態では、テーブルの途中で“ｐａｇｅ−ｂｒａｋｅ”は適用しない。また、テーブルの入れ子の深さ（ネストレベル）は各プリンタのリソースに依存する。テーブルのセル幅・高さを自動決定する場合のルールはシステムで予め決めてある。コンテンツのレイアウトを表現する部分には、実体である画像データとその付加情報（画像データの大き、出力時のサイズ）を含む。ただし、テーブル外枠の大きさの指定があるときは、その外枠サイズを優先して適用する。
【００５５】
以上説明してきたように、本実施形態によれば、属性値の管理を、ページやコンテンツ全体を単位として一括して行うのではなく、コマンドライン単位に逐次行うため、コマンドの解釈と印字の実行を平行して行える。また、大きな継承マップを保持する必要が無いので、パーサのリソースが少なくても済む利点がある。
【００５６】
また、本実施形態によれば、印字データをプリンタエンジンの処理単位で形成できるため、ページやコンテンツ全体の印字データを保持する必要が無い。従って、印字データを保持するメモリも少なくて済む利点がある。さらに、本実施形態によれば、コンテンツが全て揃わなくとも印字データの作成を開始できるため、結果として、印字動作を早く開始できる利点がある。
【００５７】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【００５８】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００５９】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【００６０】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（基本システム或いはオペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６１】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６２】
ここで、本発明の実施態様を以下に列挙する。
［実施態様１］情報を入力する入力手段と、
前記入力手段より入力した前記情報内のコマンドライン間における属性値の継承管理を行う管理手段と、
前記情報に含まれるコマンドライン及び前記管理手段による管理内容を解釈する解釈手段と、
前記解釈手段による解釈結果に基づいて、出力手段に対して前記情報の出力制御を行う出力制御手段とを有することを特徴とする出力制御装置。
【００６３】
［実施態様２］前記管理手段は、前記解釈手段が前記コマンドラインの解釈の度に参照し、或いは逐次有効な内容に更新するリスト構造体を含むことを特徴とする実施態様１に記載の出力制御装置。
【００６４】
［実施態様３］前記情報は、前記情報内のデータがタグによって区切られることでデータ構造を表現するマークアップ言語で記述され、画像ファイルと前記画像ファイルのレイアウト情報とを含むことを特徴とする実施態様１又は２に記載の出力制御装置。
【００６５】
［実施態様４］情報を入力する入力ステップと、
前記入力ステップにて入力された前記情報内のコマンドライン間における属性値の継承管理を管理手段において行う管理する管理ステップと、
前記情報に含まれるコマンドライン及び前記管理手段による管理内容を解釈手段にて解釈する解釈ステップと、
前記解釈手段による解釈結果に基づいて、出力手段に対して前記情報の出力制御を行う出力制御ステップとを含むことを特徴とする出力制御方法。
【００６６】
［実施態様５］実施態様４に記載の出力制御方法をコンピュータに実行させるためのプログラム。
【００６７】
［実施態様６］実施態様５に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【００６８】
【発明の効果】
本発明によれば、ページやコンテンツ全体を単位として一括して属性値の管理を行うのではなく、コマンドライン間における属性値の継承管理を行ってコマンドライン毎に属性値を管理するように構成したので、コマンドの解釈と情報の出力制御を並行して実行することが可能となり、出力制御装置側の処理負担を軽減することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る印字システムの構成を概略的に示したブロック図である。
【図２】本発明の一実施形態において適用するＩＥＥＥ１３９４  Ｉｎｔｅｒｆａｃｅプロトコル・スタックを説明するための図である。
【図３】本発明の一実施形態におけるＤＰＰ／ＤＰＣパケット  Ｐａｃｋｅｔを用いた“Ｓｅｎｄ”データ構造を模式的に示した図である。
【図４】本発明の一実施形態におけるＤＰＰ／ＤＰＣパケットのヘッダー各要素に対する意味付けを示した図である。
【図５】本発明の一実施形態におけるチューナ（ＳＴＢ）内部でのデータ処理フローを示した図である。
【図６】本発明の一実施形態に係るデジタルテレビチューナ（ＳＴＢ）のシステム構成を模式的に示した図である。
【図７】本発明の一実施形態におけるプリント専用ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を説明するための図である。
【図８】デジタルテレビ放送のチューナ内部におけるＢＭＬ／Ｐコンテンツのファイル構成を示した図である。
【図９】図８のモジュール群から印字用モジュール（ここでは、９９９９番）だけを書き出した図である。
【図１０】マルチパート化したファイルの一構成例を示した図である。
【図１１】デジタルテレビによるプリント実行処理を簡略化して示した図である。
【図１２】デジタルデータ放送における著作権保護に関する一実施形態を説明するための図である。
【図１３】本発明の一実施形態で適用した印字レイアウト用マークアップ言語ＢＭＬ／ＰとＢＭＬとの関係を説明する図である。
【図１４】本発明の一実施形態で適用した印字範囲の指定について説明するための図である。
【図１５】ＢＭＬ／ＰをＸＭＬドキュメントとして、木構造で表現した図である。
【図１６】ＢＭＬ／Ｐの表現・記述例を示した図である。
【図１７】第１の属性値の継承管理法について説明するための図である。
【図１８】第２の属性値の継承管理法について説明するための図である。
【図１９】テーブル要素を実現するための実施形態を説明するための図である。
【符号の説明】
１０  チューナ
１１  表示装置
１２  メモリカード
２０  プリンタ
２１  プリンタコントローラ
２２  プリンタエンジン
【図１】
2005004281.tif 000003
【図２】
2005004281.tif 000004
【図３】
2005004281.tif 000005
【図４】
2005004281.tif 000006
【図５】
2005004281.tif 000007
【図６】
2005004281.tif 000008
【図７】
2005004281.tif 000009
【図８】
2005004281.tif 000010
【図９】
2005004281.tif 000011
【図１０】
2005004281.tif 000012
【図１１】
2005004281.tif 000013
【図１２】
2005004281.tif 000014
【図１３】
2005004281.tif 000015
【図１４】
2005004281.tif 000016
【図１５】
2005004281.tif 000017
【図１６】
2005004281.tif 000018
【図１７】
2005004281.tif 000019
【図１８】
2005004281.tif 000020
【図１９】
2005004281.tif 000021