Re: 両側ルビをどうするか

木田さん、


2022年7月27日(水) 21:23 木田泰夫 <kida@mac.com>:

> 村田さん、
>
>
> DAISYコンソーシアムは、両側ルビを必要と考えていない、のか、積極的に、アクセシビリティに問題があるなどの理由で、あっては困る、と考えているのかどちらでしょう？


前者です。両側ルビを使うとどうなるかまで考えた
ことは一度もありません(興味がない)。

>

>
> DAISY コンソーシアムの立場がわかったとして、他の領域、例えば電子書籍や、ウェブ、などなど、はどうでしょう？


それはJDCが答えることではないですね。

私個人は、要らない、袋小路だ、どうせGoogleとAppleは
実装しないと思ってます。

村田

>
>
> 木田
>
> > 2022/07/27 21:15、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール:
> >
> > 木田さん、
> >
> > 両側ルビに固執する人が仕様制定側にはいますが、
> > ブラウザベンダは嫌がっているのが現状だと
> > 思います。Firefoxだけが例外ですが、シェアは
> > 10%を切っています。
> >
> > 日本DAISYコンソーシアムには、両側ルビ
> > に言及する人は私以外にいません。私が
> > 両側ルビが必要かと聞いたときに答えてくれる
> > （そしてパーレンで処理していると言う）人が
> > いるだけです。日本DAISYコンソーシア
> > 技術委員会としての公式な意見をまとめて
> > HTML WGに出すのは、おそらくやるほうが
> > 良いですね。あれば使うかもしれない程度
> > の関心しかないと書くことになるでしょう。
> >
> > このタスクフォースから、両側ルビの必要性
> > についてHTML WGにレポートすればそれで
> > よいと思います。議論してもどうせ無駄（きっと
> > 平行線）なのでタスクフォース内でアンケート
> > を取り、その結果を報告するというのは
> > どうでしょう。
> >
> > W3C内での決定権はHTML WGにあります。ただし、
> > WHATWGのHTMLにはブラウザベンダが実装しない
> > と入らないので、HTML WGの仕様に入っていても
> > 空文になる可能性は大きい。
> >
> >>
> ただし、両側ルビがとても重要なら、行間注というものを定義して、それは、ルビのように範囲につくのではなく、特定の文字もしくは文字の間に付く。脚注のスタイル差のようなもの。そのようなものを定義することができるなら、複雑性をもたらすことなく、両側ルビのようなものを生かす余地があるかとも思います。もちろん、html
> 自体に脚注の機能さえありませんので（right?）、勝算は高くありませんが、これが正しい方向かと思います。
> >
> > ルビの複雑化は正しい方向ではないというのは同意します。
> > しかし、Open Annotationを追求するのが正しい方向だと
> > 私は思っています。
> >
> > 村田 真
> >
> > 2022年7月27日(水) 20:48 木田泰夫 <kida@mac.com>:
> >>
> >> みなさま、
> >>
> >> （敏先生、指摘ありとうございます）
> >>
> >> 両側ルビをどうするか決める必要がありますね。両側ルビはいらない、と言う声も多いようですが、jlreq-d
> でいらないことにすると、おそらく将来にわたって両側ルビを殺すことになるでしょうから、そのような覚悟で考えましょう。
> >>
> >> 私は、現在のルビの仕組みを両側につけられるようにすることは、重要性以前に、仕組みを複雑にしすぎると言う理由で、やらない方が良いと感じています。
> >>
> >>
> ただし、両側ルビがとても重要なら、行間注というものを定義して、それは、ルビのように範囲につくのではなく、特定の文字もしくは文字の間に付く。脚注のスタイル差のようなもの。そのようなものを定義することができるなら、複雑性をもたらすことなく、両側ルビのようなものを生かす余地があるかとも思います。もちろん、html
> 自体に脚注の機能さえありませんので（right?）、勝算は高くありませんが、これが正しい方向かと思います。
> >>
> >> いかがでしょう？
> >>
> >> 木田
> >>
> >> 2022/07/27 13:24、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
> >>
> >> Yasuo Kida 様
> >> みなさま
> >>
> >> 小林 敏 です．
> >>
> >> Yasuo Kida さんwrote
> >>
> >> 用語について
> >>
> >> ルビは、三種類もあるルビの理解がまず難しいと感じています。しかしよく比べて読
> >>
> >> めば基本は共通です。ルビの単位が一文字より大きければグループルビですから、モ
> >>
> >> ノルビとグループルビは一体で説明し、異なる点を、一文字の場合には、と例外を説
> >>
> >> 明する方が記述が短く、わかりやすくなるように思います。用語を増やすとそれだけ
> >>
> >> 複雑に見えますので、両方まとめて「ルビ」で良いと私は思います。
> >>
> >>
> >> これは可能です．グループルビの分割を認めると，親文字1字の場合も記述しないといけない．つまりモノルビの方法です．
> >>
> >>
> ただ，両側ルビの場合が問題というよりは，説明がやっかい．親文字が複数であるが，片方がグループルビで，もう一方がモノルビの際に，片方が複数の親文字にルビを対応させ，片方は，個々の漢字にルビを対応させ……みたいな説明になる．この説明でモノルビという用語は便利
> >>
> >> モノルビとグループルビに限れば，ルビ配置のルールは以下の場合に分けられる
> >> 1 親文字1字の場合
> >> 2 親文字2字以上の場合
> >>  a 親文字もルビ文字も漢字又は仮名
> >> ルビ文字が1字の場合
> >> ルビ文字が2字以上の場合
> >>  親文字列長とルビ文字列長が同じ
> >>  親文字列長とルビ文字列長が異なる
> >> 親文字列長が長い
> >> ルビ文字列長が長い
> >>  b 親文字もルビ文字のいずれかがラテン文字の場合
> >>
> >> ここに熟語ルビを含めると，以下になる．問題がaだけですので，そこだけを示す．
> >> 2 親文字2字以上の場合
> >>  a 親文字もルビ文字も漢字又は仮名
> >>  a-1 親文字列に対し，ルビ文字全体が対応している（従来のグループルビ）．
> >> ルビ文字が1字の場合
> >> ルビ文字が2字以上の場合
> >>  親文字列長とルビ文字列長が同じ
> >>  親文字列長とルビ文字列長が異なる
> >> 親文字列長が長い
> >> ルビ文字列長が長い
> >>  a-2 親文字列は一体であり，この親文字に対し，ルビ文字全体が対応している
> >> とともに，部分ごとの対応も示されている（分割可能なグループルビのこと）
> >>  分割しない場合は，a1と同じ，分割した場合は，1又はa-1と同じ
> >>  a-3 親文字列は一体であり，この親文字に対し，ルビ文字の各文字ごとに
> >> ルビが対応している（熟語ルビのこと）．
> >>  各親文字列に対応するルビ文字列長が，各親文字の長さ以下の場合
> >>  各親文字列に対応するルビ文字列長が，各親文字の長さを超える場合
> >> 親文字列長とルビ文字列長が同じ
> >> 親文字列長とルビ文字列長が異なる
> >>  親文字列長が長い 例：
> >>  ルビ文字列長が長い
> >>
> >> ＊これはシンプルルビの内容は同じで書き換えたも，マークアップでa-2とa-3の区別が問題．
> >>
> >> 熟語ルビを含めた別案．そこだけを示す．
> >> 2 親文字2字以上の場合
> >>  a 親文字もルビ文字も漢字又は仮名
> >>  a-1 親文字列に対し，ルビ文字全体が対応している（従来のグループルビ）．
> >> ルビ文字が1字の場合
> >> ルビ文字が2字以上の場合
> >>  親文字列長とルビ文字列長が同じ
> >>  親文字列長とルビ文字列長が異なる
> >> 親文字列長が長い
> >> ルビ文字列長が長い
> >>  a-2-1 親文字列は一体であり，この親文字に対し，ルビ文字全体が対応して
> >>  いるとともに，ルビ文字が親文字1字ごと又は部分に対応しいる（特別の
> >>  指示のないもの）．
> >> 分割しない場合は，a1と同じ，分割した場合は，1又はa-1と同じ
> >>  a-2-2 上と同じであるが，（特別の指示のあるもの）．
> >>  1の親文字1字の場合と同じ
> >>
> >>
> この別案は，熟語ルビを分解し，a-2-1又はa-2-2とする．いってみれば，ルビの字数がどうであろうと，熟語に付くルビをモノルビ的に処理したければa-2-2，グループルビ的に処理したければa-2-1を選びなさいということです．
> >>
> >> ただ，a-2-2で親文字列の2文字と対応させて文字列があった場合が新たな問題となるが，それはa-1で処理すればよい．．
> >
> >
> >
> > --
> > Regards,
> > Makoto
>
-- 
Regards,
Makoto