Re: ルビと行間注の違い

On 2020-07-30 11:20, MURATA Makoto wrote:
> 2020年7月30日(木) 12:00 KOBAYASHI Tatsuo(FAMILY Given) <tlk@kobysh.com>:
>> 
>> 村田さま、
>> 小林龍生です。
>> 
>> だとすると、HTMLやCSSの議論で、ルビと行間注を区別すること自体がナンセンスなのでは?
> 
> JLreqやSimple Rubyの議論では区別されていますが、CSSやHTML
> で区別しているのを見たことがありません。
> 
>> もしくは、敏さんの議論でルビと行間注の切り分けが必須なものであれば、それこそ、ルビとは別に行間注の機能を提案するのがいいのでは?
> 
> 行間注は出来ない、ルビをabuseして行間注をやる人は
> いるというのが現状ですね。
> 
> 行間注をWebに入れるべきかというと、とうぜん議論になります。頭注、傍注が
> ないのに、なぜ行間注という気もします。おそらくWHATWGを突破できない
> と予想します。

要件[1][2][3]が明瞭ではないことも、行間注は出来ない理由の1つである可能性があると思います。それから、優先度もルビより高くないかもしれません。

Fuqiao

[1] https://w3c.github.io/jlreq/#h-note-223
[2] https://w3c.github.io/clreq/#positioning_of_interlinear_comments
[3] https://w3c.github.io/simple-ruby/#h-note

