Re: Double-sided ruby: Translators are traitors. 両側ルビ: 翻訳者は反逆者である

村田さん、翻訳していただいてありがとうございました。

敏先生、これはとてもわかりやすい解説です。開発者であれば十分に理解するためにはこういう細かい説明は必要です。皆さんのご意見は違うかもしれないですが、私なら入れたいと思います。もし本文をなるべく簡単にしたいのであれば別途詳細解説みたいな添付として出してもいいかも知れないです。

ナット

From: Kobayashi Toshi <binn@k.email.ne.jp>
Date: Wednesday, June 3, 2020 at 10:35 PM
To: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Cc: W3C JLReq TF <public-i18n-japanese@w3.org>, Richard Ishida <ishida@w3.org>, Florian Rivoal <florian@rivoal.net>, Nat McCully <nmccully@adobe.com>
Subject: Re: Double-sided ruby: Translators are traitors. 両側ルビ: 翻訳者は反逆者である
MURATA Makoto　様
Nat　様

　　　小林敏です

Natさんの投稿は読みました．

村田さんの

> 具体的なやり方はルビの種類によって違う。両側ルビだとさら
> に組み合わせになるのでややこしい、そこで単純化してやろう
> というわけですよね。

その通りです．

モノルビとグループの組合せは，まだ比較的に考えやすいのです．

例えば，まずモノルビとした各親文字とルビの配置を決めます．そ
のまとまりをモノルビの親文字群ということにします．次にそのモ
ノルビの親文字群をベタ組で並べ（ルビのはみ出しがあれば，その
先端・末尾をモノルビの親文字群のブロックの枠と考え，ブロック
間を空けないで配置する），次にその全長に対し，グループルビを
対応させる．短い場合は，グループルビの字間と先頭・末尾を空け
る，長い場合は，モノルビの親文字群のブロック間を空ける．

この場合，1字の親文字につくルビが2字のときは，わりあい綺麗に
配置できます．ですが，一部の3字以上のルビがつく場合は，あま
りバランスがよい配置とはいえない場合が出てきます．例えば，先
頭のルビだけ3字の場合，親文字全体にグループルビを貼りつける
のではなく，親文字列の先頭にアキがあり，それがバランスを壊し
ます．また，途中の3字のルビが付けば，字数の多いグループルビ
が付く場合，親文字列の字間が均等ではなくなります．これをなく
すには，別のルールが必要になります．で，それを考えると，今度
はモノルビの親文字とルビとの対応に問題が出てきます．

これを考えてもよいが，それて意味があるのかな，というのが私の
感想です．ある特別の個別のケースでうまくいく方法を個別に考え
るのではなく，多くのケースでバランスのよい配置を考えるのは，
実は簡単ではないし，考えても，どうかということです．

上とは，別のモノルビがすべて親文字の字幅を越さない場合と越す
場合に分け，前者はモノルビを親文字に配置し，親文字をベタ組で
配置し，その上で，グループルビを親文字列に配置する処理を考え
る，後者はグループルビとグループルビの組合せという方法にすれ
ば，比較的簡単です．

この方法は，熟語ルビと熟語ルビの組合せでも適用できます．つま
り，
1　両側の熟語ルビの各親文字のとルビの対応が親文字の字幅を越
さない場合
2　片方が越す場合
3　両側が越す場合

1はモノルビのとモノルビの組合せのルール，2はモノルビとグルー
プルビのモノルビが親文字の幅を越さないルール，3はグループル
ビとグループルビの組合せのルール

これでよければ書くことは可能ですが，それ必要かな？

MURATA Makoto さん wrote

> 敏先生、
>
> 両側ルビのところで、5通りから2通りに絞り込む部分について
> なぜこういうことをするのかが分からないというのがNattの
> 提案の理由です。
>
> 親文字とルビの対応関係がはっきり
> するように親文字のほうを引き延ばしたりルビのほうを
> 引き延ばしたりするわけですが、具体的なやり方は
> ルビの種類によって違う。両側ルビだとさらに組み合わせ
> になるのでややこしい、そこで単純化してやろうという
> わけですよね。こういう背景説明も確かに必要です。
> そして、例も必要だと思います。
>
> なお、機械翻訳エンジンはいまはDeepLがもっとも
> 自然な訳文を作ってくれるようです。
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.deepl.com%2Fja%2Ftranslator&amp;data=02%7C01%7Cnmccully%40adobe.com%7C0c9558760299421c0a7908d808491b36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268457392188467&amp;sdata=dbM7XbtEDb5ixh1jzTGSqofxJz3FcPikDRVqHGcvme8%3D&amp;reserved=0
>
> 村田　真
>
> 2020年6月3日(水) 4:23 Nat McCully <nmccully@adobe.com>:
> >
> > I think it would be helpful to provide way more context to the reader about what is being abbreviated or compromised in these simplifications. For example:
> >
> >
> >
> > Ruby spacing rules are governed by the type of ruby (mono- jukugo- or group-) and the length of the ruby relative to the base it annotates. When the ruby is longer than the base, each type has specific rules about how the base text is adjusted to expand. Likewise, when the ruby is shorter, it is expanded according to rules that are designed to make it clear how much of the base text is being annotated.
> >
> > This complex situation is compounded when both sides of the base text are annotated with ruby of differing lengths and/or types. There is a hierarchy of conditions as to which spacing rules are used on the longest component (upper ruby, base text, or lower ruby), and then to each of the shorter components. Generally, when the spacing rules differ among ruby types, (for example when ruby spacing and overhang is different for mono-ruby than for the other ruby types), those rules are honored for e
> ach ruby string and its type, to establish the baseline width of the string. Then, each shorter component is expanded according to expansion rules to fit the longest component.
> >
> >
> >
> > A number of possible combinations of types can be imagined:
> >
> >
> >
> > 1) mono-ruby and mono-ruby
> > 2) group-ruby and group-ruby
> > 3) mono-ruby and group-ruby
> > 4) mono-ruby and jukugo-ruby
> > 5) jukugo-ruby and jukugo- or group-ruby
> >
> > Because jukugo-ruby can be broken across lines, and each break point depends on the relationship of the ruby sub-string to its corresponding base text sub-string, it is deemed overly complicated to support breaking double-sided ruby strings, even of both upper and lower ruby are jukugo-ruby. Therefore jukugo-ruby are to be treated like group ruby when it comes to line breaking.
> >
> >
> >
> >
> >
> > The above is intended to make clear that the correct typesetting of ruby (even simple ruby) has to take into account the spacing rules within the base text and ruby text (and how they relate), and not simply express the algorithm in terms of overall lengths.
> >
> >
> >
> > --Nat

―――――――――――――――――――――
　小林　敏（toshi）　　2020年 6月 4日
　e-mail: binn@k.email.ne.jp
―――――――――――――――――――――