Re: 約物要件案の位置づけ (was Re: 日本語約物の要件の“送り”という用語

返事が遅くてすみません、いろいろフィードバックをありがとうございます。

「字送りと字間アキの用語について
<https://docs.google.com/document/d/12xbvcy1_x2GTvln7nKhA0NEVke63uDpDasGCYbDxhu4/edit#bookmark=id.eymu7bh6at79>
」という章を「はじめに」の中に追加しました。

欧文でも両方の概念が存在します。例えば、letter-spacingは「字間のアキ」を表現し、アプリケーションでは「アキ」の値として設定されますが、OpenTypeにはアキがないため、アプリケーションが処理、あるいは字送りに変換して実行します。とはいえ、OpenTypeにアキがないから、ユーザーに字送りで設定させよう、ということにはならないですよね。

Natさんの言われたように、上位（仕様やアプリケーション）では両方存在し、状況によってどちらを使うべきかは異なります。ただ、OpenTypeの作り方を考える上では、字送りで考える必要がある、という分類でいいのではないかと思っています。そういう趣旨で上の章を追加してみました。

On Mon, Oct 11, 2021 at 1:22 PM Yasuo Kida <kida@mac.com> wrote:

> ナットさん、とってもわかりやすい説明ありがとうございました。
>
>
> なんとなく、「アキ」と「送り」は一つのことの二つの違った説明の仕方、くらいにしか理解していませんでした。が、日本語組版を、欧米の組版を基礎とする組版エンジンを用いて実装する場面において、「アキ」は日本語の組みを作るための概念で、「送り」はそれを実現するための実装方法、と考えるとスッキリしますね。
>
>
> この捉え方が当を得ているなら、概念的な説明やフォントの観点での説明は「アキ」で行って、エンジンの実装者の議論では送りに変換すればスッキリするかもしれません。また、この関係をきちんと説明しておく。そもそもこの文章は、理論を実装につなぐところにあるので、その両方の用語に触れるのを避けられない位置にいるのかもしれません。
>
> 欧文組版から来た人は、「アキ」の概念は理解しにくい可能性はありますか？ とすると、JDLReq 含めどこかに「アキ」の説明が必要ですね。
>
> 木田
>
> 2021/10/11 2:09、Nat McCully <nmccully@adobe.com>のメール:
>
> 横から、英語で、失礼いたします。
>
> I think it is a balance of both approaches. Consider that when composing
> runs of differing sizes, the aki is supposed to scale with the character it
> belongs to, so it is important for the engine to make the translation from
> the user-centric concept of “owned” aki to the implementation detail of
> achieving it with font features and glyph placement. Describing the
> requirements only in terms of the reductionistic OpenType approach will
> result in limited implementations and perhaps lose some of the nuance.
>
> Engines must achieve “owned” aki by moving glyphs’ origins, and also
> introducing the concept of cursor boundaries that are independent of glyph
> origins. It is the cursor boundaries that the user sees when selecting
> glyphs and seeing the aki that “belongs” to them.
>
> Whether or not one thinks of aki as independent spacing or simply an
> adjustment to the glyph left or right side bearings, and whether one thinks
> of punctuation as having aki built-in or that for them you must reduce
> width where everywhere else you introduce spacing, these concepts are
> important to preserve in the UX, even though underneath at the lowest level
> glyphs are placed by moving their origins and that is it.
>
> I do not want us to lose this role of the engine supporting these
> user-centric concepts of how aki works so a kumihan operator can use the
> same conventions they always have (from phototypesetting or CTS or even
> metal) without having to learn too much about OpenType and other details of
> the digital machinery underneath that shoehorns CJK concepts into a Latin
> model.
>
> --Nat
>
>
> *From: *Koji Ishii <kojii@chromium.org>
> *Date: *Sunday, October 10, 2021 at 9:35 AM
> *To: *Atsushi Shimono (W3C Team) <atsushi@w3.org>
> *Cc: *W3C JLReq TF <public-i18n-japanese@w3.org>
> *Subject: *Re: 約物要件案の位置づけ (was Re: 日本語約物の要件の“送り”という用語
> フィードバックありがとうございます。
>
>
> おそらく、次期文書をどうやって形成していくかという共通理解を先に作れ、というご指摘だとは思ったりもするのですが
>
>
> 少し補足させてください。前のメールで言おうとしたことは、JLREQ/JDLREQでの用語議論と、OpenType実
> 装上の用語議論は分離してよいのではないか、ということです。
>
> この文書は、OpenTypeのフォント開発者と、OpenTypeを使ったアプリケーション開発者に向けた限定的なものであるため、実
> 現したい組版結果に必要なフォントの情報を、最終的に字送りに落とし込むことが必要です。
>
> 一方で、JLREQはもちろんそうなっていますが、次期版JDLREQも、もっと広い観点で語られるべき仕様だと考えています。OpenTypeの現行仕様
> の制限事項を持って、現行JLREQを書き直したり、次期版JDLREQに影響を与
> える、という事態は避けるべきだという点では合意があるものと考えています。どちらかと言えば、必要なことをやるために、必用な部分があればOpenType
> の仕様を変える提案もしていきましょう、という方向性ですよね。
>
> なので、二つの用語議論を分離して、JLREQ/JDLREQでは実現したい組版を定義する。それをOpenTypeに実
> 装する上で必要な細かい取り決めは、約物文書で理解してもらう、という役割分担でいいのではないでしょうか、という趣旨です。
>
> On Sun, Oct 10, 2021 at 11:22 PM Atsushi Shimono (W3C Team) <
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Frecom&data=04%7C01%7Cnmccully%40adobe.com%7C458d0b9930834fba624d08d98c0c046e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637694805563599361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9oKxaGM8rsZAH9JTZqj3%2Bd5qfvMObhqAlDp%2Fsx3t220%3D&reserved=0>
> >がOpenType仕様書のAppendixにありますが、こんなイメージです。
> >
> >
> > On Wed, Oct 6, 2021 at 11:53 AM Kobayashi Toshi <binn@k.email.ne.jp
> <mailto:binn@k.email.ne.jp>> wrote:
> >
> >     石井 様
> >
> >      小林 敏 です．
> >
> >     ご参考までに，日本語約物の要件の“送り”という用語について，いくつか案を考えてみました．
> >
> >     A案：現在のまま．
> >      “送り”とい用語が定義されていないので，意味がややあいまい．
> >
> >     Ｂ案：“送り”という用語を定義する．
> >      結構面倒であり，また，JLReqとの整合性がなくなる．
> >
> >     C案：JLReqの用語を用いて説明し，JLReqへの参照を付ける．
> >      たぶん，多くの人はJLReqを参照しない可能性があり，石井さんの心配するように意味を互解する人が出る可能性がある．
> >
> >     D案：説明を簡単というか，以下のようにする．
> >      括弧や句読点など，約物等（全角空白があるので等を付ける）が連続した場合，アキ（空白といってもよい）を調整しないといけないケー
> スがある（詳細はJLReqを参照）．以下では，この調整を行う（“する”でもよい）処理を“約物等の連続時の調整を行う処理”，この調整処
> 理を行わない場合を“約物等の連続時の調整を行わない（“しない”でもよい）処理”という．
> >      D案の欠点は，どう処理するか不明である，ということと，説
> 明の用語が長い．であるが，前者は，調整した例と調整しない例を示せばよい．例を示せば，ほぼわかる（わからなければJLReqを参照すればよい）．
> >
> >      このドキュメントは，約物の字間の調整をどう行うかの説明は，あくまで前提であり，くわしく説
> 明する必要はないので，Ｄ案のような形式でもいいように思います．Ｄ案では，全角，半角，ベタという用語は使用しません．
> >
>
>
>