Re: __Simple_Rubyの序文訂正

ナットです。

皆さんがおっしゃることに同意です。インプリを考える人のために「難しいルビ」と「シンプルなルビ」は、どう区別するか、どうしてシンプルなのでいいのか、明確ではなければ説明した方がいいと思います。うちの場合は、段落コンポーザーでの計算は、ルビ付き文字列は行頭、行中、行末に来た場合全ての候補を計算して適切な折り返し位置と空き量調整、追い込みなど、重い計算をするのです。そのROIは紙媒体の印刷物での熟語ルビの使われる頻度やworkaroundはあったのかなどに比較して機能の簡単化してしまったのですが、browserの場合は皆さんがどうそのROIとかに関して考えたのか、明確にした方がいいと思います。開発者はコストはわかりますが、ユーザへの価値は皆さんの方がわかることでしょう。その比較で、ユーザが使えるルビをローコストで開発できるのではと思います。

From: Atsushi Shimono (W3C Team) <atsushi@w3.org>
Date: Monday, April 13, 2020 at 7:54 AM
To: public-i18n-japanese@w3.org <public-i18n-japanese@w3.org>
Subject: Re: __Simple_Rubyの序文訂正
 shimonoです

 最終的に公表する英語版にどう入れ込むかな、というところもにらみつつちょっと返信を書いた
り書き直したり消したりしていたのですが、、とりあえずの提案としてざっくり出させてください。

　現状として、本文は日本語の"0 はじめに"が"1. Introduction"、"1 簡便な配置ルールで考慮し
た事項"が"2. Matters considered by the simple placement rules"に対応しています。そのうえ
で、英語版は一番先頭にAbstractがあり今は
> A simple set of rules for placement of Ruby text in Japanese typography.
という1行になっています。
 JLReqでは、Abstractはsimple-rubyと同様にちょっと長い1行(JIS X 4051への言及や追記・リン
ク追加について)ですが、1.Introductionが目的・作成方法・執筆方針・構成の節立てになっていて、
だいたいsimple-rubyの英語版での1.+2.と短く記述された"目的"の構成です。

　という比較の中で、"目的"の節を増やすのがいいのかな、と思い始めています。というよりは、
"Webでの配置処理"の部分がそれにあたるのかな、と考えるところで、ここがいわゆる論文(やJLReq
などの技術ドキュメント)で言うところのAbstract (JLreqでは"目的"のあたりに相当?)になってい
るのではないかと思います。
　で、いまのところ、改訂議論はもともとの章・節立てと順序を踏襲してその中で文章を明確化・
追記していくという流れで行っていますが、順序の入れ替えを行う、つまり"Webでの配置処理"の
節を"この文書の目的"として先頭に移動するというのが木田さんの提案だと思います(し、わたし
もそうなったほうが技術ノートとして読むにはすっきりするのではないかと考えます)。

 現状では、
> Webでの配置処理を考えた場合，活字組版のように個別箇所で配置位置を工夫する処理は避ける
> のが望ましい．となると，上記の問題をすべて解決できる配置処理方針を決め，処理系に実装し
> ていく必要がある．活字組版で理想とされていた処理方法をカバーするとなると，かなり複雑な
> 処理方針を考える必要がある．
などという部分で、先行するルビ処理のむつかしさの詳細を参照している部分(「上記の問題をす
べて解決できる」など)があるため、多少の文言整理が必要ですが、ざっくりとしたレベルでは節
ごと先頭に移動しても大丈夫ではないかと思うのですが、いかがでしょうか？


　ひとまず、、


On 2020/04/13 10:29, 木田泰夫 wrote:
> 敏先生、
>
> 内容は分かりやすくて良いと思います。ありがとうございます。その文章をドキュメントの先頭に置くことは難しいですか？
>
> 木田
>
>> 2020/04/13 9:47、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
>>
>> 木田 様
>>
>>    小林敏です
>>
>> 木田泰夫 さん wrote
>>>
>>> 通常、技術ドキュメントではそのドキュメントの意図や要約をタイトルの次、一番先頭に持ってくることになっているのですが、後ろの方にされた意図はありますか？
>>>
>>>> 木田
>>
>> “配置ルールで考慮した事項”内に書こうと思ったので，いれる場所
>> がなく，最後にしたものです．
>>
>> それでは，“最後に1行アキで追記”という以下の文章は，“はじめに”
>> の最後の以下の部分を差し替えるようにいたします．
>>
>> -----修正前------
>>
>> 　しかし，ある程度理想的な配置処理を考えたとしても，ルビ処理
>> では，どうしても例外事項が発生し，問題がでる可能性がある．
>> 　そこで，理想ではないが，誤読はされない，といった範囲で，例
>> 外のあまりでない，また，機械的に処理できる簡便な配置処理方針
>> を考える必要があるように思われる．
>> 　以下は，こうした簡便な配置処理方法の一案である．なお，用語
>> はJLReq（日本語組版処理の要件，Requirements for Japanese Te
>> xtLayout）による．
>>
>> -----修正前，以上------
>>
>> これを以下と差し替え
>>
>> -----修正後------
>>
>> 　しかし，ある程度理想的な配置処理を考えたとしても，ルビ処理
>> では，どうしても例外事項が発生する，あるいは，それぞれの要求
>> 事項を組版で実現しようとすると矛盾が出てしまう事項もある．
>> 　こうした事情を考慮すると，理想ではないが，誤読されない，
>> といった範囲で，例外のあまりでない，また，機械的に処理できる
>> 簡便な配置処理方針を考える必要があるように思われる．
>> 　そこで，CSS，SVG及びXSL-FOなどの技術で実現が求められる
>> 日本語組版のルビ処理方法について，何を選べばよいか，何が重要
>> であるかについて，実装する際に参考となるように，この文書で
>> は，JLReqとは異なり，次項で説明する事項を考慮し，配置方法を
>> 一つに絞って示した．（JLReqでは，過去に行われていた処理例を
>> 紹介する意味もあり，一つのことに複数の処理方法や，かなり複雑
>> な処理方法を示している．）
>> 　ただし，ここで解説する処理方法は．方法が絞られたことによ
>> り，すべての人の要求は満足させないかもしれないが，それなりの
>> 組版の品質が確保される方法だと考えている．
>> 　なお，用語はJLReq（日本語組版処理の要件，Requirements for Japanese TextLayout）による．
>>
>> -----修正後，以上------
>>
>> 以上，ご検討ください．
>>
>> —————————————————————
>> 　小林　敏（toshi）　　2020年 4月13日
>> 　e-mail: binn@k.email.ne.jp
>> —————————————————————
>