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

コメント、ありがとうございます。敏先生の主題からは少しずれてしまうかもしれませんが、約物要件案の位置づけが不明瞭なために議論を難しくしている部分があるのではないかと思い、論点を二つに分けてみたいと思います。

   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>
がOpenType仕様書のAppendixにありますが、こんなイメージです。


On Wed, Oct 6, 2021 at 11:53 AM Kobayashi Toshi <binn@k.email.ne.jp> wrote:

> 石井 様
>
> 小林 敏 です．
>
> ご参考までに，日本語約物の要件の“送り”という用語について，いくつか案を考えてみました．
>
> A案：現在のまま．
> “送り”とい用語が定義されていないので，意味がややあいまい．
>
> Ｂ案：“送り”という用語を定義する．
> 結構面倒であり，また，JLReqとの整合性がなくなる．
>
> C案：JLReqの用語を用いて説明し，JLReqへの参照を付ける．
> たぶん，多くの人はJLReqを参照しない可能性があり，石井さんの心配するように意味を互解する人が出る可能性がある．
>
> D案：説明を簡単というか，以下のようにする．
>
> 括弧や句読点など，約物等（全角空白があるので等を付ける）が連続した場合，アキ（空白といってもよい）を調整しないといけないケースがある（詳細はJLReqを参照）．以下では，この調整を行う（“する”でもよい）処理を“約物等の連続時の調整を行う処理”，この調整処理を行わない場合を“約物等の連続時の調整を行わない（“しない”でもよい）処理”という．
>
> D案の欠点は，どう処理するか不明である，ということと，説明の用語が長い．であるが，前者は，調整した例と調整しない例を示せばよい．例を示せば，ほぼわかる（わからなければJLReqを参照すればよい）．
>
>
> このドキュメントは，約物の字間の調整をどう行うかの説明は，あくまで前提であり，くわしく説明する必要はないので，Ｄ案のような形式でもいいように思います．Ｄ案では，全角，半角，ベタという用語は使用しません．