JP4017659B2 - テキスト入力フォント・システム - Google Patents

Description

著作権所有表記
本特許明細書の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標局の特許ファイルまたは記録に記載されている特許文書または特許開示事項を第三者が複製することを妨げるものではないが、その他の場合には、著作権を有する一切の権利を留保する。
関連特許出願の相互参照
本件特許出願は、特許出願（発明者Debra L.Orton、David B.Goldsmith、Christopher P.Moeller、およびAndrew G.Heninger、発明の名称「オブジェクト指向フレームワーク・システム」（Object Oriented Framework System）、1992年12月23日出願、被譲渡人Taligent社）の関連出願であり、その開示事項は引用により本明細書の一部を構成するものである。
本件特許出願は、本出願と同時に出願された特許出願（発明者Russell Sonnenschein、発明の名称「フォント選択システム」（FONT SELECTION SYSTEM）、被譲渡人Taligent社）の関連出願であり、その開示事項は引用により本明細書の一部を構成するものである。
発明の分野
本発明は、一般的には、コンピュータ・システムにおける改良に関し、より具体的には、テキストがコンピュータに入力されると、インテリジェントに判断してフォント・スタイルを追加することに関する。
発明の背景
アップル（登録商標）社マッキントッシュ（登録商標）やマイクロソフト（登録商標）社ウィンドウズ（商標）などのシステムでは、文字コードの意味に負担がかかりすぎになっている。例えば、コード0x53は、コンテキスト（文脈）によってはローマ文字の‘S’を表す場合とギリシア文字の‘S’を表す場合とがある。このように文字コードに負担がかかりすぎると、クライアントが複数のスクリプトと記号を含むテキストを編集する必要があるとき問題が起こっている。スクリプト（script）とは、意味論的に関係のある意味をもつ文字コードが集まったものである。通常、１つの言語は１つのスクリプトにマッピング（写像）される。例えば、ローマ文字、ギリシア文字およびヘブライ文字のコードはすべてが別々のスクリプトになっている。
商用化されているシステムでは、ほとんどすべてが文字符号化の意味（semantics）に過重な負担をかけている。あるシステムでは、コード・ページ・アーキテクチャによって符号化を行っており、他のシステムではフォントを変更することによって（これはコード・ページを指定するのと同じである）符号化を単純化している。コード・ページ（code page）はIBMシステムに共通するものである。文字のコンテキストは、現在使用中のフォントまたはコード・ページによって決まる。大部分のシステムでは、複数のスクリプトからのテキストさえも扱うことができない。それが可能であっても、多くのシステムは多くて２つのスクリプトのテキストが扱えるだけである。また、大部分のシステムは、文字が入力されたとき、その文字が現在のフォントの中に存在するかどうかを検出することができない。従って、‘S’を入力したつもりでいても、その文字は、現在のフォントに応じて‘S’と表示されることがある。これは、文字コードだけに基づくと、文字の意味が何であるかを、システムが区別できないためである。あるシステムはユーザ・インタフェース・レベルでこの問題に対処するために、キーボードを特定のフォントに関連づけようとしている。しかし、この種の解決方法は、文字がキーボードを使用しないでプログラムで入力されるとき役に立たない。
文字コードに負担をかけすぎると起こる問題がもう１つある。クライアントが異なるスクリプトからの文字ストリング（文字列）にフォント・スタイル（font style）を適用しようとしたとき、文字が曲解（garbled）されるおそれがあることである。例えば、テキストは、“S n/2”のような単純な式を含んでいる場合がある。テキスト上のフォントをChicagoフォント風に見せるために小さなボールド・フォント（little bolder）に変更する必要がユーザに起こったとする。ユーザがその式を選択し、フォントを変更すると、その結果はボールド字体で“S n/2”と表示されることになる。その選択の中に、多数の異なるスクリプトからの文字が含まれていると、問題はさらに悪化する。
これらの問題はどちらも、文字コードに過重な負担をかけているシステムに固有のものである。汎用符号化（universal encoding）に基づくシステムでは、すべての文字が独自のコードをもっているので、機会を利用してこれらの問題に対処している。しかし、現時点では、多くのシステムは、これらの問題の扱い方が効率的でない。ゼロックス社提供のシステムのように、汎用文字符号化を使用するシステムは、一般的に、ある文字が現在のフォントから抜けていることを知らせるだけである。例えば、シグマは、それをある種のランダムな絵文字にマッピングするのではなく、脱落している絵文字（missing glyph）として表示されることになる。絵文字（glyph）とは、文字コードを可視的に表現したものである。コード・ページに基づく従来のシステムでは文字はランダムな絵文字にマッピングされることになる。
フォント選択方法は、固定ピッチとプロポーショナル・フォントを選択することに対しては知られている（IBM Technical Disclosure Bulletin, Vol.34, No.11, Aplil 1992, pages 336 and 337）。印刷時に、フォント・リストが文書の文字に対してサーチされる。一致を発見すると、文字が表示される。一致を発見しないと、２つの他のフォントがサーチされ、前記２つのフォントのいずれかの中にピッチの一致を見い出す。この方法は、順序づけられたフォント・テーブルを必要としない。
発明の概要
従って、本発明の主目的は、ドキュメントに現れることを期待している文字とフォントがユーザに表示されるようにフォントを自動的に選択するシステムおよび方法を提供することである。本発明の好適実施例によれば、ある文字または文字ストリング（文字列）がテキスト・ストリームに入力されたとき、第１のプロセスが使用される。現在のタイピング・スタイル（typing style）に指定されているフォントにその文字がなければ、このプロセスはその文字を表示できるフォントを選択する。例えば、“Σ”を表すコードが“n/2”の前に挿入されると、プロセスは“Σ”を表示できるフォントを使用して、コードを自動的にスタイル化する。文字をスタイル化（styling）するとは、文字が、その文字に関連づけられたフォント・スタイルを常にもつことを意味する。
【図面の簡単な説明】
第１図は、本発明によるパーソナル・コンピュータ・システムを示すブロック図である。
第２図は、現在のフォントが文字を表示できないとき新しいフォント・スタイルで文字を自動的にスタイル化する、本発明によるロジックを示す図である。
第３図は、本発明に従って一致するフォントを探し出すロジックのフローチャートを示す図である。
第４図は、本発明による絵文字挿入の例を示す図である。
第５図は、本発明によるフォントにない文字の例を示す図である。
第６図は、本発明によるフォント処理の例を示す図である。
第７図は、本発明による絵文字処理の例を示す図である。
第8a図、第8b図、第8c図、第8d図、第8e図および第8f図は、本発明によるタイピング・スタイル変更の例を示す図である。
第９図は、本発明に従ってテキスト選択でフォントをセットするためのロジックのフローチャートを示す図である。
第10図は、本発明に従ってテキスト選択でフォントをセットするための代替ロジックの別フローチャートを示す図である。
第11図は、本発明によるギリシア文字センテンスの例を示す図である。
第12図は、本発明に従って第10図に示すロジックを第11図に示すギリシア文字センテンスに適用したときの例を示す図である。
第13図は、本発明に従って第９図に示すロジックを第11図に示すギリシア文字センテンスに適用したときの例を示す図である。
第14図は、本発明による５つのギリシヤ文字の単語の例を示す図である。
第15図は、本発明に従ってChicagoフォントを第14図に示すギリシア文字の単語に適用したときの例を示す図である。
第16図は、本発明に従ってギリシア文字フォントを第14図に示すギリシア文字の単語に適用したときの例を示す図である。
第17図は、本発明に従ってクーリェ・フォントを第14図に示すギリシア文字の単語に適用したときの例を示す図である。
第18図は、本発明に従ってZapf Dingbatsフォントを第14図に示すギリシア文字の単語に適用したときの例を示す図である。
第19図は、従来のシステムを使用してZapf Dingbatsフォントをギリシア文字の単語に適用したときの例を示す図である。
第20図は、従来のシステムを使用してクーリェ・フォントをギリシア文字の単語に適用したときの例を示す図である。
第21図は、従来のマッキントッシュ・コンピュータ・システムでクーリェ・フォントをヘブライ文字に適用したときの例を示す図である。
発明の詳細な説明
本発明の好適実施例は、IBM（登録商標）社PS/2（登録商標）またはアップル（登録商標）社マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータ上に置かれているオペレーティング・システムの下で実施される。第１図は代表的なハードウェア環境を示したもので、従来のマイクロプロセッサのような中央処理ユニット10と、システム・バス12を介して相互接続された複数の他のユニットとを装備した本発明によるワークステーションの代表的なハードウェア構成が示されている。第１図に示すワークステーションは、ランダム・アクセス・メモリ（RAM）14と、リードオンリ・メモリ（ROM）16と、ディスク・ユニット20などの周辺デバイスをバスに接続するための入出力（I/O）アダプタ18と、キーボード24、マウス26、スピーカ28、マイクロホン32、および／またはタッチ・スクリーン・デバイス（図示せず）などの他のユーザ・インタフェース・デバイスをバスに接続するためのユーザ・インタフェース・アダプタ22と、ワークステーションをデータ処理ネットワークに接続するための通信アダプタ34と、バスを表示デバイス38に接続するための表示アダプタ36とを含んでいる。ワークステーションには、アップル・システム/7（登録商標）オペレーティング・システムなどのオペレーティング・システムが常駐している。
好適実施例によれば、２つのプロセスが採用されている。これらのプロセスは文字コードとフォント・スタイルを操作するためにテキスト・サブシステムによって使用される。第１のプロセスは、テキストが入力されると、インテリジェントに判断してフォント・スタイルを文字に追加する。第２のプロセスは、複数のスクリプトからの文字を含んでいる選択にフォント・スタイルを適用する。
前記したように、アップル（登録商標）社マッキントッシュ（登録商標）のようなシステムは、文字コードの意味に過重な負担をかけている。例えば、0x53はコンテキストによってはローマ文字の‘S’を表す場合とギリシア文字の‘Σ’を表す場合とがある。このように文字コードに負担がかかりすぎると、クライアントが複数のスクリプトと記号を含むテキストを編集する必要があるとき問題が起こっている。文字のコンテキストは、現在使用中のフォントまたはコード・ページによって決まる。
大部分のシステムは、文字が入力されたとき、その文字が現在のフォントの中に存在するかどうかを検出することができない。従って、‘Σ’を入力したつもりでいても、その文字は、現在のフォントに応じて‘S’と表示されることがある。これは、文字コードだけに基づくと、文字の意味が何であるかを、システムが区別できないためである。あるシステムはユーザ・インタフェース・レベルでこの問題に対処するために、キーボードを特定のフォントに関連づけようとしている。しかし、この種の解決方法は、文字がキーボードを使用しないでプログラムで入力されるときは不可能である。
文字コードに過重な負担をかけると起こる問題がもう１つある。クライアントが異なるスクリプトからの文字ストリング（文字列）にフォント・スタイル（font style）を適用しようとしたとき、文字が曲解（garbled）されるおそれがあることである。例えば、テキストは、“Σ n/2”のような単純な式を含んでいる場合がある。テキスト上のフォントを、例えば、Chicagoフォント風に見せるために小さなボールド・フォント（little bolder）に変更する必要がユーザに起こったとする。ユーザがその式を選択し、フォントを変更すると、その結果は“S n/2”と表示されることになる。その選択の中に、多数の異なるスクリプトからの文字が含まれていると、問題はさらに悪化する。
これらの問題はどちらも、文字コードに過重な負担をかけているシステムに固有のものである。汎用符号化（universal encoding）に基づくシステムでは、すべての文字が独自のコードをもっているので、機会を利用してこれらの問題に対処している。しかし、現時点では、多くのシステムは、これらの問題の扱い方が効率的でない。
ゼロックス社提供のシステムのように、汎用文字符号化を使用するシステムはある文字が現在のフォントから抜けていることを知らせるだけである。例えば、シグマは、それをある種のランダムな絵文字にマッピングするのではなく、脱落している絵文字として表示されることになる。
好適実施例では、２セットのプロセスが採用されている。１つはテキスト入力用であり、もう１つはフォント・スタイルをテキスト選択に適用するためのものである。フォント・スタイル（font style）とは、フォントを記号化したものである。フォントの全機能はフォント・スタイルを通して得られる。この処理によると、他のシステムで起こっている問題がなくなる。これらのプロセスを結合すると、表示されると期待していた文字が、そこに入っていると期待していたフォントで常にユーザに表示される。
第１のプロセスは、文字または文字ストリングがテキスト・ストリームに入力されたとき使用される。現在のタイピング・スタイルに指定されているフォントにその文字がないと、このプロセスはその文字を表示できるフォントを選択する。例えば、“Σ”を表すコードが“n/2”の前に挿入されると、プロセスは“Σ”を表示できるフォントを使用してコードを自動的にスタイル化する。
第２のプロセスは、クライアントがフォント・スタイル変更を文字の範囲に適用したとき使用される。このプロセスは、インテリジェントに判断してフォントを選択に適用する。例えば、本発明の好適実施例によれば、Chicagoフォントを“Σ n/2”の文字に適用すると、“Σ n/2”が得られる。
これらのプロセスはどちらも、次のような場合は、コード・ページ・ベースのシステムによって使用可能である。
・ プロセスは、文字コードを含むコード・ページを追跡（track）できる機能を備えている。
・ プロセスを使用するシステムは、単一のテキスト・ストリーム内の複数のコード・ページからの文字を扱うことができる。
・ プロセスは、フォントにない文字を検出できる機能を備えている。
実際には、下述するプロセスと同じようなプロセスを、コード・ページ・ベースのシステムが使用することは、不可能でないにしても、もっと困難になる。コード・ページ・ベースのシステムがこれらのプロセスを利用することが困難になる理由は、事態を複雑化する次のような制約がプロセスにあるのが通常であるためである。
・ プロセスが扱えるコード・ページは一度に１つだけである。
・ プロセスは１つのコード・ページ内に文字をオーバラップしている。
・ プロセスはフォントにない文字であるかどうかを検出できない。
・ プロセスは同じ文字を複数のコード・ページにマッピングできない。
Unicodeのような汎用文字符号化を使用するシステムでこれらのプロセスを利用すると、より有用であるのは、そのためである。プロセスは、入力テキスト全体で一度呼び出された場合も、テキスト全体の連続する断片で繰り返し呼び出された場合も、同じ振舞をする。
テキスト入力に対するタイピング・フォントの変更
第２図に示すロジックは、現在のフォントが文字を表示できないとき、文字を新しいフォント・スタイルで自動的にスタイル化する。プロセスは入力について繰り返されて、現在の文字に関連するフォントがその文字を表示できるかどうかを判断する。表示できなければ、プロセスは表示できるフォントを見つけることを試みる。そのあと、プロセスは入力テキストの後続文字をすべて同じフォントに保存しておく。
第３図に示すように、現在の文字を表示できるフォントを見つけるために、プロセスはテキスト・ストリーム中のすべての先行文字を解析（parse）し、そのあと後続文字の１つが参照しているフォントが現在の文字を表示できるまですべての後続文字を解析していく。フォントが見つからなければ、システムはシステムに用意されているすべてのフォントを探索する（ユーザの好みで指定された分類順に、あるいはスタイル突合わせプロセスで指定された分類順に）。
テキスト・ストリーム中のすべての文字はフォント・スタイルが関連づけられている。通常、フォント・スタイルはタイピング・スタイルから初期設定されるが、別の方法で設定することも可能である。文字は、NILスタイルをもつことができる。これは、どの文字も表示できないフォントに類似している。第二に、プロセスは特殊な脱落絵文字フォント（missing glyph font）を参照する。これは、文字置換目的だけに使用される特殊なフォントであり、他のどのフォントも、文字を表示できないとき使用される。好適実施例では、このフォントはスクリプト範囲全体内の文字を単一の絵文字にマップする。例えば、すべてのキリル文字は向きが反対のＲ（キリル文字のIA）と表示される。
処理は第２図のターミナル200から始まり、即時に機能ブロック210に移って、テキスト入力を得て、新しいテキストの挿入個所を識別する。そのあと、機能ブロック220で、入力テキストはスタイル化され、挿入個所からテキスト・ストリングに挿入される。判定ブロック222で、挿入されたすべての文字は、挿入処理が完了するまで処理される。挿入処理が完了すると、タイピング・スタイルは、機能ブロック224で処理された最後の文字のフォント・タイプと等しくされ、処理はターミナル226で完了する。挿入文字の繰返しは判定ブロック230で始まるループに入って処理され、そこで、現在の文字が最後に処理されたフォント・セットにあるかどうかを判断するテストが行われる。機能ブロック240に示すように、この処理は、文字コードを有効な絵文字にマップすることを試み、有効な絵文字が存在すればTRUE（真）を返却する。有効な絵文字が得られると、次に、newfont（新フォント）が機能ブロック262でlastfontprocessed（最後に処理されたフォント）と等しくされ、現在の文字がnewfontでスタイル化され、lastfontprocessedがnewfontに一致するようにセットされ、処理が判定ブロック222に渡されて、すべての挿入文字が処理されたかどうかが判断される。
有効な絵文字が判定ブロック230で見つからなければ、判定ブロック250で別のテストが行われ、現在の文字が、その文字独自のフォント・スタイルにるかどうかが判断される。そうであれば、lastfontprocessedが現在の文字のフォントに等しくなるようにセットされ、制御が判定ブロック222に渡されて、挿入すべき追加文字が残っているかどうかが判断される。現在の文字がその文字独自のフォント・スタイルにないと判定ブロック250で判断されたときは、第３図に示すロジックを使用してフォントを見つけなければならない。そのあと、テストが判定ブロック264で行われ、フォントが見つかったかどうかが判断される。フォントが見つからなければ、文字は、事前定義の脱落絵文字システム・フォントでスタイル化され、制御が判定ブロック222に渡されて、挿入すべき追加文字があるかどうかが判断される。フォントが見つかったと判定ブロック264で判断されると、制御が機能ブロック266に渡されて、newfontが見つかったフォントに等しくなるようにセットされ、現在の文字が新しいフォントでスタイル化され、lastfontprocessedが機能ブロック268でnewfontに等しくなるようにセットされ、制御が判定ブロック222に戻されて、処理すべき追加文字が残っているかどうかが判断される。
第３図は、本発明に従ってフォントを見つけるときの詳細ロジックを示す図である。処理は機能ブロック310から始まり、そこで、テキスト・ストリームが得られ、最初の文字を指しているポインタが識別される。そのあと、判定ブロック320で、最初の文字からテキストの先頭までの各文字yが検査され、文字がyのフォントにあるかどうかが判定ブロック330で判断される。文字があれば、フォントがターミナル370から返却される。文字がなければ、判定ブロック370が実行されて、処理すべき追加文字が残っているかどうかが判断される。すべての文字が逆方向に処理されると、テキストの最後までの各文字ｘからｙまでについて別のループが判定ブロック340で開始され、ｚがｘのフォントにあるかどうかが判定ブロック350で判断される。フォントがあれば、そのフォントがターミナル370から返却される。なければ、すべての文字が処理されるまで次の文字が判定ブロック340で処理される。そのあと、機能ブロック360で、フォントのリストが作成され、判定ブロック380で、マッピングを識別するために現在の文字が各フォントと突合わせ検査される。マッピングが得られると、フォントがターミナル370から返却される。マッピングが得られなければ、見つからなかったフォントがターミナル390から返却される。
第４図、第５図および第６図は、第２図および第３図に示す処理をもっと理解しやすくした例を示す図である。
これらの例では、２つのフォントがあることを想定している。
・ フォント‘G’は範囲0x370...0x3FFのすべての文字と文字0x020の絵文字をもっている。
・ フォント‘E’は範囲0x000...0x0FFのすべての文字の絵文字をもっている。どちらのフォントも文字0x20をマップすることができる。
コード・ストリング400、フォント410、体裁420、およびストリング・インデックス430が第４図に示すように与えられているとき、プロセスを使用しないで、新しい文字がインデックス15の文字のあとに挿入されると、新しい文字はフォント・スタイル‘E’を採用することになる。その結果のストリングは、第５図に示すストリングのようになる。
この処理が行われると、スペースを表すコード（コード0x20）が現れる個所を除くすべてには、脱落文字を示すストリング（この例では疑問符）が得られる。コード・ページをオーバラップするシステムでは、疑問符ではなく、別のコード・ページからランダムな文字が表示されるのが普通である。例えば、マッキントッシュ・コンピュータでは、文字16..24は文字がどのように表示されるか（“ton Qeon”）ではなく、“ton Qeon”と表示される。このプロセスをストリングに適用すると、第６図のラベル600に示すストリングに次のような望ましい結果が得られる。
注目すべきことは、最初の0x20はフォント‘E’に残っているが、２番目の0x20はフォント‘G’に変更されたことである。プロセスには、新しいフォントへの切替えが行われると、そうすることが可能ならば、後続のすべての文字が新しいフォントでスタイル化されるという、望ましい機能が備わっている。
上記プロセスを若干修正したものが、第７図に記載されているフローチャートに示されている。すでにフォント・スタイルをもっているテキストの中の脱落文字の絵文字をフィックス（修正）する必要がクライアントに起こったときは、第７図に示すロジックが使用される。このプロセスでの主な違いは、最初に、文字が独自のフォント・スタイルで表示可能かどうかをプロセスがチェックしてから、その文字が以前に処理されたフォント・スタイルで表示できるかどうかをチェックすることである。現在のフォントで表示できる文字にこのプロセスが及ぼす効果は、文字が未変更のままになっていることである。例えば、このプロセスは、異なるフォント構成をもつシステム間でテキストを転送するときに使用できる。
処理はターミナル700から始まり、直ちに機能ブロック710に移って、テキスト・ストリング、入力されるテキスト、入力テキストが追加される挿入個所を得て、lastFontProcessedをNIL文字に等しくなるようにセットする。そのあと、判定ブロック720で、ループが開始され、すべての文字が処理されるまで、新しく入力された文字の各々について繰り返される。すべての文字が処理されると、タイピング・スタイルは最後に処理された文字のフォント・スタイルに等しくなるように機能ブロック722でセットされ、処理はターミナル724で完了する。
処理すべき文字が残っていれば、判定ブロック730でテストが行われ、現在の文字がその文字独自のフォント・スタイルにあるかどうかが判断される。そうであれば、lastFontProcessedは現在の文字フォントに等しくなるように機能ブロック750でセットされ、制御が判定ブロック720に戻され、次の文字が処理される。そうでなければ、判定ブロック734でテストが行われ、現在の文字がlastFontProcessedにあるかどうかが判断される。そうであれば、newFontはlastFontProcessedに等しくなるように機能ブロック740でセットされ、現在の文字は新しいフォントでスタイル化され、lastFontProcessedはnewFontに等しくなるように機能ブロック770でセットされ、制御が判定ブロック720に戻され、次の文字が処理される。
テキスト入力フォント・システム
現在の文字がlastFontProcessedになければ、機能ブロック736で、現在の文字をもつフォントが探し出され、判定ブロック742でテストが行われ、フォントが見つかったかどうかが判断される。フォントが見つかれば、newFontが見つかったフォントに等しくなるようにセットされ、現在の文字が新しいフォントでスタイル化され、lastFontProcessedがnewFontに等しくなるように機能ブロック770でセットされ、制御が判定ブロック742に戻され、次の文字が処理される。フォントが見つからなかったと判定ブロック742で判断されたときは、機能ブロック760に示すように、文字は特殊な脱落絵文字システムでスタイル化され、制御が判定ブロック720に戻され、文字がさらに処理される。
文字変換時のタイイング・フォントの変更
第２図に示す処理は、２つのフォントがある種の文字を共用し、テキストが文字変換（transliterate）されるときの問題に遭遇したとき使用できる。この問題を理解しやすくするために、例を示して説明する。
ギリシア語の“LogoV”という単語をタイプし、そのあとに“P”の文字をタイプしたとする。そうすると、ストリングは“LogoV P”のようになり、ＰはBookmanフォントでスタイル化され、ストリングの残り部分はギリシア文字フォントでスタイル化される。また、システムに文字変換ソフトウェア（transliterator）があって、‘Pi’を‘P’に変換し、両方のフォントがギリシア語のPi文字を表示できるとする。そこで、ユーザが‘i’とタイプすると、その結果のストリングは“LogoV π”のようになる。pi文字は、ギリシア文字フォント・スタイルにではなく、Bookmanフォント・スタイルにあるので、もっと望まし結果はPi文字をギリシア文字フォントで表示することである（その結果、“LogoV P”のようになる）。
上記を行うためには、次のような余分のロジックをタイピング・スタイルと文字変換ソフトウェアに追加する必要がある。
・ タイピング・スタイルがユーザによって明示的に変更されたとき、現在のタイピング・スタイルは、文字変換ソフトウェアだけによってアクセスされる新しいタイピング・スタイルのコピーを残しておかなければならない。このコピーのことを、明示的タイピング・スタイル（explict typing style）と呼ぶことにする。第２図を参照して上述したプロセスがタイピング・スタイルを変更したとき、その変更は明示的タイピング・スタイルに影響しない。
・ 文字変換ソフトウェアはテキストを置き換えるとき次のことを行わなければならない。つまり、
置き換えた文字の前に置かれている文字が現在のタイピング・スタイルと同じフォントでスタイル化されていなければ、タイピング・スタイルを明示的タイピング・スタイルにリセットしなければならない。
この処理が扱うケースには、次のものがある。
２つのギリシア文字フォント（GとF）および１つのローマ文字フォント（E）があるとする。また、‘Pi’文字を‘P’文字にマップする文字変換ソフトウェアがあるとする。
次に、第8a図、第8b図および第8c図に示すストリングがあるとする。また、ユーザがタイピング・スタイルの文字をフォントＦに明示的に変更してから、第8b図に示すように、２番目のストリングに‘P’とタイプしたとする。ユーザが３つのストリングすべてに‘P’のあとに‘i’とタイプすると、ストリングは第8b図、第8e図および第8f図に示すようになる。３ケースのいずれも、結果はユーザが期待していたとおりになる。
選択へのフォント・スタイルの適用
フォント・スタイル変更をある文字範囲に適用するとき、クライアントが望むことは、システムがフォント・スタイルを、そのフォントが表示できる文字にだけ適用することである。これを正しく行うのが第９図に示すプロセスである。このプロセスは機能ブロック910から始まり、そこで、適用すべきフォント・スタイル、スタイル化されたテキスト・ストリームおよびfontStyleをセットすべきテキスト・ストリーム上の範囲または選択への参照が得られる。次に、判定ブロック920で、ループか開始され、startIndexからstopIndexまでのテキスト・ストリームの該当部分が処理される。stopIndexの文字の処理が終わると、処理はターミナル930に示すように完了する。追加の文字が残っていれば、判定ブロック940でテストが行われ、処理しようとする現在の文字がfontStyleにあるかどうかが判断される。そうであれば、fontStyleがその文字にセットされ、制御が判定ブロック920に渡されて、次の文字が処理される。処理中の文字がfontStyleになければ、制御は判定ブロック920に戻され、次の文字が処理される。
第10図に示す処理は、前後に置かれたすべてのスペースと句読点（引用符、カンマ、ピリオドなどを含む）を、その前後の文字と同じフォントに保存しておく点で複雑化している。実際には、この処理を行うと、もっと満足の行く結果が得られる。つまり、フォント設計者の期待通りの結果が得られる。さらに、この処理は、フォント・スタイルが各単語とスペースの間の前後に交互に現れるのを防止する。この切替えは、多くのシステムではパフォーマンスに問題が起こるおそれがある。
処理は機能ブロック1010から始まり、そこで、適用すべきフォント・スタイル、スタイル化されたテキスト・ストリームおよびfontstyleをセットすべきテキスト・ストリーム上の範囲または選択への参照が得られる。また、現在のフォント・スタイルがNILに等しくなるようにセットされ、文字Aスペースが偽（false）に等しくなるようにセットされ、newFontStyleがfontStyleに等しくなるようにセットされる。そのあと、判定ブロック1020でテストが行われ、現在の文字のfontstyleがあるかどうかが判断される。もしなければ、処理はターミナル1024で完了する。もしあれば、判定ブロック1022でテストが行われ、すべてのstopindexまで到達したかどうかが判断される。そうであれば、処理はターミナル1024で完了
する。そうでなければ、currentfontstyleは、機能ブロック1030に示すように、テキスト・ストリームの中で現在処理されている文字のfontstyleと等しくされる。そのあと、判定ブロック1032で別のテストが行われ、テキスト・ストリームの中で現在処理されている文字がスペースまたは句読点文字であるかどうかが判断される。そうであれば、lastcharacterspaceは機能ブロック1034でthischaracterspaceと等しくされる。
判定ブロック1040で別のテストが行われ、現在の文字がスペース文字であるかどうかが判断される。そうであれば、判定ブロック1050でループが開始され、文字がスペースまたは句読点文字であるかどうかが判断される。そうであれば、次の文字が判定ブロック1050で処理される。そうでなければ、nextFontStyleが機能ブロック1056でその文字のフォント・スタイルと等しくされ、テストが判定ブロック1058で行われ、文字がfontstyleにないかどうか、現在フォント・スタイルがNIL文字であるかどうかが判断される。そうであれば、別のテストが判定ブロック1080で行われ、現在のフォント・スタイルが次のフォント・スタイルと同じであるかどうか、現在の文字がフォント・スタイルにあるかどうかが確かめられる。そうであれば、最終テストが行われ、フォントが実際にシステムに存在するかどうかが判定ブロック1082で判断される。存在していれば、前のフォントが機能ブロック1060で現在のフォントと等しくされ、次の文字が判定ブロック1022で処理される。
現在の文字がフォント・スタイルに存在しないか、あるいは現在のフォント・スタイルがNIL文字でなければ、テストが判定ブロック1090で行われ、文字がfontstyleにあるかどうかが判断される。そうであれば、文字のfontstyleがセットされ、現在のフォント・スタイルがフォント・スタイルと等しくされ、前のフォントが現在のフォントと等しくされ、次の文字が判定ブロック1022で選択される。現在の文字がフォント・スタイルになければ、前のフォントが機能ブロック1060で現在のフォントと等しくされ、制御が判定ブロック1022に渡されて次の文字が処理される。
現在の文字がスペースまたは句読点文字でないと判定ブロック1032で判断されると、thisCharacterASpaceが偽（false）にセットされ、制御が判定ブロック1090に渡され、上述したように処理が行われる。
特殊な文字が見つからなかったと判定ブロック1040で判断されると、別のテストが判定ブロック1042で行われ、最初の文字が処理中であるかどうかが判断される。そうでなければ、nextFontStyleが機能ブロック1044でpreviousStypeと等しくされ、制御が判定ブロック1080に渡されて上述したように処理が行われる。最初の文字が処理中であれば、nextFontStyleがcurrentFontStyleと等しくされ、制御が判定ブロック1080に渡されて上述したように処理が行われる。第10図に示すスマートなプロセスは、テキストを解析し、新しいフォント・スタイルをフォントが表示できる文字に適用する働きをする。
スペースと句読点は特殊文字として扱われるので、このプロセスは最初の非スペースまたは非句読点文字を先読みして、その文字がスペースまたは句読点文字と同じフォントにあるかどうかをチェックする。また、フォントが非スペースまたは非句読点文字を表示できるかどうかもチェックする。この情報を使用して、プロセスは、フォント・スタイル変更をスペースまたは句読点文字に適用する必要があるかどうかを判断する。
注目すべきことは、このプロセスは選択に作用することである。選択がスペースと句読点だけを含んでいると、プロセスは前後の文字のフォントに関係なく、そのフォントが文字を表示できるものとして、文字のフォントを変更する。
第11図から第21図までは、代表的な複数スクリプト・テキストで行われる処理の例である。第11図に示す最初の例はギリシア文字センテンスを示している。テキスト全体が選択され、クーリェ・フォント・スタイルが適用されると、この処理から、第12図に示す結果が得られる。注目すべき重要なことは、ギリシア文字部分に含まれる引用符、ピリオド、スペースおよびカンマがギリシア文字フォントに保存されることである。この中にはセンテンスの最後の末尾句読点も含まれる。
第９図に示す単純な処理を用いて文字をマッピングしていれば、結果として得られるテキストは第13図に示すようになる。
第２の例は、第14図に示す５つのギリシア文字の単語に関係するものである。第14図に示すように、スペース、カンマおよびピリオドはすべてクーリェ・フォントを使用している。テキスト全体が選択され、Chicagoフォントが適用されると、本発明の実施例による処理から第15図に示す結果が得られる。結果に示すように、スペース、カンマおよびピリオドはChicagoに変更されている。これは、これらの文字のフォントが前後の文字のそれと異なっていることを、処理が感知したためである。最後の例からの結果にギリシア文字フォントを適用すると、第16図に示すテキストが得られる。結果に示すように、ギリシア文字の単語間のカンマ、ピリオドおよびスペースだけがギリシア文字フォントに変更されている。
最後に、上記のセンテンスにクーリェを適用すると、第17図に示す単語が得られる。図に示すように、ギリシア文字の単語間のカンマ、ピリオドおよびスペースはギリシア文字フォントに残っている。これは、これらの文字がギリシア文字フォントと同じフォントでスタイル化されたことを、プロセスが感知したためである。これらの例でもう１つ注目すべきことは、コロンはローマ文字テキストと同じフォントで常にスタイル化されるのに対し、他の句読点はそのフォント・スタイルに応じて異なった振舞をすることである。
次は、コンピュータ・ユーザに比較的親しみのある例である。上記のラインにフォントZapf Dingbatsを適用すると、プロセスはそのラインを変更しない。ラインはまだ第18図に示すようになっている。しかし、最近の商用化された従来システムを使用してZapf Dingbatsを適用すると、第19図に示すテキストが得られる。現在市販されている大部分のプロダクトを使用して上記センテンスにクーリェを適用すると、第20図に示すテキストが得られる。これは余り役立たない結果である。このセンテンスがヘブライ文字であれば、アップル・マッキントッシュ・コンピュータで従来の手法を用いると、結果は第21図に示すテキストのようになる。ギリシア文字の方が若干読みやすいが、多くのシステムではギリシア文字コードは、音声的に同等のローマ文字コードと同じ文字コードを共用することがあるので、まだガベージである。
本発明による上述した好適実施例は、一見すると、強い印象を受けないかもしれない。これは、正に、ユーザが望んでいる結果が得られるためである。驚くべきことは、非常に扱いにくいシステムにユーザが我慢していることである。これまでに説明してきたシステムと方法は、だれもが本発明に類似したものを従来のシステムで使用していない点で、文字通りユニークである。従来のシステムでは、正しく表示されるテキストを得るためにユーザに負担をかけている。タイプ・インした通りに表示されなくても、あるいはフォントを変更したとき、テキストが意図しない文字に変更されたときでも、ユーザはそれに我慢しなければならない。
コンピュータ・システムはますますグローバル化され、ローマ文字以外のマーケットを目標とすることに伴い、本発明はますます重要になる。ほとんどのメーカはグローバル・システムを作ることの構想を開始したばかりであるが、これはローマ文字ベースの言語だけをサポートすることを暗に意味している。非ローマ文字マーケットの影響力が増し、バイリンガルおよびマルチリンガル・ドキュメントが普及化するに伴い、コンピュータに対するユーザの要求はますます増加することになる。
以上、特定のシステム環境における好適実施例を参照して本発明を説明してきたが、本発明は、請求の範囲に明確化されている本発明の精神と範囲内で、変更を加えることにより、他の異なるハードウェアおよびソフトウェア環境で実施することが可能であることはもちろんである。

