- From: Atsushi Shimono (W3C Team) <atsushi@w3.org>
- Date: Mon, 11 Oct 2021 02:02:59 +0900
- To: public-i18n-japanese@w3.org
- Message-ID: <bcbcfaa5-3480-8dea-1c36-dd53e3fab936@w3.org>
shimonoです On 2021/10/11 01:35, Koji Ishii wrote: > フィードバックありがとうございます。 > > おそらく、次期文書をどうやって形成していくかという共通理解を先に作れ、というご指摘だとは思ったりもするのですが > > > 少し補足させてください。前のメールで言おうとしたことは、JLREQ/JDLREQでの用語議論と、OpenType実装上の用語議論は分離してよいのではないか、ということです。 > > この文書は、OpenTypeのフォント開発者と、OpenTypeを使ったアプリケーション開発者に向けた限定的なものであるため、実現したい組版結果に必要なフォントの情報を、最終的に字送りに落とし込むことが必要です。 ここのターゲット論は基本的には同意します。 > 一方で、JLREQはもちろんそうなっていますが、次期版JDLREQも、もっと広い観点で語られるべき仕様だと考えています。OpenTypeの現行仕様の制限事項を持って、現行JLREQを書き直したり、次期版JDLREQに影響を与える、という事態は避けるべきだという点では合意があるものと考えています。どちらかと言えば、必要なことをやるために、必用な部分があればOpenTypeの仕様を変える提案もしていきましょう、という方向性ですよね。 > > なので、二つの用語議論を分離して、JLREQ/JDLREQでは実現したい組版を定義する。それをOpenTypeに実装する上で必要な細かい取り決めは、約物文書で理解してもらう、という役割分担でいいのではないでしょうか、という趣旨です。 が、、先のメールを書いてからも、いろいろうんうん考えていたところではあるんですが、視点というスコー プ限定を行う文脈で、ある一つの概念の定義をターゲットになる領域ごとに用語として変えるというのはやって はいけないのではないか、（最近の流行りで言うとドメイン限定用語でしょうか？）というのは一つ提示したい ところです。ドメイン限定の定義とかは我々はよくやりがちではあって、しかもそういうのがほんとうに便利で はあるんですが、それって統一的な何かの提示という方向にはつながらなくて、将来への禍根を残すだけなので はないかとここ10年くらい思ってたりしてはします。。（ここには居ないですが、、桃井さんとかは同意してく れないかな、、）アキ、にしても、送り、にしても、活版組版での何か入れて調節にしても、本質的にはリズム なり全体の調整なりからくる何かしらのものがあったんだろうな、と。。。。 国際化という概念がひろまったいまこそ、ハレーションをいろいろ起こすとは思いますが、日本語としての概 念での定義、活字活版と手動写植からくるもろもろをきちんと正しく出していくというところにJL-TFの価値の一 つがあるんではないでしょうか。。。（識者のみなさまからすると、青二才が何を言うか、という話ではあろう かとは思いますが。。。。） > On Sun, Oct 10, 2021 at 11:22 PM Atsushi Shimono (W3C Team) <atsushi@w3.org <mailto:atsushi@w3.org>> wrote: > > shimonoです > > 根本なところではあるんですが、ちょっとなんか混乱してきたので確認させてください。 > > いま、幾つかの小さめの個別トピックについての文章をまとめようとしています。個人的には、これらは全 > てきたる次のJLReq（の3rdなのか新しい文書なのかどうかは置いて）の新しい文書のビルディングブロックと > して議論をいろいろしながら熟成させないといけない、かつ、ある程度ブロックとしてまとめやすいところを > 小文書としてまとめているという認識でした。 > というところで、約物などが使う（持つ、という表現をあえて避けて）スペーシングというのを約物の要件 > に限らず、日本語組版の中でどうやって汎用的に表現するか、というのは、ルビの親文字の両側とか、プロ > ポーショナルを考えたときの拡張をどうするかなどについても、いろいろ話を広げて用語定義をしないといけ > なくて、その中で何か統一的に表現できる何か、を模索しているのかなという側面も思っていたところでした。 > > というところで、「約物要件案」という小文書が、来るJLReqか何かの内包される（下位推奨）事項である、 > というのは当然だとは思っていたのですが、用語については必要十分なものを全体で定義することを模索して > いるのかな、とも考えていたところでした。 > > おそらく、次期文書をどうやって形成していくかという共通理解を先に作れ、というご指摘だとは思ったり > もするのですが、そういう方向の議論の中で共通理解・方向性を考えていく、というのはいかがでしょうか？ > とちょっと思いました。 > > > > # なんか政治家チックな発言になってしまって微妙なところではありますが・・・＞＜ > > > On 2021/10/10 21:02, Koji Ishii wrote: > > コメント、ありがとうございます。敏先生の主題からは少しずれてしまうかもしれませんが、約物要件案の位置づけが不明瞭なために議論を難しくしている部分があるのではないかと思い、論点を二つに分けてみたいと思います。 > > > > 1. JLREQ/JDLREQにおいての 「送りかアキか」という議論。これは 「送りかアキか」というスレッドを敏先生が始めてくださったので、そちらで議論できるかと思います。 > > 2. 約物要件案はJLREQ/JDLREQに対してどういう位置づけで、用語を揃えるべきか、という議論。 > > > > 私の意図としては、約物要件案はJLREQ/JDLREQの下位にあって、JLREQ/JDLREQが定める組版結果を実装するためには、OpenTypeと組版アプリケーションでこういう分担をし、こういう相互取り決めをすればいいのではないか、という推奨案として位置付けています。 > > > > このため、JLREQ/JDLREQの用語に影響は受けても、約物要件案の用語をJLREQ/JDLREQで使ったり、JLREQ/JDLREQが影響を受けたり、ということはあまり想定していません。 > > > > フォント製作者、および組版アプリケーション製作者の観点から考えると > > > > * 組版アプリケーションは、通常字送りもアキも作ることができる。 > > * OpenTypeには、仕様上「アキ」の概念はない。「アキ」は字送りを大きくすることで実装する。 > > > > このため、JLREQ/JDLREQがいずれの概念で構成されていたとしても、約物要件案には「字送り」の説明が必要になると思っています。JLREQ/JDLREQにおけるアキを > > > > 1. 組版アプリケーション製作者がアキを作ることで実装する > > 2. フォント製作者が字送りに入れることで実装する > > > > と二つのオプションがあった時に、二者の間の対話を容易にすることができるかと思います。 > > > > ということで、話を少し戻すと > > > > * 約物要件案の位置づけが明確ではない。JLREQ/JDLREQの下位推奨事項であることを明記すべき。 > > * タイトルが誤解をしやすくしている。 安直に 似たタイトルをつけたのが失敗だったと思います。 > > > > 「はじめに」にこれを追加して、タイトルを変えるべきではないかと思い始めています。 > > > > 「OpenTypeにおける約物の推奨事項」とかいかがでしょう？ Recommendations for OpenType Fonts <https://docs.microsoft.com/en-us/typography/opentype/spec/recom <https://docs.microsoft.com/en-us/typography/opentype/spec/recom>>がOpenType仕様書のAppendixにありますが、こんなイメージです。 > > > > > > On Wed, Oct 6, 2021 at 11:53 AM Kobayashi Toshi <binn@k.email.ne.jp <mailto:binn@k.email.ne.jp> <mailto:binn@k.email.ne.jp <mailto:binn@k.email.ne.jp>>> wrote: > > > > 石井 様 > > > > 小林 敏 です． > > > > ご参考までに，日本語約物の要件の“送り”という用語について，いくつか案を考えてみました． > > > > A案：現在のまま． > > “送り”とい用語が定義されていないので，意味がややあいまい． > > > > Ｂ案：“送り”という用語を定義する． > > 結構面倒であり，また，JLReqとの整合性がなくなる． > > > > C案：JLReqの用語を用いて説明し，JLReqへの参照を付ける． > > たぶん，多くの人はJLReqを参照しない可能性があり，石井さんの心配するように意味を互解する人が出る可能性がある． > > > > D案：説明を簡単というか，以下のようにする． > > 括弧や句読点など，約物等（全角空白があるので等を付ける）が連続した場合，アキ（空白といってもよい）を調整しないといけないケースがある（詳細はJLReqを参照）．以下では，この調整を行う（“する”でもよい）処理を“約物等の連続時の調整を行う処理”，この調整処理を行わない場合を“約物等の連続時の調整を行わない（“しない”でもよい）処理”という． > > D案の欠点は，どう処理するか不明である，ということと，説明の用語が長い．であるが，前者は，調整した例と調整しない例を示せばよい．例を示せば，ほぼわかる（わからなければJLReqを参照すればよい）． > > > > このドキュメントは，約物の字間の調整をどう行うかの説明は，あくまで前提であり，くわしく説明する必要はないので，Ｄ案のような形式でもいいように思います．Ｄ案では，全角，半角，ベタという用語は使用しません． > > >
Received on Sunday, 10 October 2021 17:03:05 UTC