Re: Design Principles behind Simple Ruby


> A 序文の修正について
> これは，私も考えてみますが，みなさまさからの具体的な提案がありましたら，お知らせください．

JLReq の実装の一例を示している。JLReq は一つのことに複数の処理方法を示しているが、この文章ではそれを適用する一つの考え方を示していること。ベースライン、つまり日本語ルビに最低限必要な機能に絞って書いてあること。という感じでしょうか？

基本的には敏先生のこの文の作成意図を書いていただければ良いと思います。私としては、JLReq かこれかを選ばなければならないようなものではなくて、JLReq の実装のためにあるのだという点がはっきりすればありがたいです。

リチャードが大体の出来上がり時期を知りたいとのことですが、一、二週間で書いていただくことが可能な範囲ですか？

木田

> 2020/04/08 16:39、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
> 
> みなさま
> 
>    小林敏です
> 
> A　序文の修正について
> これは，私も考えてみますが，みなさまさからの具体的な提案がありましたら，お知らせください．
> 
> B　注釈としてのruby（様のもの）は対象としない，……
> 
> ruby（様のもの）の注釈については，これはルビではなく，必要が
> あれば，別の名前をつけて処理方法を決めた方がよいと考えている
> からです．一番の問題は，この注釈では1行に入りきらない場合も
> 想定されています．モノルビなどでは，親文字列とルビ文字列は，
> いずれの箇所でも2行に分かれる分割は求められていません．
> 
> で，例えば，ruby（様のもの）の注釈を“行間注”とでも名前を付け
> れば，概略，以下のような処理方法を考えることができます．
> 
> 1 行間注の親文字列は指定による．
> 2 行間注の文字サイズは指定による．
> 3　行間注の行送り方向の配置位置
> 3.1　行間注の配置位置は，行送り方向の先頭側又は末尾側とし，
> どちからにするかは指定による．（縦組では右側，横組では下側の
> 例があるので）
> 3.2 行間注と親文字は，行送り方向のそれぞれの文字の外枠を接
> して配置する．
> 4 行間注の文字の字間処理は，本文と同じとする．ただし，先頭
> 又は末尾に配置する括弧類，句読点の前又は後ろの二分アキは確保
> しないものとする．また，2行に分割する場合の処理は，本文の処
> 理と同じとし，行末にアキがでた場合には，そのアキを確保し，行
> の調整処理は行わない．
> 5　行間注の親文字に対する行送り方向の原則的な配置位置は，次
> とする．いずれにするかは指定による．
> 5.1　親文字と行間注の字詰め方向の先頭をそろえる．
> 5.2　親文字と行間注の字詰め方向の末尾をそろえる．
> 5.3　親文字と行間注の字詰め方向の中心をそろえる．
> 　＊末尾を選べば，行間に配置する注番号も，これで処理できま
> 　す．
> 6　親文字の文字列全体が1行内に配置されている場合で，行間注の
> 文字列が親文字列より長いときの字詰め方向の配置位置
> 6.1　字詰め方向の先頭をそろえる場合，末尾側に延ばし，更に親
> 文字を配置する行の末尾を超える場合は，先頭側に延ばし，先頭側
> の行を超える場合は，次行以下の行頭から配置する．
> 　＊2行する行間注は考えない．
> 6.2　字詰め方向の末尾をそろえる場合，先頭側に延ばし，親文字
> を配置する行の先頭を超える場合は，末尾側に延ばし，更に末尾側
> の行を超える場合は，次行以下の行頭から配置する．
> 6.3　字詰め方向の中心をそろえる場合，両側に平均に伸ばし，片
> 方が先頭又は末尾に達した場合は，反対方向の先頭又は末尾まで延
> ばし，更に行を超える場合は，次行以下の行頭から配置する．
> 7　親文字の文字列が，2行以上にまたがる場合の字詰め方向の配置
> 位置は，親文字列の先頭行に配置する親文字列に対して前項の配置
> 処理を行い，配置する行を超える場合は，次行以下の行頭から配置
> する．
> 
> C　両側のルビの配置処理法
> 
> ついでに，話題に出ていた両側のルビの処理法について，私の考え
> た処理法は，JIS X 4051の規定を拡張して，熟語ルビも対象にいれ
> たものとしては，概略，以下です．
> 
> 1　ルビの種類とその組合せ
> a　モノルビとモノルビの組合せ
> 　処理方法は後述
> b　グループルビとグループルビの組合せ
> 　処理方法は後述
> c　グループルビとモノルビの組合せ
> 　これは，連続するモノルビを一つのグループルビとして扱い，b
> 　の方法で処理する
> d　熟語ルビとモノルビの組合せ
> 　熟語ルビの熟語を構成する個々の漢字とそれに対応するルビ文
> 　字との組合せを一つのモノルビとして扱い，aの方法で処理す
>  る．
> e　一方が熟語ルビで片方が熟語ルビ又はグループルビの組合せ
> いずれの熟語ルビも一つのグループルビとして扱い，bの方法で処理する
> 
> 2 モノルビとモノルビの組合せの行送り方向の配置処理
> 　両側のルビ文字列をベタ組とし，親文字の文字列とルビの文字
> 　列の中心をそろえて配置する．
> 
> 3　グループルビとグループルビの組合せの行送り方向の配置処理
> 1）両側のルビの文字列長が親文字の文字列長未満の場合
> 　両側のそれぞれのルビの文字列の字間と先頭及び末尾のアキを
> 　空け，親文字列と長さをそろえる（ただし，ルビ文字が欧文文
> 　字の場合は，ベタ組とする）．字間と先頭及び末尾のアキの比
> 　率は2対1とする．
> 　なお，親文字の文字列長とルビの文字列長が同じ場合は，ルビの
> 　文字列長はベタ組とする．
> 
> 2）いずれかのルビの文字列長が親文字の文字列長を超える場合
>   長い方のルビ文字列に対し，親文字の文字列の字間と先頭及
>   び末尾のアキを空け，長い方のルビ文字列と長さをそろえる
>   （ただし，親文字が欧文文字の場合は，ベタ組とする）．字
>   間と先頭及び末尾のアキの比率は2対1とする．短い方のルビ
>   文字列が字間を空けた親文字の文字列長を超える場合はルビ
>   文字はベタ組とし，字間を空けた親文字の文字列長未満の場
>   合は， ルビの文字列の字間と先頭及び末尾のアキを空け，親
>   文字の文字列と長さをそろえる．字間と先頭及び末尾のアキ
>   の比率は2対1とする．
> 
> 4　親文字列よりはみ出したルビ文字と戦後に配置する文字関係，及び行頭並びに行末の配置処理は，“2　ルビの簡便な配置ルール”
> と同じとする．
> 
> 以上です．
> 
> Atsushi Shimono (W3C Team) さん wrote
> 
>>> On 2020/04/07 20:37, MURATA Makoto wrote:
>>> 私が別文書を主張する理由は、simple ruby文書をほとんどの
>>> 読者は読み終えないと思っているからです。Design Principles
>>> behindとすれば、両者の位置づけははっきりします。
>>> 
>>> 海外の実装者からすると 、Simple Rubyにあるアルゴリスムは
>>> 
>>>  * 日本語以外の言語を考慮していない
>>>  * HTMLの他のタグやCSSの他の機能を考慮していない
>>> 
>>> ので読んでも仕方がないと途中で見切られるのではないで
>>> しょうか。
>> 
>> 　わたしもそうは思ってます > ほとんどの読者は読み終えない
>> 　call中のターゲット層の話は、個人的には、通読して利用する人は高々一桁、実装者への参考とし
>> てcss spec(のノートとか)からリンクされてたらその部分だけ摘まみ読みする人が少々、ということ
>> なのかな、と思ってました。
>> 　読んでも仕方がないと途中で見切られる、というよりは、現実的にはそんな感じの用法なんじゃな
>> いでしょうか。というところで、同じ文書内のappendixとかnoteとかで参照されてれば何かの拍子に
>> 見るかという人が出るかもしれないけれど、分けたら「余計に」誰も見なくなる、んじゃないかなと
>> ちょっと危惧するところです。。
>> 
>> 
>>>> 　また、現実として、
>>>>> ?1. 二レベルモデル（少なくとも二レベル）の説明
>>>>> ? ? ? * 親文字とルビを合わせたものについてのボックスを作るレベル
>>>>> ? ? ? * このボックスを行の中に配置する（当然ルビ掛けも考慮する）レベル
>>>> の1.の部分は、現状でも日本語での1.の「配置ルールで考慮した事項」の(4)、simple-rubyで
>>>> の2.1.4にあるように思います。
>>> 
>>> 確かにそうなんですが、私にはその重要性が見えません
>>> でした。敏先生が話しているのを聞いて、徐々に認識
>>> しました。もっとはっきり全面に打ち出さないと
>>> いけないと思います。
>> 
>> 　+1
>> 
>>> また、 1.の「配置ルールで考慮した事項」の中の各項目
>>> のレベルがそろっていないという気もします。
>> 
>> 　+1
>> 
>>>> あと、2.1.1 Note: Ruby as noteに、日本語版でサイドの注釈に入っている、注釈としての
>>> ruby(様のもの)は対象としない、というのが入っていますが、これはもう少しintroductionあ
>>> たりの文書の前提条件・対象の記述に入れた方がいいのではないかな、とふと思ったのですが、
>>> いかがでしょう。
>>> 
>>> 確かに。しかし、実装者は、行間注も扱わないといけないので、
>>> 残念ながらsimple rubyを軽視する方向に傾くでしょうね。
>> 
>>  軽視というか、、、そもそもnormative specでない(normative specをまとめるうえでの参考の
>> ためのまとめ文書？)ので＆normativeで定義しきれなかった部分の参照用とするならば、つまみ
>> 食い前提の想定で文書をNoteで出してもいいのではないでしょうか。
>> 
>> 
>>> 
>>> 
>>> 2020年4月7日(火) 19:56 Atsushi Shimono (W3C Team) <atsushi@w3.org <mailto:atsushi@w3.org>>:
>>> 
>>>     shimonoです
>>> 
>>>    On 2020/04/07 17:16, MURATA Makoto wrote:
>>>> 皆さん、
>>>> 
>>>> きょうの会議でSimple Rubyは出来るだけ変えず、序文
>>>> を工夫して（どう？）W3Cからそのまま出すということ
>>>> になりました。
>>>> 
>>>> その上で、私があったら良いと思っているのは
>>>> Design Principles behind Simple Rubyという別文書
>>>> です。
>>> 
>>>     callの後につらつら考えていたのですが、、個人的には、別文書というのは読者を混乱させ
>>>    ることにつながるのでAppendixに追加(など)するほうがいいのではないかと思いました。これ
>>>    らの点はsimple-ruby文書・記述されているルールの検討の前提条件や取捨選択の理由ともい
>>>    うべきものですし、実装者が参考にする場合にも対象の問題点との間での前提レベルのすり合
>>>    わせ(日本語以外が入っていることで問題がややこしくなっている時の特殊条件のくくりだし
>>>    を含み)にも有用なのではないか、という気がしています。
>>> 
>>>    　また、現実として、
>>>> ? 1. 二レベルモデル（少なくとも二レベル）の説明
>>>> ? ? ? ?* 親文字とルビを合わせたものについてのボックスを作るレベル
>>>> ? ? ? ?* このボックスを行の中に配置する（当然ルビ掛けも考慮する）レベル
>>>    の1.の部分は、現状でも日本語での1.の「配置ルールで考慮した事項」の(4)、simple-rubyで
>>>    の2.1.4にあるように思います。
>>> 
>>>> 2.  二レベルモデルの利点
>>>> 3. 二レベルモデルを可能にするために何を諦
>>>> めたか（たとえば、前後の文字を変えるとル
>>>> ビが親文字から何ミリ離れるかが違ってしま
>>>> う機能は落としている）
>>>> 
>>>> 多少のルビ掛けを可能にしつつ、二レベルモデルを可能に
>>>> するために、敏先生はいろいろ苦心していると理解して
>>>> います。
>>> 
>>> 
>>>    　あと、2.1.1 Note: Ruby as noteに、日本語版でサイドの注釈に入っている、注釈としての
>>>    ruby(様のもの)は対象としない、というのが入っていますが、これはもう少しintroductionあ
>>>    たりの文書の前提条件・対象の記述に入れた方がいいのではないかな、とふと思ったのですが、
>>>    いかがでしょう。
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Regards,
>>> Makoto
>> 
> 
> 
> 
> ―――――――――――――――――――――
> 　小林　敏（toshi）　　2020年 4月 8日
> 　e-mail: binn@k.email.ne.jp
> ―――――――――――――――――――――
>

Received on Thursday, 9 April 2020 01:30:17 UTC