Claims (6)

1. 中央処理ユニット、オペレーティング・システムおよび複数のフォントスタイルを格納する格納装置、キーボード、および表示装置を具備するコンピュータで使用するテキスト表示システムであって、各フォントスタイルは、１組の文字コードの少なくともいくつかを絵文字にマッピングすることができ、前記キーボードから入力された各々の文字コードは、前記表示装置に表示される絵文字にマッピングされ、前記中央処理ユニットは、前記フォントスタイルの１つを、前記文字コードをマッピングするためのタイピングフォントスタイルとして選択するテキスト表示システムにおいて、
   前記オペレーティング・システムが前記中央処理ユニットで実行されると、
   文字コードのストリング中の挿入点で挿入されるべき入力文字コードを、前記キーボードから受信する第１手段、
   前記入力文字コードが現在使われている前記タイピングフォントスタイルにあるか否かを判定することにより、前記入力文字コードを絵文字にマッピングできるか否かを決定し、できる場合には、前記タイピングフォントスタイルを前記入力文字コードに割り当て、その絵文字を前記表示装置に表示する第２手段、
   前記判定により、前記入力文字コードを絵文字にマッピングできない場合には、前記ストリングの複数の文字コードから、前記挿入点より前の文字コードをテスト文字コードとして連続して選択する第３手段、
   前記選択されたテスト文字コードに割り当てられたフォントスタイルに応じて、前記入力文字コードが前記割り当てられたフォントスタイルにあるか否かを判定することにより、前記入力文字コードを絵文字にマッピングできるか否かを決定し、できる場合には、テスト文字コードの選択を終了し、前記割り当てられたフォントスタイルを前記入力文字コードに割り当て、その絵文字を前記表示装置に表示する第４手段、および
   前記入力文字コードを絵文字にマッピングする他のフォントスタイルが見つけられない場合には、あらかじめ決めた絵文字を前記表示装置に表示する第５手段
   として機能することを特徴とするシステム。
