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

敏先生、

両側ルビのところで、5通りから2通りに絞り込む部分について
なぜこういうことをするのかが分からないというのがNattの
提案の理由です。

親文字とルビの対応関係がはっきり
するように親文字のほうを引き延ばしたりルビのほうを
引き延ばしたりするわけですが、具体的なやり方は
ルビの種類によって違う。両側ルビだとさらに組み合わせ
になるのでややこしい、そこで単純化してやろうという
わけですよね。こういう背景説明も確かに必要です。
そして、例も必要だと思います。

なお、機械翻訳エンジンはいまはDeepLがもっとも
自然な訳文を作ってくれるようです。

https://www.deepl.com/ja/translator

村田 真

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 each 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
>
> From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
> Date: Tuesday, June 2, 2020 at 2:16 AM
> To: W3C JLReq TF <public-i18n-japanese@w3.org>
> Cc: Richard Ishida <ishida@w3.org>, Florian Rivoal <florian@rivoal.net>
> Subject: Double-sided ruby: Translators are traitors. 両側ルビ: 翻訳者は反逆者である
>
> Folks,
>
>
>
> Here is my attempt for providing an understandable
>
> description of Bin-sensei's ideas for handling
>
> double-sided ruby.  I paid no attention to sentences
>
> or words in his text.  What is more, I tried to ignore
>
> details as much as possible.  So, my text may well contain
>
> significant misunderstandings and problems.  I'm
>
> responsible for them, but  I hope that my text is still useful
>
>
>
> Here goes.
>
>
>
> ------------------------------------------------------------------------------------------------------
>
>
>
>
> Placement of double-sided ruby
>
> Double-sided ruby can be classified into five types
> of ruby combinations:
>
> 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
>
> JIS X 4051 provides procedures for handling 1), 2),
> and 3).  But 3) is actually handled as 2) by first
> concatenating mono-ruby strings to form a single
> group-ruby.
>
> We propose to handle 4) as 1) by first converting
> jukugo-ruby to mono-ruby, and to handle 5) as 2) by
> first converting jukugo-ruby to group-ruby.
>
> My note: Some examples for demonstrating this
> simplification?
>
> Here we further prose procedures for handling
>
> combinations 1) and 2), which are simpler than those
>
> in JIS X 4051.
>
>
> 1) mono-ruby and mono-ruby
>
> See Figure 23.
>
> 2) group-ruby and group-ruby
>
> Let U be the box for the upper group-ruby and that
> for the lower group-ruby, let L be the box for the
> upper group-ruby, and let B be the box for the ruby
> base.  Let U_w, L_w, and B_w be the width of these
> boxes, respectively.
>
> Case 1: U_w  < B_w and L_w < B_w
>
> Handle the upper group-ruby and the ruby base as
> specified in XX, and then handle lower group-ruby
> and the ruby base, similarily.
>
> Case 2: U_w >= L_w >= B_w
>
> First, handle the upper group-ruby and the ruby base
> as specified in XX. (Note: box B may be widened.)
> Then position box L by aligning its center and that
> of box B.
>
> Case 2': L_w >= U_w >= B_w
>
> Similar to Case 2.  Read the above description
>
> after swapping L and U.
>
>
> Case 3: U_w >= B_w >= L_w
>
> Similar to Case 2.  But the positioning of box L is
>
> doner after it is widened (by introducing character-spacing and
> word-spacing) so that L_w and B_w are identical.
>
> Case 3': L_w >= B_w >= U_w
>
> Similar to Case 3.  Read the above description
>
> after swapping L and U.
>
>
> --
> Regards,
> Makoto



-- 
Regards,
Makoto

Received on Wednesday, 3 June 2020 12:27:44 UTC