- From: 木田泰夫 <kida@mac.com>
- Date: Thu, 1 Feb 2024 15:27:15 +0900
- To: Yamamoto Taro <tyamamot@adobe.com>
- Cc: Tatsuo KOBAYASHI <tlk@kobysh.com>, JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-Id: <96A84DF2-8680-47F8-93B6-E730C127D16E@mac.com>
山本さん、ありがとうございます。でも、な、長い :D chatGTP さんに要約して、と頼みましたら、下のような文書にまとめてくれました。 > 山本太郎さんは、「手で書くこととデジタルに書くことの違い」という小林さんの文書に対して異なる意見を持っています。小林さんの文書では、手書きの文字とデジタルデータの符号化された文字列には「共約不可能な相違」があるとされています。山本さんはこの点に疑問を持ち、手書き文書の時代、活版印刷・電算写植・邦文光学写植の時代、電子文書・DTP・Webの時代の書記方法の違いを検討しました。 > > 山本さんの考えでは、同形異字や類形異字の問題は、デジタル時代以前から存在していたと指摘します。電子文書の時代においても、この問題は過去の手書き文書や活版印刷の時代と比較して「共約不可能な相違」があるわけではないと主張します。むしろ、デジタル技術の普及により書き手がテクストの入力から最終的な印刷や表示までを管理する必要が生じたため、同形異字・類形異字に関するエラーが見過ごされやすくなったと述べています。 > > また、山本さんは、デジタルフォントや文字コードの誤認問題についても考察し、現代の電子文書におけるこれらの問題は、デジタル技術固有の制約によるものではなく、人間やOCRの誤認によるものであると主張します。そして、伝統的な書記技術とデジタルによる書記技術には「共約不可能な相違」がないと結論付け、デジタルコンピュータが伝統的な書記技術の役割を自然に果たしていると述べています。 私も、そんなゴツい相違があるとは感じていません。結局のところ、両方とも同じモノ、つまり書かれたテキストを達成する手段であって、山本さんの言葉を使うと、同じ役割、を果たしていますし、共通の問題もまた存在しています。 もちろん、その「手段自体」は根本的に違う。なので問題の現れ方に独特な部分がある。 馬車と自動車のメタファが使えますね。 > 同形異字・類形異字の問題を、書き手が意識することの重要性は、電子文書が用いられる時代以前から存在していました。 これを考えると、デジタルで書くということは、書き手の責任が大きいという意味においては、手書きのモデルへの回帰なのかもしれない、と思いました。 印刷のモデルは、印刷機械という設備費用の問題からもっぱらマスが対象(なのでその時代でも私信は手書き)であり、そこには書き手が書いたものを「解釈され選ばれた文字の列」に変換する機構があります。「第」を「㐧」と書いてあってもその略字は一般的には最終の原稿に反映されることはないでしょう。書き手が無意識に同じように書いた長音記号やダッシュ類は、それぞれコンテキストに適切な文字に置き換えられて表現されるでしょう。 しかるに手書きやデジタルでは、書き手が間違えたら、間違ったものがそのまま伝わります。 > 編集ソフトウェアなどで、それらを表示上区別するなどの工夫によって、入力・校正段階での誤認を防ぐことは可能と考えられます。 私は視覚に頼るアプローチは限られたニッチを除いてはうまくゆかないと思います。このメールのように、私たちが日々書くツールにそのような表示上の工夫が好まれるかどうかというと大変に怪しいからです。 ソフトウェアによってはスペース文字の種別を明に表示する機構があるものも存在しますが、その仕組みは技術的にはごく容易なのに、その機能がどこにでもあるかというとそうではない。0ゼロとOオーを視覚的に区別する工夫として、等幅書体にあるようにゼロの真ん中に斜め線を引くことがありますが、そうなっているのは特殊なフォントのみ。一般的なユーザーにとってみれば、ウルサイUIになるくらいなら、文字列が間違っていても良いのです。多くの人にとってその程度の問題なのです。 もちろん、精密な文字の選択が重要でそのことに時間を使うべきユーザーにとっては、一文字一文字視認できるツール・機能が有用であると思います。 より一般的なユーザーにとっては、そもそも、表示してくれたからって、数多あるダッシュ類を、空白類を、また柿と杮の違いを、正しく選べる・選びたいかというと、そんなことないわけです。ゆえ、私はより広い解決策として、もっと透明で自動的なアプローチを期待します。「書き手が間違えたら、間違ったものがそのまま伝わります」ではない伝わり方。印刷の時代の校正・編集のような存在を取り戻す方向。 また同時に、文字列を利用する機能側ももっと賢く、文字列に間違いはないとの前提を捨てて、例えば検索なら間違いを許容するような検索ができるようになるべきでしょう。 木田 > 2024/02/01 13:26、Taro Yamamoto <tyamamot@adobe.com>のメール: > > 小林さんが書かれた『手で書くこととデジタルに書くことの違い』(以下では「当該文書」と呼ぶ)で、下記のように結論付けられている点について、私の考え方は異なるため、私の考えを以下に記します。 > > 「紙葉に手で書かれる文字情報が、視覚的イメージデータであり、さまざまな手段で蓄蔵され、伝搬されるデジタルデータが、符号化された文字の列である、という違いは、一般に認識される/認識されない以上に大きい。一口に書記技術といっても、伝統的な視覚表現を媒介とする伝統的な書記技術と、符号化文字列を媒介とする書記技術とでは、まさに共約不可能(incommensurable)な相違がある。」(当該文書より引用) > > 私の疑問は、もし本当に「共約不可能(incommensurable)な相違がある」のであれば、伝統的な視覚表現を媒体とする技術を用いたコミュニケーションは、符号化文字列を媒介とする表現技術によっては代替不可能になって、そもそもコミュニケーション技術の移行が不可能になっていたはずではないいか、ということにあります。 > > このことを説明するために、ここでは、先ず(1)手書き文書の時代、(2)活版印刷・電算写植・邦文光学写植の時代、(3)電子文書・DTP・Webの時代に分けて、文書の書記方法の違いについて考えてみました。それを下記の表に記します。 > > 手書き文書の時代 > 活版印刷・電算写植・邦文光学写植の時代 > 電子文書・DTP・Webの時代 > 書き手の作業 > 書き手の作業 > 書き手の作業 > 伝達すべき内容(意味)を考える。 > その内容(意味)を文字の列として書こうとする(この文字を書こうとする行為には、具体的には、字形/グリフイメージを描くということと、字形/グリフイメージを目で見て確認する行為が含まれる。実際に可視化され物理的に定着されるのは、文字ではなく字形/グリフイメージである)。その字形/グリフイメージとして実現された視覚的表現が原稿となるが、編纂者・編集者、マーケティング担当者、コピーライター、家臣、家来、執事、秘書などの手によってチェックされ修正される場合がある。あるいは、原稿が即最終結果となる場合もある。 > 書き手は、能書家・代筆業者など他者に実際に書く行為を委託する場合がある。この最終結果が紙の上に書かれた文書となる。 > 伝達すべき内容(意味)を考える。 > その内容(意味)を文字の列として書こうとする(この文字を書こうとする行為には、具体的には、字形/グリフイメージを描くということと、字形/グリフイメージを目で見て確認する行為が含まれる。実際に可視化され物理的に定着されるのは、文字ではなく字形/グリフイメージである)。中間的な結果として原稿ができる。 > 原稿は、編纂者・編集者、マーケティング担当者、コピーライターなどによって修正される場合がある。 > 伝達すべき内容(意味)を考える。 > その内容(意味)を文字の列として、それぞれの文字に対応するコードを入力する(この文字を入力する過程には、仮名漢字変換ソフトウェアが介在する場合、しない場合があるが、表示される字形/グリフイメージを目で見て、伝達すべき内容(意味)を表現する文字と対応しているかを確認する行為が含まれる)。入力作業の結果は、符号化された文字コードの列で構成されるデジタルデータとなる。 > デジタルデータは、編纂者・編集者・校正者などの手によってチェックされ修正される場合がある。 > > 採字・入力・印字・組版・レイアウト工程 > 採字・入力・印字・組版・レイアウト工程 > > 活版印刷の時代には、文選と植字(以後の組版製作を含む)とに分業化され、電算写植の場合には、採字・入力とコーディング/組版とレイアウト/版下制作が分業化され、邦文手動写植の場合には、採字と植字とは分業化されないが、その後のレイアウト/版下制作とは分業化される。活版の場合、印刷以前の段階での中間的な結果は組版である。電算写植と邦文手動写植の場合、印画紙が貼り込んだ版下またはそれと同等の画像を感光させたフィルムが中間的な結果となる。活版では、活字組版を用いて印刷を行うかその複製のステロタイプで印刷を行う。電算写植の場合には版下から写真製版の過程を経て普通は平版印刷用の版を作成し、それを用いて印刷を行う。 > 手書きの原稿を基にしながらも、活字組版あるいは邦文手動写植の工程を経た後、手書きの文書の場合とは異なり、フォントを用いるため、定型化されたグリフイメージが用いられるが、グリフイメージが常に物理的・視覚的に存在しているという意味では、手書きの場合と変わりがない。電算写植では、採字・入力段階で原稿中のグリフイメージは(グリフに対応する)コードとしてデジタルデータに変換される。 > 初期の段階では原稿用紙、中間的な段階では印画紙やレーザープリンターによる印字物、より後段では校正機で印刷した校正刷りなどを用いて校正が行われ、内容が修正される場合がある。紙の上に印刷された文書が最終結果となる。 > デジタルデータには指定や説明などを含むメタ情報が附属する場合がある。その場合、書き手自身が異体字グリフの指定や、同形異字・類形異字についての注釈などを加える場合もある。印字・組版・レイアウトをすべて書き手自身がツールを用いたりコーディングをして行う場合もある。編集者・校正者・デザイナーが同様の指定を行う場合もある。 > DTPやWebでは、書き手自身が最終的な印刷・出版を担うことを可能にし、分業を不要にして、書き手自身による最終文書の品質の管理を可能にした。このことは一方では、出版を民主化し、文字によるコミュニケーションの機会を広汎な人々に提供したが、専門の校正者による組織的な校正の過程が省略されることが誤植の発生頻度を高くしたとも言える。 > 最終的な形が印刷物の場合に、デジタルデータは、レイアウト作業の後、平版印刷の製版の原稿用のフィルムに印字・出力される。直接コンピュータから製版または印刷までを直接行う方法もある。 > 最終的な形が印刷物でない場合、特にWebにおいては、書き手自身あるいはデザイナーまたはエンジニアがツールを用いたり、CSSやHTMLをコーディングすることでレイアウトを行う。 > デジタルデータの校正は、書き手だけでなく、編纂者・編集者および上記のWebページ作成者によって行われる場合がある。 > 読み手の作業 > 読み手の作業 > 読み手の作業 > 文書に書かれた字形/グリフイメージを見る(知覚する)。字形/グリフイメージから文字を読み取る(文字を認識する)。読み取った文字列から内容を理解する(読解する)。 > 文書に印刷されたグリフイメージを見る(知覚する)。グリフイメージから文字を読み取る(文字を認識する)。読み取った文字列から内容を理解する(読解する)。 > 電子文書に表示・印刷されたグリフイメージを見る(知覚する)。グリフイメージから文字を読み取る(文字を認識する)。読み取った文字列から内容を理解する(読解する)。 > > その上で、当該文書の中で「共約不可能(incommensurable)な相違」から生じる問題とされている以下の点について考えます。 > > 1. 「これら、視覚的な類似性ゆえに、意味的に異なる(文字名が異なる)文字や記号を、デジタルな文字情報に用いることは、排列や検索から、アクセシビリティ(音声によるデジタル情報の読み上げ)に至るまで、多くの混乱の元となる。」(当該文書より引用) > > 2. 「どのような媒体、通信経路を前提とした場合でも、デジタルによる文字方法の入力の際には、そこで蓄蔵される情報が、符号化文字の列であることを意識しておくことが、重要である。」(当該文書より引用) > > しかし、ここで「重要である」とされていることは、電子文書を作成し利用する現代だけに固有の、あるいは現代を特徴づける事柄でしょうか。手書き文書の時代でも、「柿」と「杮」などの同形異字・類形異字は混乱のもとだったはずです。また漢字を簡略化した字体を『当用漢字』や『常用漢字』という形で権威付けしてしまった結果、「芸」を「げい」の文字として使う頻度が増し、「うん」の文字との同形異字を普及させてしまいました。これらは、デジタル計算機が普及するはるか以前のことでした。つまり、同形異字・類形異字の問題を、書き手が意識することの重要性は、電子文書が用いられる時代以前から存在していました。 > > では電子文書の時代において、この同形異字・類形異字の問題は、過去の手書き文書や活版印刷の時代の同種の問題とは、「共約不可能(incommensurable)な」ほどに「相違」しているのでしょうか。 > > たしかに、電子文書と過去の技術を用いた文書との違いは、手書き文書や活版印刷においては、書き手が書いたグリフイメージが常に物理的・視覚的に存在しているが、今日の電子文書(DTPやWebを含む)では、書き手が考える文字は、それに対応する符号化された文字コードの列にすぐに変換されて、印刷・表示されるまではグリフイメージとして表現されない、ことにあります。 > > そして、同形異字・類形異字が問題となるのは、間違った文字コードが選択されてしまう場合です。これは文字コードに依存する情報処理においては、深刻な問題を生む可能性がありますが、その原因となる問題自体は、電子文書に固有の問題ではありません。 > > とはいえ、DTPやWebの普及によって、書き手がテクストの入力から最終的な印刷や表示の段階までを管理する必要が生じたため、同形異字・類形異字に関するエラーを見過ごしてしまう頻度が多くなった、ということはあり得ます。しかし、この問題の原因が、人間が同形異字・類形異字を誤認する、あるいはOCRのようなプログラムが同形異字・類形異字を誤認することにあるのですから、前者の場合にはそれは電子文書に限定されるものでなく、また後者の場合でも、その誤認の原因は文字が電子化・デジタル化されていることにあるのではなく、あくまで元々のグリフの形状が同じであるか類似していることによるものです。 > > しかし、もし電子文書の時代には、同形異字・類形異字の誤認を回避する、あるいはその発生を低減する方法がなくなってしまったのであれば、それは、過去の技術の時代との深刻で大きな差異であると言えるかもしれません。しかし、私は現代において誤認の回避方法が存在しなくなったのではなく、そのような方法が、まだ広く普及していないのではないかと考えます。この点を説明するために、次に具体的な問題について考えてみます。 > > 当該文書に例示されている具体的な同形異字・類形異字の問題の内、平仮名の「へ」、「り」と片仮名の「ヘ」、「リ」をOCRが誤認する問題以外は、すべて記号類の問題です。おそらく、漢字の同形異字・類形異字の問題は発生頻度が少ないために、採り上げられていないのだと推測します。 > > 形が同じまたは類似した記号類どうしがなぜ誤認されるのかと言えば、それは単純に最終的なグリフイメージの形が同じか類似しているために、人間やOCRが誤認するからです。ではなぜ誤認するような状況を避けられないのでしょうか。 > > 私は、その理由は、デジタルフォントを用いて、文字コード→グリフ→グリフイメージに変換するという、印刷・表示と同じプロセスに依存して文字の入力・校正を行っているからだと考えます。グリフの形以外の情報が欠落しているので、形が同じあるいは類似していれば誤認・混同しやすくなるのは当然であり、それは人間もOCRも同じです。 > > 先の時代別の表の中で、「電算写植の場合には、採字・入力の段階で、原稿に書かれたグリフイメージは(グリフに対応する)コードとしてデジタルデータに変換される」と書きましたが、電算写植での採字・入力の場合、例えば、Linotypeの場合であれば、各種の幅の固定スペース(行末で吸収される空白文字)やダミー文字(行末で吸収されない空白文字)は、採字・入力・校正の段階では、編集機上での表示・印刷には、特別の表示マークのグリフが用いられました。例えば固定スペースの場合、それらのグリフには、字幅等の属性を示すEMとかENとかが説明的に表記されていたため、それらの記号についてのメタ情報として機能していて、最終的に表示・印刷されるべきグリフ/グリフイメージが他のグリフ/グリフイメージと同じであったり類似しているからといって、採字・入力・校正段階で混同することはありえなかったのです。 > > 現在の電子文書のテクストの入力・作成において、同形あるいは類形の記号類の混同が生じ易いのは、最終的に出力・表示されるべきグリフイメージと同じものを見て入力・校正しているからであって、電子文書に固有の制約が原因ではありません。 > > 電算写植の場合には、普通はグリフに対してコードが割り振られていました。そのためグリフの識別とコードの識別との対応は自明でした。現代の電子文書における文字コードの場合でも、「ギュメ」と「不等号」や「音引き」と「~」のような記号の場合には、それらに対応付けられたグリフが類似していたとしても、類似グリフが同一のコードポイントに包摂されてしまった統合漢字の場合とは異なり、異なるコードポイントとが割り当てられているのですから、識別することは容易です。編集ソフトウェアなどで、それらを表示上区別するなどの工夫によって、入力・校正段階での誤認を防ぐことは可能と考えられます。 > > このように考えると、「伝統的な視覚表現を媒介とする伝統的な書記技術と、符号化文字列を媒介とする書記技術とでは、まさに共約不可能(incommensurable)な相違がある」と考えることは無理だと考えます。むしろ、現代の書記技術もまた、デジタルコンピュータが暗算やソロバンが果たした役割を今日でも十全に果たしているように、伝統的な書記技術が果たすべき同じ役割を自然に果たしていることが理解できるはずです。そこに見いだされるのは、新旧の技術間の断絶ではなく、むしろあらゆる情報をビットの組み合わせで表現することの一般性と有効性であると考えます。 > > 以上、私見まで。 > > 山本太郎
Received on Thursday, 1 February 2024 06:27:39 UTC