2. 前記第４手段は、前記選択されたテスト文字コードに割り当てられたフォントスタイルにより、前記入力文字コードを絵文字にマッピングする場合には、前記割り当てられたフォントスタイルを、引き続き入力文字コードに割り当てるタイピングフォントスタイルとして選択することを特徴とする請求項１に記載のシステム。
3. 前記第４手段は、
   前記挿入点より前の前記ストリングの全てのテスト文字コードが選択され、前記入力文字コードを絵文字にマッピングするフォントスタイルが見つからない場合には、前記ストリングの前記複数の文字コードから、前記挿入点より後のテスト文字コードを連続して新たに選択する手段と、
   前記新たに選択されたテスト文字コードに割り当てられた新たなフォントスタイルに応じて、前記入力文字コードが前記新たなフォントスタイルにあるか否かを判定することにより、前記入力文字コードを絵文字にマッピングできるか否かを決定し、できる場合には、テスト文字コードの選択を終了し、前記新たなフォントスタイルを前記入力文字コードに割り当て、その絵文字を前記表示装置に表示する手段と
   を含むことを特徴とする請求項２に記載のシステム。
4. 前記オペレーティング・システムが前記中央処理ユニットで実行されると、前記入力文字コードを絵文字にマッピングするフォントスタイルが見つけられた場合には、前記タイピングフォントスタイルを前記見つけられたフォントスタイルに設定する第６手段としてさらに機能することを特徴とする請求項３に記載のシステム。
5. 前記オペレーティング・システムが前記中央処理ユニットで実行されると、
   前記タイピングフォントスタイルから他のタイピングフォントスタイルへの変更に応じて、前記タイピングフォントスタイルを前記格納装置に格納する第７手段、および
   文字コードの組み合わせを前記ストリングに挿入される文字コードとして他の文字コードに置き換える文字変換手段であって、置き換えに応じて、前記文字変換手段は、前記置き換えられた文字コードの組み合わせより前の文字コードを検索し、その前の文字コードに割り当てられた前記フォントスタイルが、前記他のタイピングフォントスタイルと同じでない場合には、前記他のタイピングフォントスタイルを前記格納されたタイピングフォントスタイルに設定する第８手段
   としてさらに機能することを特徴とする請求項４に記載のシステム。
6. 前記オペレーティング・システムが前記中央処理ユニットで実行されると、
   前記ストリングの文字コードが、スペースまたは句読点を表す場合には、前記ストリングの前記スペースまたは句読点の文字コードに続く非スペース文字コードおよび非句読点文字コードを取得する第９手段、および
   前記非スペース文字コードおよび非句読点文字コードが前記スペースまたは句読点の文字コードに割り当てられた新しいフォントスタイルにあるか否かを判定することにより、前記非スペース文字コードおよび非句読点文字コードを絵文字にマッピングできるか否かを決定し、できる場合には、前記新しいフォントを使用して、前記スペースまたは句読点の文字コードを絵文字にマッピングする第１０手段
   としてさらに機能することを特徴とする請求項１に記載のシステム。

Images