JP2004199545A - 文書作成校閲システム - Google Patents

Abstract

【目的】記事の組み上がりの状態を早期に入稿者に提示し、組版のターンアラウンドタイムを削減する。
【構成】所定のタイプに定形化可能な記事情報を入稿にコンピュータにより組版する文書作成校閲システムであり、記事情報に付加して記事情報の取り扱いを決める、記事タイプ情報を含む記事データをマークアップ言語形式で出力するエディタ手段と、記事タイプ情報に基づいてマークアップ言語形式データから記事タイプ情報に合致したＰＯＳＴＳＣＲＩＰＴ類似形式の組版データを作成する組版手段と、マークアップ言語形式データから記事タイプ情報に合致するＨＴＭＬ形式の公開データを生成するＨＴＭＬ生成手段と、組版データ及びＨＴＭＬ形式の公開データを参照するためのアクセス情報をコンピュータネットワークを通じて入稿者に通知する通知手段とから構成される。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、有料で広告掲載主から記事情報を入手し、これを入稿して新聞を作成するフリーペーパーにおける記事のように、一定のタイプに定形化可能な記事を入稿してコンピュータにより組版する文書作成校閲システムに関する。
【０００２】
【従来の技術】
フリーペーパー、新聞等の印刷を行うにあたっては、ＤＴＰ（ＤＥＳＫ ＴＯＰ ＰＵＢＬＩＳＨＩＮＧ：デスク・トップ・パブリッシング）と呼ばれるコンピュ−タによる電子組版が広く利用されている。フリーペーパー各社、あるいは、大手新聞社から中小新聞社においても、システム規模に差こそあれ、基本的な処理の流れは同様である。記事はワープロ、あるいはホームページから入力され、テキスト形式によって組版システムに渡されることが多い。組版システムとしては、専用に開発されたソフトウエア、あるいは、米国アドビ社により販売されているＤＴＰ組版ソフト（ＤＴＰツール）が利用されることが多い。
【０００３】
また、印刷機の印刷原版作成用のデータ形式としては、「ＰＯＳＴＳＣＲＩＰＴ」と呼ばれる米国アドビ社が開発したデファクトスタンダードが利用されることが多い。そして、ＰＯＳＴＳＣＲＩＰＴ以外には、同じく、米国アドビ社が開発したデファクトスタンダードである「ＰＤＦ」が、よりデータ量が小さなデータ形式として利用されている。このような組版用のツールに提供するために、入稿された記事に付随した写真は、デジタルデータとしてデータベース化されている。そして、ＤＴＰツールによって、テキスト形式の記事と写真は組み合わされ、組版が実現される。この組版作業は、大手の新聞社ではかなりの割合が自動化されているが、小さな新聞社では、ＣＲＴ（陰極線管）等のディスプレイ上で、人手で作成されることが多い。
【０００４】
ここで、注意せねばならないことは、記事の入稿者（新聞記者）は、記事入稿時点では、最終的な印刷時の組版イメージを知り得ないことである。組版後の仕上がりは、あくまでも、他の記事との兼ね合いがあるから、どの程度のサイズ、あるいは大きさをもって記事が組版されるかは記者による入稿段階では決定不可能である。組版して初めて、記事の許容サイズ（文書の量）が判明する。結果として、この段階で初めて、入稿者に対して、記事の縮減が要求されることがある。実際、大手の新聞社の組版システムであっても、入稿されるのはテキストであって、何段階かの編集デスクの校閲を経た後、組版システムで組版イメージが初めて決定され、記者に返信される。すなわち、基本的には、新聞記者は、組版後の記事の紙面上のサイズ、形、位置にはタッチしない。そもそも、新聞記事は内容が勝負であるので、新聞記者はそのような組版上のパラメータに頓着する必要もない。
【０００５】
新聞記者が、記事内容について、情報提供者に確認をとることはあり得る。この場合、テキスト上の文言が、取材元の表現意図に合致しているかどうかが確認される。記事のデータ形式は、ワープロ等の打ち出しで十分である。一般紙では、記事内容に対する責任はあくまで、新聞記者が持っている。例えば、不正を働いた政治家や、犯罪被疑者に取材した場合などは、情報提供元に確認をしなかったり、あるいは、確認をして情報提供元が否認しても、記事として入稿する。即ち、一般紙では、組版後の表現は、情報提供者には無関係である。一般紙ではお金を払うのは、購読者である。入稿者（新聞記者）に情報を提供した情報提供者ではない。本来、情報提供者は、組版後の記事の位置やサイズに文句を言える立場ではない。
【０００６】
これに対して、有料で広告掲載主から記事情報を入手して、これを入稿して新聞を作成するフリーペーパーでは、このあたりの事情は大きく異なる。フリーペーパーでは記事に対してお金を払うのは、広告掲載主であり情報提供者でもある記事掲載依頼主である。新聞を読む読者ではない。入稿された記事がどんな仕上がりとなるかは、お金を支払っている記事掲載依頼主の大きな関心事である。組版データは、必ず、記事掲載依頼主、すなわち、記事の情報提供者にフィードバックされねばならない。言い換えると、一刻でも早く、記事の組版上のイメージを記事掲載依頼主に見せて了解をもらうことが入稿者の大きな責務である。この点で、フリーペーパー社は、一般紙とは大きく異なるのである。
【０００７】
以上のような背景によって、フリーペーパー社では、すこしでも早く、組版後のイメージを情報提供者、即ち、広告依頼主に見せて、納得してもらう必要がある。これが遅れるほど、手戻りが大きくなり、工数、即ち、人件費の増大を招く。しかし、現状では、記事が入稿されたときにはテキスト形式であるので、その組版イメージはすぐには得られない。組版イメージが確定するのは、他の記事とともに、ＤＴＰツール上で組版が行われた段階であって、これは、フリーペーパー作成の最終段階に近い。それまでには、入稿した取材記者のみではなくて、取材記者の上にいるマネージャー、編集担当者、そして、ＤＴＰツール担当者などの多くのスタッフの処理を受けている。
【０００８】
組版イメージが確定するのがフリーペーパー編集の最終段階であるとしても、これを広告依頼主である情報提供者に見せないわけにはゆかない。仮に、情報提供者が、組版イメージに不満を述べて、修正を要求した場合にはどうなるだろうか？例えば、「もっと写真を大きくしてくれ」とか、「写真を右ではなくて、左下にしてくれ」と要求がでると、記事の入稿者は、ＤＴＰ編集担当と連絡を取り、ＤＴＰツール上での修正を行ってもらい、これを、再度、ファックスなどの手段により、情報提供者（広告依頼主）に送って確認を求める必要が生じる。
【０００９】
上記の作業が一回で収斂すれば、まだ手直しの時間は限定されたものとなる。しかし、これが、何度も修正が要求されてしまい、最終的に「こんなものなら、広告は不要だ！」と情報提供者が言い出すと、組版全体は大きな影響を受ける。すでに出来上がっている組版仕上がりイメージに穴があく。これを補填する別の記事が必要となり、ＤＴＰ担当者は、この抜けた記事と、その新しい記事と入れ替える必要がある。しかし、もし、新しい記事の分量が、それまでの記事の分量と異なっていたらどうなるであろうか？ＤＴＰ担当者が書いた全体の配置、記事の大きさなどは大きな影響をうけ、その手戻りと修正の工数は、決して軽視できるものではない。
【００１０】
フリーペーパー社の記事掲載に関しては、上記問題以外にも課題がある。それは、ホームページの作成である。近年、新聞記事をホームページに掲示することがよく行われるようになった。このようなフリーペーパー社の大きな特徴は、一般紙とは異なり、どうしても、商品や商店を紹介する画像が伴っていることである。通常、ホームページに掲載される記事と、フリーペーパー紙面に掲載される記事は同一内容と思ってよい。しかし、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式のホームページと、ＰＯＳＴＳＣＲＩＰＴで組版機から出力される組版データとは、配置、色など組版情報は同一ではない。それぞれなりに、配置が修正される。このような事情により、ＨＴＭＬ形式のホームページについては、ＤＴＰの担当者が、記事に合致した組版上の配置、位置、サイズ等を判断して作成していた。しかし、これは、記事数が多くなると、決して楽ではない。工数を必要とする作業である。
【００１１】
さらに、フリーペーパーには組版上の別の問題がある。それは、記事相互の配置の問題である。フリーペーパーでは、例えば、和菓子のお店の記事（広告）のすぐ横に、和菓子のお店の記事（広告）があることは嫌う。言うまでもなく、これは、類似の業種が紙面上で並ぶことによって、ＰＲ効果が薄れることを避ける目的がある。例えば、和菓子の広告なら、京都観光記事や、煎茶のＰＲ記事の横にあったほうがむしろ、望ましいはずである。あるいは、京都の記事のみを集めるアプローチも効果がある可能性がある。しかし、このような配置は、あくまでも、ＤＴＰ組版段階で、ＤＴＰ組版担当者によって検出、判断されるべき問題であり、記事情報を入稿する取材記者には、その入稿段階では、タッチできないことであった。
【００１２】
【発明が解決しようとする課題】
以上から、フリーペーパーの入稿時点で直ちに組版イメージ、及びＨＴＭＬ作成イメージを確認でき、また、フリーペーパー上の記事の配置において、隣接することが望ましくない配置を防止し、あるいは、類似のタイプをもつ記事を集める組版システムが必要である。従って本発明の課題は、組みあがりの状態を早期に入稿者に提示し、組版のターンアラウンドタイムを削減することである。
【００１３】
【課題を解決するための手段】
上記の課題を達成するため、本発明は、記事情報に付加して記事情報の取り扱いを決める、記事タイプ情報を含む記事データをマークアップ言語形式で出力するエディタ手段と、記事タイプ情報に基づいてマークアップ言語形式データから記事タイプ情報に合致したＰＯＳＴＳＣＲＩＰＴ類似形式の組版データを作成する組版手段と、マークアップ言語形式データから記事タイプ情報に合致するＨＴＭＬ形式の公開データを生成するＨＴＭＬ生成手段と、組版データ及びＨＴＭＬ形式の公開データを参照するためのアクセス情報をコンピュータネットワークを通じて入稿者に通知する通知手段によって文書作成校閲システムを構成するという手段を講じたものである。
【００１４】
上記構成を有する本発明では２つのキーとなるアイデアを利用している。第１のアイデアは、記事のタイプを表現する「記事タイプ情報」を、記事情報に付加したことである。記事タイプ情報には本明細書では、２つの種類が例示される。第１の種類は、記事の組版上のタイプを設定するための情報である。例えば、１段組とか２段組の種別を表現するタイプ情報である。あるいは、写真の位置でもよい。これに対して、第２の種類は、記事の内容に対応する記事タイプ情報である。記事が扱う業種や、記事が表現している店舗などの地理上の位置に相当する情報である。更に、本発明の２つ目のキーとなるアイデアは、タグつきデータを利用することである。具体的には、マークアップ言語と呼ばれる言語形式即ち記事を構成する各データ要素を区別するためのタグを具備したデータ構造であれば、どのようなタグ構造を利用するかは当業者の設計上の選択に任せられる。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ、請求項５）や、ＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）でもよいし、あるいはまた、単なる特定のビット列をタグとしてもよい。タグがあることによって、例えば、上記の記事タイプ情報が自動的に識別可能となり、複数の記事タイプ情報が存在しても、これを正しく認識可能となる。
【００１５】
ここで記事タイプ情報は、本質的に、記事の組版上のサイズを限定されたタイプに絞る効果を有する。一般に、組版上は、記事の掲載幅、段組（１段組、２段組）、写真位置（右上とか左下）はＤＴＰツール上で自由に設定できる。しかし、本発明の主旨に基づき、前記記事タイプ情報によって、これらは、あらかじめ定められた有限個のタイプによって選択指定される。言い換えれば、記事の幅、段組、写真位置は、有限の種別しかない。これらは、複数の記事タイプ情報で個々独立に指定してもよく、あるいは、それらを組み合わせた記事の組版上の形態のタイプを有限個設けても良い。更に、この記事タイプ情報としては、扱っている記事の業種（当然、有限個のタイプを想定する）、あるいは、記事が紹介している店舗の地理上の位置（大阪、神戸など）に対応したタイプを設定しても良い。
【００１６】
エディタ手段は、記事データを入力するためのものである。通常のエディタと同じ役割であるが、大きな特徴として、出力は、マークアップ言語形式などのタグつきデータ構造で出力する。マークアップ言語は、「＜ｈｏｏ＞」と言った形式の開始タグと、「＜／ｈｏｏ＞」と言った形式の終了タグによって囲まれたデータから成っている。タグは、即ち、＜ｈｏｏ＞と＜／ｈｏｏ＞の間に囲まれたテキストの属性がｈｏｏであることをこのタグは表現している。タグによって属性が規定されたテキストは、階層構成をなしている。マークアップ言語の詳細については、全体的な意義付けは、例えば、村田真著「マークアップ言語入門」日本経済新聞社（ＩＳＢＮ４−５３２−１４６１０−０）１９９８年１月発行、に記載されている。また、マークアップ言語自体の詳細な技術的解説は、例えば、中山幹敏編著、奥井康弘編著、「標準マークアップ言語完全解説・上・改訂版」技術評論社（ＩＳＢＮ４−７７４１−１１８６−４）、２００１年４月発行、に記載されている。
【００１７】
組版手段は、前記マークアップ言語形式の記事データから組版仕上がりを出力する機能を持つ。ここで、記事の組版仕上がりの形態（サイズ、段組、写真位置等）は、記事タイプ情報によって制限されているので、組版手段は、これに合致した、組版処理を行い、ＰＯＳＴＳＣＲＩＰＴ、あるいはＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｉｌｅ、米国アドビ社開発のファイル形式）と言ったＰＯＳＴＳＣＲＩＰＴ類似形式の組版出力を行うことが可能である。ただし、言うまでもなく、ここで出力されるのは、ひとつの記事に対する組版結果である。なおここで、あえて「ＰＯＳＴＳＣＲＩＰＴ類似形式」と規定している理由は、ＰＯＳＴＳＣＲＩＰＴなどのプリンタ記述言語を用いれば、その出力を、更に、ＤＴＰツール上に貼り付けて、高品位に自由に拡大縮小できるからである。これが、ビットマップであると、ＤＴＰツール上で拡大すると画像があらくなるが、プリンタ記述言語で記述したものであれば、拡大縮小しても、印刷上の品位が低下しないメリットがあるからである。ＰＯＳＴＳＣＲＩＰＴ類似形式とは、ＰＯＳＴＳＣＲＩＰＴ及びＰＤＦを含むがその他のプリンタ記述言語であってもよい。
【００１８】
ＨＴＭＬ生成手段は、前記マークアップ言語形式の記事データから、ＨＴＭＬ出力を生成する。ここで、マークアップ言語形式の記事であるので、例えば、「＜Ｐ＞」「＜／Ｐ＞」と言ったタグで段落を表現しておけば、ＨＴＭＬ出力を作成する際の、段落タグに容易に置き換えることができる。この例では、たまたま、ＨＴＭＬの段落タグと同一のタグを例示したが、マークアップ言語形式データの側では、段落タグとして、当業者が任意にタグの名称を設定できることに留意する必要がある。
【００１９】
通知手段は、入稿者がＰＯＳＴＳＣＲＩＰＴ類似形式データ、あるいは、ＨＴＭＬ形式の公開データをインターネットで参照するためのアドレス（ＵＲＬ）を入稿者に通知する。具体的には、たとえば、メールを用いてこのＵＲＬを報知してもよく、あるいは、前記エディタ手段によって記事を入稿した際に、自動的に、ＰＯＳＴＳＣＲＩＰＴ類似形式データやＨＴＭＬ形式の公開データをアクセスするリンクをもったＨＴＭＬ形式画面を打ち返しても良い。
【００２０】
以上の構成によって、入稿者は、記事を入力すると、ただちに、組版イメージ、あるいは、ＨＴＭＬ公開イメージを確認できる。したがって、情報提供者（広告依頼主）の現場で取材して記事を作成したような場合には、情報提供者に、その場で、ＨＴＭＬ公開イメージや、ＰＤＦ形式での印刷元データを見せることができる。これにより、早めに情報提供者の了解を取り付けることが可能となり、手戻りの手間が削減される。このように他記事の存在とは無関係に、記事の印刷イメージを提示できるのは、あらかじめ、記事タイプ情報を制限して、この範囲においてのみ、自動的に組版を行っているからであり、その組版結果をＰＤＦ形式で出力すれば、ＰＤＦ用の無料のリーダーによって、インターネットを経由して、誰でも、結果を確認できる。
【００２１】
また、本発明の文書作成校閲システムでは、マークアップ言語形式データにより表現された複数個の記事データに対して、その記事タイプ情報を調べ、隣合う位置に配置された記事の記事タイプ情報があらかじめ定められたルールに合致しているか否かを検査する記事チェック手段と、前記記事チェック手段により不適切とされた記事データの記事タイプ情報に対する警告信号を送出する通知手段を有することができる（請求項２）。記事チェック手段は、複数の記事データが入力されたときに、仮の記事の紙面上の配置を生成し、生成された配置情報を出力するとともに、望ましくない隣接関係にあるか否かをチェックする。例えば、記事データが複数存在したとする。この記事データは、とりあえず、入力された順序で、紙面上割り付けられたとする。記事チェック手段は、この割り付けられた状況をみて、例えば、同一の業種が隣接していると、隣接している記事の位置と、望ましくない理由を出力する。同一業種の和菓子屋が隣接したり、あるいは、京都と大阪の記事しかないのに、京都と大阪がバラバラに配置されて、「京都と大阪の霜降り状態」になっているとこれを検出する。この場合通知手段は、メール等によって、入稿者あるいはＤＴＰ担当者に対して、前記チェック結果を通知する機能を有する。この結果から、例えば、人手で、記事の順序を変更して、「京都と大阪の霜降り状態」を回避することを、促す作用を有している。
【００２２】
また、本発明の文書作成校閲システムでは、前記記事チェック手段により不適切とされた記事データの順序を、あらかじめ定められた置き換えルールにより自動的に修正する修正手段を有することができる（請求項３）。修正手段は、前記の記事チェック手段により、記事の順序が不適当と判定されたときに、この順序を変更する。例えば、配置をランダムに入れ替えて、同業者が隣接しないように配慮したり、あるいは、地区が近いものを集めて連続する順序に変更するなどの作用を成す。
【００２３】
また、本発明の文書作成校閲システムでは、マークアップ言語形式データにより表現された複数個の記事データに対して、その記事タイプ情報を調べ、隣合う位置に配置された記事の記事タイプ情報があらかじめ定められたルールに合致しているか否かを検査する記事チェック手段と、前記記事チェック手段により不適切とされた記事データの記事タイプ情報を、あらかじめ定められた置き換えルールにより自動的に修正する修正手段を有し、かつ、この記事タイプ情報の修正により記事の過不足が生じた場合に、その旨を通知する通知手段を有することができる（請求項４）。
【００２４】
前記記事チェック手段は、複数の記事データが入力されたときに、仮の記事の紙面上の配置を生成し、生成された配置情報を出力するとともに、望ましくない隣接関係にあるか否かをチェックするものであり、前記修正手段は、前記記事チェック手段により、記事の順序が不適当と判定されたときに、記事タイプ情報を修正して、記事の配置上、問題がないように修正するものであるが、通知手段は、そのようにして記事の量が変化した際に、これを入稿者に通知する。具体的には、例えば、写真の位置を変更すると、禁則処理の関係で、記事テキストの分量に過不足が生じることがある。そのような場合について、入稿者にその旨を連絡して、対応を促す作用を有する。通知手段としての制限はなくメールでもよい。
【００２５】
【発明の実施の形態】
図１は、本発明の実施例１を示す。本発明に係る実施例１の文書作成校閲システムは、記事タイプ情報１００を含む記事データ１０１をマークアップ言語形式（本実施形態ではＸＭＬ形式とする。）で出力するエディタ手段１０２と、記事タイプ情報１００に基づいてマークアップ言語形式の記事データ１０１から記事タイプ情報１００に合致したＰＯＳＴＳＣＲＩＰＴ類似形式の組版データ１０３を作成する組版手段１０４と、マークアップ言語形式の記事データ１０１から記事タイプ情報１００に合致するＨＴＭＬ形式の公開データ１０５を生成するＨＴＭＬ生成手段１０６と、組版データ１０３及びＨＴＭＬ形式の公開データ１０５を参照するためのアクセス情報１０７を通知する通知手段１０８とから構成される。
【００２６】
記事タイプ情報１００は、組版上の条件を与えるための付加情報である。本発明では、記事サイズを任意とはせず、有限個数に絞り込む。一例として、図２に示すような、１段組と２段組を考える。この場合、記事タイプ情報としては、「１段組」「２段組」の２通りの値を持つ属性が準備されなければならない。記事サイズの限定は、自由な紙面の構成を制限する。しかし、これによって、組版データの自動生成が可能となり、あるいは、後述するように、複数の記事の相互関係をチェックしたり、再配置することが自動化可能となる。
【００２７】
また、記事タイプ情報１００は、例えば、写真の「右」「左」といった位置指定であってもよい。この場合にも、例えば、記事の上部から何ミリと言った指定も可能であるが、むしろ、「右」「左」といった有限のタイプ種別数のもののほうが、本発明の主旨にはより合致する。ただし、この写真位置を、前記の記事のサイズ指定と併合して「右２段組」と言った指定をするか、あるいは、２個の記事タイプ情報として表現するかは、当業者の自由な設計上の選択である。
【００２８】
また、記事データ１０１は、マークアップ言語により表現された記事情報である。図３には、簡単な例をイメージとして示した。わかりやすくするために、タグによって囲まれた実際のデータを太字の斜字体で表現している。本発明の特徴として、記事タイプ情報に相当する、記事段組、あるいは、写真位置などの情報は、図３では、「組版」の名称を持つタグの配下に、２個のデータとして格納されている。
【００２９】
組版データ１０３は、記事を図３の１段組み、あるいは、２段組で印刷するためのデータであり、ＰＯＳＴＳＣＲＩＰＴ、あるいはＰＤＦ形式の組版データである。このようなデータは、例えば、図３のマークアップ言語形式の記事データから、プログラムによって変換して、組版言語ＴＥＸ（スタンフォード大学のＤ．Ｅ．Ｋｎｕｔｈ教授によって開発された文書処理システム）のソースファイルを生成し、このソースファイルを（例えば、ｐＬａＴｅＸ２Ｅ．１．８）等によってコンパイルして、これを変換プログラムによって、ＰＤＦに変換するなどの方法によって生成される。この場合、組版手段１０４は、ＴＥＸソースファイルを生成するプログラムとｐＬａＴｅＸ２Ｅにより構成される。
【００３０】
公開データ１０５は、ＨＴＭＬ形式のホームページ公開のためのデータである。ＨＴＭＬの場合には、組み版データとは異なり、ＨＴＭＬ言語で書かれたテキストである。図３のようなマークアップ言語形式の記事データでは、どこが表題で、どこが記事本体であるかは、タグを見れば直ちにわかる。したがって、図のようなマークアップ言語形式の記事データを生成することは、簡明な変換プログラムによって実行できる。この変換プログラムがＨＴＭＬ生成手段１０６であり、生成結果のＨＴＭＬ形式のファイルが公開データ１０５である。
【００３１】
以上の処理によって、ＨＴＭＬ形式の公開データ１０５と、組版データ１０３が生成される。例えば、組版データ１０３がＰＤＦであるなら、記事の入稿者に、この組版データ１０３と公開データ１０５のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ、インターネット上でのアドレス）を知らせてやれば、入稿者は、遠隔地からでも、組版の仕上がりイメージを確認できる。このためには、例えば、双方のＵＲＬをＥメールで入稿者に送信したり、あるいは、これらのＵＲＬにリンクをはった画面を、入稿者のパソコンに打ち返すような処理を実現すればよい。このように、ＵＲＬを相手に報告する手段が通知手段１０８であり、また、通知されるＵＲＬが、アクセス情報１０７となる。以上の構成により、入稿者は、記事の仕上がり（印刷）イメージと、ＨＴＭＬによる公開イメージを入稿後、すみやかに確認できる。
【００３２】
また、図４は、本発明の実施例２を示すものである。実施例２の文書作成校閲システムは、マークアップ言語形式データ１０１により表現された複数個の記事データに対して、その記事タイプ情報１００を調べ、隣合う位置に配置された記事の記事タイプ情報１００があらかじめ定められたルールに合致しているか否かを検査する記事チェック手段２００と、前記記事チェック手段２００により不適切とされた記事データの記事タイプ情報１００に対する警告信号２０１を送出する通知手段２０２とを、図１に示した実施例１に付加したものである。図４において、記事タイプ情報１００は、図１の記事タイプ情報と同一である。また、エディタ手段１０２も、図１のエディタ手段１０２と同一である。
【００３３】
記事チェック手段２００は、本発明の実施例２において、最も特徴的な構成を有する。即ち、記事チェック手段２００は、複数の記事データ１０１を対象として、各記事データ１０１に含まれる記事タイプ情報１００について吟味する。
【００３４】
図５ａ、図５ｂは、記事チェック手段２００により検査される対象となる記事の状態を紹介したものである。複数の記事は、図５ａ、５ｂに示すように、仮に配置されているとする。この配置の順序は、例えば、記事の入稿された順序である。システムのインプリメント上、たまたまこうなったに過ぎないものとする。
【００３５】
図５ａでは、記事は京都の間に大阪がはさまれている。もし、各記事について記事タイプ情報として、どこの都市（あるいは県）の記事であるかが記載されていれば、このような配置は、以下のルールによって検出される。ルール１：同一の都市名を記事タイプとして有する記事の間に、これとは異なる都市名を記事タイプとしてもった記事がはさまれて存在してはならない。
【００３６】
また、図５ｂは、他の例である。この例では、和菓子の記事が接近して、しかも、多少なりとも関係ある煎茶は遠くにあって、しかも、煎茶と和菓子の間に、和菓子とはあまり関係のない紅茶が入っている。このような配置は、以下のルールによって検出される。ルール２：同一業種を隣接させてはならない。ルール３：和菓子と煎茶の間にそれ以外の業種が入ってはならない。
【００３７】
記事チェック手段２００は、以上のようなルールをあらかじめ記憶しておき、記事の配置をチェックする。記事の配置についてルール違反が検出された場合には、その旨を通知手段２０２に通知する。
【００３８】
通知手段２０２は、ルール違反があることを、警告信号２０１により報知する。例えば、警告信号２０１は、ルール違反の対象となった記事の識別番号、ルール違反の原因となった記事タイプ情報１００として、実際の現状の配置順序に関する情報から構成される。一般には、この通知が行われる相手は、ＤＴＰ担当者である。ＤＴＰ担当者は、記事の順序を変更することによって、このルール違反に対処する。
【００３９】
以上の構成によって、ＤＴＰ担当者は自動的に生成された記事の順序に問題があることを認知できる。本実施例では、この順序が自動的に補正されることはない。ＤＴＰ担当者は、この記事順序を、送られてきた警告信号２０１に基づいて修正する。それでも、順序に問題がある場合には、本実施例は、再度、警告をおくることとなる。
【００４０】
図６は、本発明の実施例３を示すものである。実施例３の文書作成校閲システムはマークアップ言語形式データにより表現された複数個の記事データ１０１に対して、その記事タイプ情報１００を調べ、隣合う位置に配置された記事の記事タイプ情報１００があらかじめ定められたルールに合致しているか否かを検査する記事チェック手段２００と、前記記事チェック手段２００により不適切とされた記事データ１０１の順序を、あらかじめ定められた置き換えルールにより自動的に修正する修正手段３００とを実施例１に付加したものに相当する。
【００４１】
図６において、記事タイプ情報１００は、図１の記事タイプ情報と同一であり、また、エディタ手段１０２も、図１のエディタ手段１０２と同一である。また、記事チェック手段２００は、図４の記事チェック手段２００と同一である。記事チェック手段２００は、複数の記事データ１０１を対象として、各記事データ１０１に含まれる記事タイプ情報１００について吟味する。
【００４２】
修正手段３００は、本実施例３の最も特徴的な構成要素である。この修正手段３００は、記事チェック手段２００のチェック結果に基づいて、記事の順序を自動的に並び替える。図７ａ、図７ｂは、その記事の再配置の例である。まず、最初、複数の記事は、図７ａに示すように、仮に配置されているとする。この配置の順序は、例えば、記事の入稿された順序である。システムのインプリメント上、たまたまこうなったに過ぎないものとする。次に、この順序を、記事チェック手段２００がチェックする。この場合、「京都」が離れているので、望ましくない。このことは、記事チェック手段２００から、修正手段３００に通知される。
【００４３】
修正手段３００は、上記の並ぶ順序の問題点を修正する。図７ａから図７ｂへは記事の並べ替えの様子を示している。この場合、図７ａでは、京都の記事である記事１と記事４が離れている。そこで、修正手段３００は、この記事４を記事１の直後に移動した。結果として、図７ｂのような配置になる。これによって、同一都市の名称が、離れて存在することはなくない、フリーペーパー読者の利便性が向上する。
【００４４】
図８は、本発明の実施例４を示すものである。実施例４の文書作成校閲システムは、マークアップ言語形式データにより表現された複数個の記事データ１０１に対して、その記事タイプ情報１００を調べ、隣合う位置に配置された記事の記事タイプ情報１００があらかじめ定められたルールに合致しているか否かを検査する記事チェック手段４００と、前記記事チェック手段４００により不適切とされた記事データの記事タイプ情報１００を、あらかじめ定められた置き換えルールにより自動的に修正する修正手段４０１を有し、かつ、この記事タイプ情報１００の修正により記事の過不足が生じた場合に、その旨を通知する通知手段４０２とを実施例１に付加したものに相当する。
【００４５】
図８において、記事タイプ情報１００は、図１の記事タイプ情報と同一である。また、エディタ手段１０２も、図１のエディタ手段１０２と同一である。
【００４６】
図８において、記事チェック手段４００は、図４の記事チェック手段２００とほぼ同一である。ただし、ただし、ここで、チェックされるのは、例えば、写真の位置のような、記事が有する別の属性である。記事チェック手段４００が具備すべき機能について、図９を用いて説明する。図９では、３つの記事が並べられている。この場合、記事１では、写真は右下にあり、記事２、記事３では左上にある。これらの写真の位置は、記事の掲載を依頼した広告主の希望であったものと思われる。しかし、図９を見てわかるように、この写真の配置はバランスが悪い。ばらばらの印象を受ける。このような配置については、美術分野では一定のガイドラインがあると思われるが、本明細書では図９の簡単な例で考える。この場合、記事チェック手段４００は、以下のルールを用いてチェックを行うものとする。ルール４：横方向の記事の中で、ひとつの記事のみが、写真の上下位置が他と異なっている場合には、その配置が他とは異なる記事について、チェック結果を不可とする。
【００４７】
もちろん、上記のチェック段階で、図４の実施例２のような構成にすることも考えられる。即ち、チェック結果のみをＤＴＰ担当者に報告するアプローチである。これに対し、図８の実施例４では、実施例２を更に一歩進めたものである。即ち、修正手段４０１が、違反している記事の属性（記事タイプ情報１００）を変化させる。図９の例について言えば記事１の写真の位置を示す記事タイプ情報１００が修正されて、他とならんで、左上に変更される。つまり、写真位置が揃うことになる。
【００４８】
ただし、実際の組み版を考えると、ことは単純ではない。例えば、図９の例で考えると、写真のサイズが（図９の例ではみな同一サイズであるが）一個のみ小さいと問題である。このような場合には、写真サイズを他を合わせる必要がある。この場合、写真以外の場所に配置された記事テキストに過不足が生じることになる。あるいは、写真のサイズが変らなくても、写真の位置が変化すると、写真の横に回りこんでいたテキストの禁則処理の関係で、やはり、テキストに過不足が生じる。
【００４９】
図８の修正手段４０１は、図６の修正手段３００とほぼ同一の機能を有するが、上記のようなテキストの過不足を生じる点が、図６の修正手段３００とは異なっている。これにより、テキストの過不足が生じた場合には、図８の通知手段４０２によって、入稿者に注意がうながされる。もともと、入稿者の氏名は、マークアップ言語形式の記事データ１０１に含まれているとする。また、連絡先のメールアドレスも、このマークアップ言語形式の記事データ１０１に含めておけば、テキストの量に問題のある記事について、通知手段４０２により通知することができる。
【００５０】
以下、発明を構成する構成要素について、簡単な説明を加えておく。まず、エディタ手段１０２は、例えば、Ｗｅｂブラウザで走行するプログラムとして実現できる。ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）により投入されたデータは、サーバ側でマークアップ言語形式に変換される。この処理は、多少のプログラミングスキルを要する。しかし、汎用のツールが種々、提供されており、比較的簡明な処理で、この機能を実現できる。例えば、ＢＸＳ（Ｂａｙｋｉｔ マークアップ言語 Ｓｅｒｖｅｒ）は、日本発のオープンソースであるが、Ｘｉ（ザイ）と呼ばれるＸＳＬＴを拡張した言語により、容易にサーバ側でマークアップ言語形式のデータを生成できる。この生成された記事データが記事データ１０１と考えればよい。
【００５１】
組版手段１０４は、前述したように、ひとつの実現方法は、ｐＬａＴｅＸ２Ｅによる処理である。Ｋｎｕｔｈにより開発された組版言語であるＴｅＸの上にマクロとして提供されたｐＬａＴｅＸ２Ｅでは、簡単なＴｅＸソースファイルを記述するのみで、高品位の組版が実現される。マークアップ言語形式で保存された記事データ１０１から、必要な情報、例えば、記事のタイトル、記事のサブタイトル、本文、連絡先電話番号、連絡先名称などを取り出すことは、（もともと、それらがマークアップ言語のタグとして定義されて、入力されていれば）当業者には実現が可能である。これにより、ＤＶＩ（Ｄｅｖｉｃｅ Ｉｎｄｅｐｅｎｄｅｎｔ）形式とよばれる組版データが生成されるが、これを、ＤＶＩＰＳＫなどのコマンドにより処理することにより、ＰＯＳＴＳＣＲＩＰＴ形式のデータが作成できる。そして、このＰＯＳＴＳＣＲＩＰＴ記述の組版データは、米国アドビ社が市販しているＰＤＦ作成ツールによって、容易にＰＤＦに変換できる。即ち、図１の組版手段１０４とは、これらのＴＥＸソースファイルを生成するプログラム、ｐＬａＴｅＸ２Ｅ、そして、ＤＶＩＰＳＫコマンドとアドビ社のツールである。また、組版データ１０３とは、このようにして生成されたＰＤＦと考えればよい。
【００５２】
ここで注意しなければならないのは、写真の位置、大きさなどは、すべてＴＥＸソーフファイルの中にコマンドとして記述される。したがって、マークアップ言語形式の記事データ１０１の中に、記事タイプ情報１００として、写真の位置や、大きさを指示するタグさえ設けておけば、このタグのデータを読み取って、ＴＥＸソーフファイルに反映させることはプログラムにとっては容易である。結果として、記事タイプ情報１００は、そのまま組版データ１０３に反映されることとなる。
【００５３】
また、図１の公開データ１０５は、ＨＴＭＬ形式で表現された記事データである。これは、複数の記事データから一枚のＨＴＭＬファイルを生成してもよく、あるいは、各記事データ１０１毎に、ＨＴＭＬファイルを生成してもよい。この場合でも記事のタイトル、サブタイトルがマークアップ言語形式のタグとして設定されているなら、容易に取り出して、ＨＴＭＬのしかるべき場所に設定できる。
【００５４】
図１の通知手段１０８は、前述したように、公開データ１０５や組版データ１０３のＵＲＬを入稿者に知らせるためのメールシステム、あるいは、ＨＴＭＬを打ち返すサーバとして実現できる。例えば、メールで返信するためには、マークアップ言語形式の記事データ自体に、入稿者のメールアドレスを表示するタグが必要となる。
【００５５】
図４の記事チェック手段２００は、連続した記事データ１０１の相互の関係を調べて、図５に示すような配置上の問題点をチェックする。適用すべきルールは、直接にプログラムで記述してもよく、あるいは、何らかのルール言語を作成して、このルール言語をインタープリトするような処理系を作成してもよい。または、Ｐｅｒｌ（Ｐｒａｃｔｉｃａｌ Ｅｘｔｒａｃｔｉｏｎ ａｎｄ Ｒｅｐｏｒｔ Ｌａｎｇｕａｇｅ）等によって直接に記述してもよい。できれば、ルールに優先順位を持たせたほうが、将来的なルールの追加には有利と思われる。
【００５６】
図４の通知手段２０２は、メールでもよく、あるいは、ＨＴＭＬファイルをクライアントに打ち返す方法でもよい。ここには、ルールによるチェック結果が表示される。具体的には、「記事×と記事×の間に無関係な記事○が入っている」といった情報を返すのみでよい。
【００５７】
図６の修正手段３００は、上記の記事チェック手段２００により問題があるとされた場合に、記事の順序を入れ替える作用を持つ。例えば、上記のように、本来はジャンルを異にした記事が間に入っている場合には、間に入っている記事を後ろにずらせるなどの方法で対処できる。
【００５８】
図８の記事チェック手段４００、修正手段４０１、通知手段４０２は、本実施例に特有な面をもつ。即ち、記事チェック手段４００は、ここでは、連続した記事の写真の位置や大きさを調べて、バランスが悪くないかどうかを検査する。もし、バランスが悪い場合には、例えば「一枚だけ画像が上下方向に異なっていれば、その例外的な記事についてのみ、写真の1を他に合わせる」といった処理を修正手段４０１が行う。修正手段４０１は、記事テキストの分量が適当かどうかを監視しており、問題がある場合には、その記事を識別するための情報と問題点を通知手段４０２に送信する。ｐＬａＴｅＸ２Ｅによる組版では、組み版終了後の文字の位置は、ＰＯＳＴＳＣＲＩＰＴファイルに記述されるから、プログラムでこれを読み、どの程度の余白が存在するかを調べることは、比較的容易である。
【００５９】
【発明の効果】
以上説明したように、本発明では、入稿者に組版イメージ、および、ＨＴＭＬ形式の公開データを人手を介することなく、自動的に生成できる。また、生成結果をすばやくフィードバックして、フリーペーパーの業務を効率化できる。
【００６０】
また、本発明によれば、記事を紙面にならべた際の相互関係で、同一業種が連続してしまったり、例えば京都に関する記事があちこちに飛んでしまうというような問題を回避できる。
【００６１】
また、本発明によれば、記事の写真位置や記事の段組（１段、２段）を容易に変更できる。
【００６２】
また、本発明によれば、写真の位置やサイズが変更された場合に、入稿者にすばやく対処を要求して、編集のターンアラウンドタイムを削減できる。
【図面の簡単な説明】
【図１】本発明の実施例１を示すブロック図。
【図２】段組の例を示すブロック図。
【図３】マークアップ言語形式データの例を示すブロック図。
【図４】本発明の実施例２を示すブロック図。
【図５ａ】記事配置の例（１）を示す説明図。
【図５ｂ】記事配置の他の例（１）を示す説明図。
【図６】本発明の実施例３を示すブロック図。
【図７ａ】修正前の記事配置の例（２）を示す説明図。
【図７ｂ】修正後の記事配置の例（２）を示す説明図。
【図８】本発明の実施例４を示すブロック図。
【図９】記事配置の例（３）を示す説明図。
【符号の説明】
１００ 記事タイプ情報
１０１ 記事データ
１０２ エディタ手段
１０３ 組版データ
１０４ 組版手段
１０５ 公開データ
１０６ ＨＴＭＬ生成手段
１０７ アクセス情報
１０８ 通知手段
２００ 記事チェック手段
２０１ 警告信号
２０２ 通知手段
３００ 修正手段
４００ 記事チェック手段
４０１ 修正手段
４０２ 通知手段

