- From: Koji Ishii <kojii@chromium.org>
- Date: Wed, 24 Apr 2024 17:45:35 +0900
- To: Kobayashi Toshi <binn@k.email.ne.jp>
- Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-ID: <CAHe_1d+oFMr03PUwWMCxWgScYB+YCfxnU7rTPfO4egAS0_M17w@mail.gmail.com>
なるほど、やはり誤解してました、ありがとうございます。山本さんのご趣旨は、フォントのグリフが全角かどうかで判断したい、ということかと誤解しました、すみません。 ゴール、と書いたのは、もう一つ、別の側面として、これは理想とされる組版規則を議論しているのか、Unicodeにおける仕様化を議論しているのか、という点です。Unicodeにおける仕様化においては、 現文書 <https://github.com/kojiishi/unicode-auto-spacing/blob/main/auto-spacing.md>の「1 Overview and Scope」をご参照いただきたいのですが(英語ですみません、翻訳ツールをお使いください)、端的に言えば「合理的で突飛ではないデフォルト値」がゴールであり、「印刷レベルの品質」や「どのようなスタイルやコンテキストでも正しい」ことはゴールにしていません。 これは、現在の制作者の問題を解決することを念頭に置いています。Appleプラットフォームが和欧アキをOSに実装したことで、Appleプラットフォーム向けの文書と、例えば Microsoftのスタイルガイド <https://download.microsoft.com/download/a/8/2/a822a118-18d4-4429-b857-1b65ab388315/jpn-jpn-StyleGuide.pdf> に沿った文書では、和欧間にスペースを入れるかどうかを、制作者がプラットフォームに合わせて原稿を変更しないといけない状況になっています。アプリを移植する場合にも、日本語版・中国語版においてのみ、スペースの追加・削除をして、OSに合わせないといけません。この先、例えばCSSとLinuxとAndroidとWindowsがそれぞれ別の仕様を採択していくことで制作者の負担が増えていくことは避けたい、というのが主眼になります。 これは、UAX#50の縦書き文字向きと同じようなものとお考えいただけるとわかりやすいかと思います。UAX#50の普及においては数十年単位の時間がかかると思っているので、現段階でなかなかそのメリットを実感しにくい場面も多いとは思いますが、制作者が、意図する向きとUAX#50の値が異なる場合にはマークアップを入れよう、ということと同様に、一つの基準があることで、制作者に対して、どこにThin Spaceを入れるか、どこにASCII Spaceを入れるか、あるいは入れないかの基準となることをゴールにしています。実装の普及後30年以上経ってから標準化されたUAX#50と比べて、和欧アキは、現段階で標準化ができれば、UAX#50ほどは普及に時間がかからないと思っています。 このメリットを享受するためには、Unicodeで定義せざるを得ないので、Unicodeからの制限事項もあります。Unicodeでは現在、200を超えるプロパティを定義していて、新しい文字を追加するたびに、すべての新しい文字に対してこれらのすべてのプロパティを決める、という作業を毎年メンバーが行っています。この負担がメリットを上回ればUnicodeとして定義することが難しくなってしまうため、負担を軽減するため、新しいプロパティは、既存のプロパティの組み合わせで計算できることが望ましいとされています。 もちろん、既存文字に対していくつかの例外は設けており、また新しい文字に対しても例外が出てくる可能性はあるとは思いますが、原則としては、既存のプロパティの組み合わせでできる範囲において、多くの場面で問題がないデフォルト値であり、文書の制作者が自分のOSで校正して必要な場所に修正を入れれば、別のOSでも同じ結果が得られるようになる世界が十年後にできることが、Unicodeのゴールになります。 JLREQとしては、フォントや他の情報も用いてより高精度で賢いロジックを議論していくのも、ゴールの一つだと理解してます。そういったことも、基準が一つあれば、基準との差分を計算するプログラムを作ることも可能になると思いますし、Unicodeより上のレイヤのOpenTypeやCSSではマークアップなども可能なので、より高度なロジックを組み込めるかもしれません。また、WordやInDesignなどのアプリのレベルではさらにより高度な自動校正ができるかもしれません。 高品質の結果を目指すJLREQのゴールとは別に、Unicodeのゴールに対してJLTFとしてどういう意見を出していくか、という点を考慮に入れていただけると幸いです。 On Tue, Apr 23, 2024 at 12:35 PM Kobayashi Toshi <binn@k.email.ne.jp> wrote: > Koji Ishii 様 > > 小林 敏 です. > > 私の考えは,石井さんのご指摘の通りです. > > > 山本さんの考えも,それほど違いがないが,きちんと対応するのなら,ラテン文字の記号・約物を一括するのではなく,文字クラスを分けないと対応できない,ということです. > > 具体的な主な問題は,以下です. > > 1.主にラテン文字の括弧類は,和文中に使うケースはあるを前提にするか,それとも,それは,望ましい使い方でないから無視してよいか. > →無視しないのなら,ベタにしたい. > →無視してよいならラテン文字と仮名・漢字はベタでなくてよいが,2の問題との関係だけで考えればよい. > > 2.ラテン文字と仮名・漢字が並ぶケースは,分けると,以下の2つがある. > > 2.1 アキをとりたいケース > 例: > 都市vs.農村 > 経済学者のP. A.サムエルソンは,…… > アルフレッドT.マハンは,…… > 所有格を示す場合ladies'のように-sで終わる…… > を表すI quickly finished my lunch.とI finished my lunch quickly.と副詞で…… > > 2.2 アキをとりたいくないケース > 例:合印にラテン文字を使う である*.…… 組版*は…… > > ですから,ベタにしたいラテン文字の記号類とベタにしたくない記号類と,分けられそうであるので,きちんと対応するなら山本さんのいうように分ける. > > > そこまでする必要はないので,問題のケースは,何か工夫できないか,そうであれば分けなくてよい.その場合,2.1のケースは,そう多くないし,特に人名の省略符は,別の処理方法もあるので,一律にラテン文字の記号類と仮名・漢字の字間はベタでよいとする. > > さて,どうしましょうか? ということです. > > Koji Ishii さんwrote > > >議論を見ていて、敏先生・木田さんと、山本さんの間に、目指しているゴールに違い > >があるように思えるのですが、いかがでしょう? > > > >私の理解がずれていたら申し訳ないのですが、私見では > > > > - 敏先生・木田さんは、組版的には間違った用法も含めて、より問題の少ない方法 > >を模索している > > - 山本さんは、使われているフォントを元にして校閲する際に、望ましい結果を作 > >るための調整を入れやすい方法を模索している > > > >ように見られました。 > > > >ずれていたら申し訳ないのですが、何を目指しているのか、という点を再確認できま > >すでしょうか? > >
Received on Wednesday, 24 April 2024 08:45:52 UTC