Re: JLReq-d においてグループルビの折り返しを可能にする提案 version 2.1

小林 敏さま
みなさま

コメントありがとうございます。これ、面倒くさいのは現状多くの場合、出版社側、制作(印刷)会社側の双方がこういうデータの作り方を「特に問題があるとは思っていない」ことかなと思います。古い出版社の多くは紙の本の制作時にデータは全くチェックせず、出校されたゲラだけを見ます。そこのチェック機能は相当にきめ細かくて入念です。ただ、データが論理的に作られているかどうかは見ません。版面ができていればそこはどうでもよいからです。なので、電子化の際に論理的構造を改めて与えなければならないことになり、工数がかさみます。そして多くの場合それは理解されなかったりもします。電子版でも出版社は版面しかチェックしないからです。


***************************************
(株)三陽社
 メディア開発室
 http://www.sanyosha.co.jp/

 
 田嶋 淳
 tajima@sanyosha.co.jp
 
 ※ブログ運営中です。
  ご意見をいただければ幸いです。
  http://densyodamasii.com/

***************************************



> 2022/09/21 9:50、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
> 
> 田嶋 淳 様
> みなさな
> 
>  小林 敏 です.
> 
> 苦労していますね.
> 
> 以下の例は,ご存じのように,ブラウザの機能がしっかりしていれば,親文字とルビの対応を工夫しなくても処理できるものです.ブラウザの機能がないので,親文字とルビの対応を変えないといけない(固定レイアウトだから可能).
> 
> この問題に解決として以下が考えられる.
> 1 特別なタグ付けしなくても,ブラウザの機能で処理できるようにする.
> 2 ルビの配置処理の考え方を変える(単純な方法にする).
> 
> “Rules for Simple Placement of Japanese Ruby”は,2の考え方です.ただ,出版社は,無理をいってくるでしょうから,2はだめという可能性はある.その際は,料金を変えればよいのですが,過去のいきさつもあり,かなり困難でしょう.それは過去にきちんと説明してこなかった印刷業界の問題であり,ある意味で自業自得といってよいのでとも考えられますが,そうもいっておれないので,1と2の両面で機会があるごとに問題を説明していくしかないでしょう.
> 
>  田嶋 淳 さんwrote
> 
>> 木田さま
>> みなさま
>> 
>> 組版データ上でのルビの処理として完全に固定版面での表示に特化した制作方法を取
>> っているケースが実は結構あり、EPUBにする際にかなり手間がかかっていたりします。
>> 規格としてどうこうという話とはズレますが、参考として挙げておきます。
>> 
>> 例えば行末に熟語/グループルビがかかるようなケースで次のような表示になってい
>> たとして、
>> 
>> [img:スクリーンショット 2022-09-20 13.15.10.png]
>> XHTMLに変換すると以下のようなルビの付け方をされているような例があります。
>> 
>> [img:スクリーンショット 2022-09-20 13.17.15.png]
>> 
>> あるいは1文字で
>> 
>> [img:スクリーンショット 2022-09-20 13.23.21.png]
>> を変換すると
>> 
>> [img:スクリーンショット 2022-09-20 13.24.47.png]
>> 
>> になったりします。つまり活版の際の組版ルールをそのままDTPに持ち込んでいるとい
>> うことかと思いますが、おそらく一社だけのローカルルールという話でもなく、伝統
>> 的な出版社の本では結構一般的な作成方法なのではないかなと経験上感じています。
>> 当然この手の処理がされているもので総ルビの本の電子化は相当に大変です。
>> 
>> 
>> ***************************************
>> (株)三陽社
>>  メディア開発室
>>   http://www.sanyosha.co.jp/

>> 
>>  田嶋 淳
>>   tajima@sanyosha.co.jp
>> 
>>  ※ブログ運営中です。
>>   ご意見をいただければ幸いです。
>>    http://densyodamasii.com/

>> ***************************************

Received on Wednesday, 21 September 2022 04:37:31 UTC