> 村田 真
> 
>> 
>> 2020年7月30日(木) 11:57 MURATA Makoto <eb2m-mrt@asahi-net.or.jp>:
>>> 
>>> > Tag Abuse Syndromeは、HTMLの初期のころから、ず~っとですよね。
>>> 
>>> そんなに新しくないですよ。Web以前からです。
>>> 
>>> > だとすると、そもそも、村田さんが、ルビと行間注の違いについて問題意識を持ったのはどうしてなのだろう。
>>> 
>>> 小林先生の文書が区別しているからです。
>>> 
>>> > マヌケな質問ですが、CSSとかには、ルビとは別に、「行間注」という機能があるのだろうか。
>>> 
>>> ありません。
>>> 
>>> 村田 真
>>> 
>>> 2020年7月30日(木) 11:47 KOBAYASHI Tatsuo(FAMILY Given) <tlk@kobysh.com>:
>>> >
>>> > 村田さま、みなさま、
>>> > 小林龍生です。
>>> >
>>> > Tag Abuse Syndromeは、HTMLの初期のころから、ず~っとですよね。
>>> > だとすると、そもそも、村田さんが、ルビと行間注の違いについて問題意識を持ったのはどうしてなのだろう。
>>> > マヌケな質問ですが、CSSとかには、ルビとは別に、「行間注」という機能があるのだろうか。それとも、問題は、「行間注」という機能があるにもかかわらず、Tag Abusse Syndromeで、ルビ機能を「行間注」機能として使ってしまうところにあるのだろうか。
>>> >
>>> >
>>> > 2020年7月29日(水) 21:02 木田泰夫 <kida@mac.com>:
>>> >>
>>> >> そうですよね。この議論が始まった時から、それはセマンティックの違いでパーザーには見分けがつかないので、本当にやろうとしたら ruby とは別のタグが必要だろうなと思っていました。しかし実現は無理だろうと。
>>> >>
>>> >> もう一つの方法としては github でちょっと触れた、行長との比較長さで機械的に場合分けするか、もしくはもう ruby は途中で改行可能にしてしまうか。
>>> >>
>>> >> 木田
>>> >>
>>> >> 2020/07/29 18:41、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール:
>>> >>
>>> >> 構造化文書の世界ではTag Abuse Syndromeという言葉
>>> >> があります。ユーザは見た目だけを考えてタグを選び、
>>> >> 意味を正しく反映したタグを選んでくれないという問題のことです。
>>> >> 使い分け規則を作っても、ユーザに無視されればそれで終わり。
>>> >> これは解決不能な問題です。
>>> >>
>>> >> いまからrubyをいくつかの要素に分けるというのは出来ない相談です。
>>> >> 不可能なことです。生没年を指定するのにruby要素を使っては
>>> >> いけないと言ったところでおそらく何も変わらないでしょう。
>>> >>
>>> >> ruby要素に 、ヒント情報(おそらくARIAのrole)をつけるという
>>> >> コンベンションを入れ、それを守っていれば良いことがある
>>> >> ぐらいは出来ます。それも、守らない人のほうが多いという前提で
>>> >> 組み立てないといけません。
>>> >>
>>> >> 村田 真
>>> >>
>>> >> 2020年7月29日(水) 16:49 KOBAYASHI Tatsuo(FAMILY Given) <tlk@kobysh.com>:
>>> >>
>>> >>
>>> >> 小林龍生です。
>>> >>
>>> >>
>>> >> とうとう、泥沼に踏み込みましたね。というか、この先に進むには、避けて通れないからなあ。
>>> >>
>>> >>
>>> >> 私見ですが、この問題を解決するためには、現在のルビタグを捨てて、機能論的(意味構造的)タグと、表現としての行間注釈とを切り分けて考えなければ、先に進めないように思います。
>>> >>
>>> >> この問題は、約物の扱いも似ています。
>>> >>
>>> >> 要は、ルビとは、行間に組み込む約5.5ポイントの活字(それも従来は小書きの仮名を持たない仮名だけのセット)以上でも以下でもなく、それがどのような機能を果たすかは、文脈に置かれなければ定まらないということ。
>>> >>
>>> >> かつてのメカニカルなタイプライターがsingle quotationとapostoropy、angle bracketとgrater thanやsmaller thanを共有していたのと似たような話。
>>> >>
>>> >> 構造化文書屋さんには、この辺りの問題、果敢に切り込んでいって欲しいなあ。
>>> >>
>>> >>
>>> >> ちなみに、ルビの多義性と多様性については、今野真二さんの「振り仮名の歴史」(集英社新書)がよくまとまっていると思います。
>>> >>
>>> >>
>>> >> 2020年7月29日(水) 14:21 Kobayashi Toshi <binn@k.email.ne.jp>:
>>> >>
>>> >>
>>> >> 村田 様
>>> >>
>>> >> みなさな
>>> >>
>>> >>
>>> >>    小林敏です
>>> >>
>>> >>
>>> >> Placement of Japanese Rubyを直す機会があれば,JLReqの行間
>>> >>
>>> >> 注の例示への参照を付けましょう.
>>> >>
>>> >>
>>> >> 次のルビと行間注ですが,おっしゃるように,その境界はあいまい
>>> >>
>>> >> です.文書作成者(または指定者)の指示によるしかないかと思っ
>>> >>
>>> >> ています.(似た事例として,ルビ処理では,複合語の場合,全体
>>> >>
>>> >> を1つの熟語ルビの親文字とするか,複合語を構成する各語を1つの
>>> >>
>>> >> 親文字とするかは,対象の語句から決まることではなく,文書作成
>>> >>
>>> >> 者(または指定者)の指定によるしかありません.例えば,東京都
>>> >>
>>> >> と言った場合,“東京都(とうきようと)”とするか,“東京(とうき
>>> >>
>>> >> よう)”+“都(と)”とするかは,文書作成者(または指定者)が決
>>> >>
>>> >> めるしかありません。)
>>> >>
>>> >>
>>> >> 行間注は,ある意味なんでもありかと思います.それに対し,ルビ
>>> >>
>>> >> は必ず親文字が1字以上あり,また,語です(複合語を含め).ル
>>> >>
>>> >> ビ文字列は,まとまりとなったものについては分割禁止です.
>>> >>
>>> >>
>>> >> これに対し,行間注は,親文字がなく,対応する位置だけでもよい
>>> >>
>>> >> し,語句でも,文でも,段落全体でもかまいません.行間注は,親
>>> >>
>>> >> 文字列も行間注文字列も,分割可能位置では分割が可能にしないと
>>> >>
>>> >> 処理できません.配置上の問題としては,原則として行間注はベタ
>>> >>
>>> >> 組であり,配置位置も,ルビとは異なり,親文字に対し,先頭を合
>>> >>
>>> >> わせてもよいし,末尾を合わせてもよいし,中心をそろえてもよ
>>> >>
>>> >> い,という選択肢は必要になるかと思います.親文字からのはみ出
>>> >>
>>> >> しも,他の文字に掛かることは許容しないといけないでしょう.
>>> >>
>>> >>
>>> >> なお,考え方としては,ルビ処理と行間注を含めた処理法を記述
>>> >>
>>> >> し,そのなかで,部分を考え(モノルビ,グループルビ,熟語ル
>>> >>
>>> >> ビ,……),その部分の処理法を規定するということも考えれるか
>>> >>
>>> >> と思います.
>>> >>
>>> >>
>>> >> 問題は,行間注まで含めた処理を方法を記述することは,それなり
>>> >>
>>> >> に大変であり,複雑になります.ですので,まずは行間注は除外
>>> >>
>>> >> し,ルビ処理だでを書くということで進めていくしかないのではな
>>> >>
>>> >> いか,ということです.
>>> >>
>>> >>
>>> >> なお,行間注の配置処理方法については,以前に書いたものがあっ
>>> >>
>>> >> たかと思います.
>>> >>
>>> >>
>>> >> 以上です.
>>> >>
>>> >>
>>> >> MURATA Makoto さん wrote
>>> >>
>>> >>
>>> >> 皆さん、
>>> >>
>>> >>
>>> >> ルビとは何で、行間注とは何か、両者の境界は
>>> >>
>>> >> なにかをはっきりさせる必要があると思います。
>>> >>
>>> >>
>>> >> https://github.com/w3c/simple-ruby/issues/42
>>> >>
>>> >>
>>> >> 小林先生が、以前にこう書いています。
>>> >>
>>> >>
>>> >>    冒頭近く"Ruby as notes"という注があります.
>>> >>
>>> >>    ここで説明している行間注については,JLReqの
>>> >>
>>> >>    "4.2.2 Note Numbers"の直前に行間注の例(図)を
>>> >>
>>> >>    掲げていますので,可能であればで結構ですが,
>>> >>
>>> >>     参照を付けていただけると,ありがたい.
>>> >>
>>> >>
>>> >> この例では、「徳川家康」について、「1837-1913 江戸幕府最後の
>>> >>
>>> >> 将軍」が行間注となっています。では、 「1837-1913」とだけつける
>>> >>
>>> >> と、行間注でしょうか、ルビでしょうか。そして、Rules for Simple
>>> >>
>>> >> Placement of Japanese Rubyがカバーする範囲でしょうか?
>>> >>
>>> >>
>>> >> ほかに、帝釈にインドラと振ったら、ルビでしょうか、
>>> >>
>>> >> 行間注でしょうか。日本デイジーコンソーシアム
>>> >>
>>> >> の技術委員会でまとめた例がここにあります。
>>> >>
>>> >>
>>> >> https://onedrive.live.com/Edit.aspx?resid=4106E423DCEF597E!41864&wdPid=2e60c9ec&authkey=!AGh8d3MrAlsP2bk
>>> >>
>>> >>
>>> >> これはWord文書です。Webで見るのではなく、ダウンロード
>>> >>
>>> >> してみてください。
>>> >>
>>> >>
>>> >> 慶應義塾大学
>>> >>
>>> >> 村田 真
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> KOBAYASHI Tatsuo(小林龍生)
>>> >>
>>> >> Scholex Co., Ltd. Yokohama
>>> >>
>>> >> homepage) http://kobysh.com/
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Regards,
>>> >> Makoto
>>> >
>>> >
>>> >
>>> > --
>>> > KOBAYASHI Tatsuo(小林龍生)
>>> > Scholex Co., Ltd. Yokohama
>>> > homepage) http://kobysh.com/
>>> 
>>> 
>>> 
>>> --
>>> Regards,
>>> Makoto
>> 
>> 
>> 
>> --
>> KOBAYASHI Tatsuo(小林龍生)
>> Scholex Co., Ltd. Yokohama
>> homepage) http://kobysh.com/

Received on Thursday, 30 July 2020 06:45:23 UTC