Claims (5)

1. 所定のタイプに定形化可能な記事情報を入稿してコンピュータにより組版する文書作成校閲システムであって、記事情報に付加して記事情報の取り扱いを決める、記事タイプ情報を含む記事データをマークアップ言語形式で出力するエディタ手段と、記事タイプ情報に基づいてマークアップ言語形式データから記事タイプ情報に合致したＰＯＳＴＳＣＲＩＰＴ類似形式の組版データを作成する組版手段と、マークアップ言語形式データから記事タイプ情報に合致するＨＴＭＬ形式の公開データを生成するＨＴＭＬ生成手段と、組版データ及びＨＴＭＬ形式の公開データを参照するためのアクセス情報をコンピュータネットワークを通じて入稿者に通知する通知手段とから構成されることを特徴とする文書作成校閲システム。
2. マークアップ言語形式データにより表現された複数個の記事データに対して、その記事タイプ情報を調べ、隣合う位置に配置された記事の記事タイプ情報があらかじめ定められたルールに合致しているか否かを検査する記事チェック手段と、前記記事チェック手段により不適切とされた記事データの記事タイプ情報に対する警告信号を送出する通知手段とを有する請求項1記載の文書作成校閲システム。
3. 記事チェック手段により不適切とされた記事データの順序を、あらかじめ定められた置き換えルールにより自動的に修正する修正手段を有する請求項２記載の文書作成校閲システム。
4. マークアップ言語形式データにより表現された複数個の記事データに対して、その記事タイプ情報を調べ、隣合う位置に配置された記事の記事タイプ情報があらかじめ定められたルールに合致しているか否かを検査する記事チェック手段と、前記記事チェック手段により不適切とされた記事データの記事タイプを、あらかじめ定められた置き換えルールにより自動的に修正する修正手段を有し、かつ、この記事タイプ情報の修正により記事の過不足が生じた場合に、その旨を通知する通知手段により通知するようにした請求項１又は請求項４記載の文書作成校閲システム。
5. マークアップ言語形式はＸＭＬ形式である請求項１ないし請求項４のいずれかに記載の文書作成校閲システム。

Images