Re: 6/1 火曜日のミーティング

薛さま

　Javascriptは明示的にサポートはされておらず、特に電書協ガイド準拠のような複数のストアに配信することが前提の場合は使用できないと考えた方がよいかと思います。EPUB内でのJavascript駆動は過去に柴咲コウの写真集などで行われていたのを見てはいますが、それはiBooksに特化して作り込んだものであり、その後同様のケースは出ていません。採算が合わなかったものと思います。Webサイトと同一視はできません。

> 2021/06/01 14:44、Fuqiao Xue <xfq@w3.org>のメール:
> 
> 田嶋さん、
> 
> 薛です。
> 
> EPUBでJavaScriptをサポートするかどうかはわかりませんが、中国語のウェブサイトでは、JavaScriptライブラリを使用して自動的にアキを入れている人もいます。そうすると、HTMLファイルを変更することなく、ソースコードにスペースを入れたページも、入れなかったページも、JavaScriptライブラリは自動的に分析して表示を変えさせます。例：
> 
> * https://sivan.github.io/heti/#javascript

> * https://ethantw.github.io/Han/latest/hws.html

> 
> 薛（せつ）
> 
>> On Jun 1, 2021, at 10:39, 田嶋　淳 <tajima@sanyosha.co.jp> wrote:
>> 
>> 田嶋です。
>> 
>> なぜ手動でスペースを入れる必要が出ているのかと言いますと、現状EPUBでは自動で和欧間のアキは入らず、底本版面との明確な差異が生じるために出版社側から見たときに「スペースを入れて欲しい」という要望が出るためです。彼らは「プリントした版面」しか見ていない場合が大半です。これに対して現状のCSSのみで対応すると「全ての箇所にletter-spacingの指定を入れる」というような話になり、作業量およびコードの可読性的に許容できません。また、欧文用のFour-per-em-space（U+2005）もInDesignの内部では使えますが、日本語フォントはグリフを持っていないようですのでそれをそのままEPUBで使うのはリスクが大きいです。従って、あくまで「現状での」妥協策として半角スペースを入れざるを得なくなっています。これが定着するのは作業者側としても全く望んではいません。早くtext-spacingなりでの対応を望みたいところです。
>> 
>>> 2021/06/01 11:19、Taro Yamamoto <tyamamot@adobe.com>のメール:
>>> 
>>> 各位、
>>> 
>>> アドビの山本です。すこしコメントさせていただきます。
>>> 
>>> 1
>>> Em-dashの件は、20年以上前に木田さんと話した記憶があります。
>>> 
>>> Ø  IMEやキーボードからの入力では、em-dashは ‘-‘ キーを打ちますが、MacではU+2014は入力されるのに対してWindowsではU+2015が入力されます。
>>> 
>>> Natの説明を補足すると、実際の作業上は、（１）IMEが「ダッシュ」に対してU+2014を返すのか、U+2015を返すのか、（２）フォント側はU+2014とU+2015に対応するグリフをどのようにデザインしているか、（３）この2点に応じて、アプリケーション側がどのような対応をするか、ということが課題となります。
>>> 
>>> 私の理解では、Apple社のOSに搭載されているOpenTypeの日本語フォントを含め、大多数の日本語OpenTypeフォントでは、U+2014には欧文用のem-dashを、U+2015には中心付きの水平バーのグリフを割り当てていると思います。昔、木田さんに「なぜAppleのIMEは『ダッシュ』に対してU+2015を返さないのか、日本語テキストなのに？」と質問した時、木田さんのお答えは「U+2015はダッシュでないから」というものだったと記憶しています。（私はこのお答えの主旨は理解しますし合理的な正解だとは思いますが、実際的な観点からは、今でも納得できないものがぼんやりと頭の中に残っています。）
>>> 
>>> もちろん、これはどちらが良いか悪いかという問題ではありません。全角・半角問題と類似の問題ですから。（とはいえ、当然欧文にとっては現在U+2014に対応付けられているグリフがダッシュなのであって、逆に日本語の場合はU+2015に対応付けられているグリフを「ダッシュ」として用いた方が良いわけです。横組みだと分かりにくいかもしれませんが、縦組みでU+2014の回転形のグリフが用いられると、欧文用のダッシュのグリフが日本語に適さないことが顕著に分かります）。
>>> 
>>> コードポイントは同じだけれども、異なるグリフを使い分けたい、という場合には、Natが説明したように、GSUBを用いるのが常套手段となるわけです。またそうすることで、日本語テキストと欧文でどちらのグリフを用いるべきかを、グリフレベルで選択可能になりますし、その切り替えを自動化することもできます。
>>> 
>>> ダッシュ前後の空きがあるかないかは、デザイン差なので、ダッシュを連結して使うのは避けた方が良い場合が多いですが、それに対する現時点で最新の解決策としては、GSUBの合字の機能を用いて、ダッシュが連続した場合には、2-em dashか3-em dashのグリフで表示する方法があります。さらに、GSUBの’locl’を用いて言語によって最適なグリフに切り替えることで、欧文と日本語のダッシュのグリフのバーの高さの違いの問題を回避できます。この方法は一部のOpenTypeフォントで既に利用されています。（もちろん、2-em dashと3-em dashのグリフとコードポイントに対応しているフォントであれば、直接文字コードで2-em dashまたは3-em dashを入力できますが、和文用のグリフへの切り替えにはGSUBを介する必要があると思います）。
>>> 
>>> 2
>>> 和文と欧文との空きは、文字ではありません。他方、欧文のワードスペースは文字です。そこに和文や欧文のスペース文字を挿入してしまうと、原稿のテキストを破壊（あるいは混濁）させてしまいます。あくまで和文と欧文との間隔を調整するのは文字組版の課題なのであり、テキストのレベルで行うことではありません。というか、それをやると不必要な問題を後に残す結果になります（テキストとして意味のない文字をテキストに混入してしまって、しかもワードスペースと同じ文字を用いるので区別がつきません）。さらに文字組の過程で一貫したスペーシングのコントロールが不可能になってしまいます。同じことが、和文での段落先頭の字下げ（インデント）についてもいえます。もし、和欧間にスペース文字を入れなければならない状況があるとしたら、そこには何か問題があるように思います。（電算写植でも例えばCORA5の場合には、和欧混植の場合には、四分自動挿入モードの開始命令を利用することで和欧間のスペースは自動化されていました。わざと個別に和欧間に四分スペースを挿入する場合でもそれはワードスペースSPとは区別されました）。私にはなぜ和欧間にスペース文字を入れる必要が生じているのかが良く分かりません。それはEPUBの問題なのでしょうか。私の考えが間違っていたらご指摘ください。
>>> 
>>> 山本
>>> アドビ
>>> 
>>> From: 田嶋　淳 <tajima@sanyosha.co.jp>
>>> Date: Sunday, May 30, 2021 at 9:33 PM
>>> To: Yasuo Kida <kida@mac.com>
>>> Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
>>> Subject: Re: 6/1 火曜日のミーティング
>>> 
>>> みなさま
>>> 
>>> お世話になっております。ちょっとまとまった時間が取れず、電書ラボEPUB制作仕様の総ざらいはできていないのですが、一応以下に2点ほど雑誌連載の質問候補を挙げてみます。
>>> 
>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> ・EPUB電子化で「二倍ダーシ」をどう扱うかという点についての質問です。InDesignのデータ上ではU+2014のダーシを縦200％変形して使用している例が多いのですが、EPUBでは文字の変倍はできません。また、U+2014やU+2015（ホリゾンタルバー）は日本語フォントの縦書き配置では左右中央に来なかったり2つ繋げた際に間が空いてしまったりすることがあり、またEPUBではコンテンツ側での詳細なフォント指定が難しかったりもするため、やむを得ず現状はU+2500（罫線素片）を使用したりしています。これは本来的にはどうあるべきでしょうか？
>>> 
>>> ・EPUB上での和文・欧文間のアキについての質問です。DTPでは和文・欧文間のアキは自動で入り、カスタマイズでアキ量も調整できたりするため手動でいちいち入力する必要はないのですが、EPUB化するとアキは消えてしまうため場合によってはスペースを入力しなければならなかったりします。作業量およびコードの可読性維持を考えると現状では半角スペースを入れる形になってしまっているのですが、これは本来的にはどうあるべきでしょうか？
>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> 
>>> いかがでしょうか。ちょっと懸念しているのは、今現在の作業負荷を考えるとわかっていてもできないことはあるので、そのあたりが読者に伝わるようにはしておきたいなというところです。
>>> 
>>> 
>>> 
>>> 
>>> 2021/05/28 12:40、木田泰夫 <kida@mac.com>のメール:
>>> 
>>> JLReq TF の皆様、
>>> 
>>> 次回ミーティングは週明け火曜日 6/1 10:00 からです。
>>> https://www.w3.org/2021/04/jlreq-meeting-info.html

>>> 
>>> お題は
>>> ・GitHub 活用について（軽く）
>>> ・簡略化クラス & Unicode 拡張の wrap up（軽く？）
>>> ・「字間のため（だけ）のクラス、簡便化案」参照。だいたい終わり
>>> ・クォーテーションマークがなやましげ
>>> ・リーダー、ダッシュ類などの検討がまだ。別コードポイント or バリエーションシーケンス欲しい？
>>> ・ドキュメントにする
>>> ・行の折り返しの JLReq vs Unicode の比較がまだ
>>> ・
>>> ・デジタルテキストの日本語組版について、雑誌連載の話（本題その１）
>>> ・『「印刷雑誌」連載企画書』、スレッド参照
>>> ・企画会議など議論をどこでやるか？
>>> ・JLReq 次期バージョン（仮称）への筋道（本題その２）
>>> ・内容となるものが集まってきたと思っています
>>> ・がどんな内容が含まれるべきか
>>> ・JLReq の新バージョンとなるのか他の形なのか、はもっと進んでから考えてもOK?
>>> 
>>> 全部はカバーできそうにないですね。
>>> 
>>> 
>>> 
>>> 前回までのお話し
>>> フォント分科会が間に挟まったので、ちょっと思い出しましょう。前回4/27のミーティングとその後の議論の簡単な recap です。
>>> 
>>> 簡略化クラスについての議論を進めてきました。だいたい終わり。「字間のため（だけ）のクラス、簡便化案」のスレッドを参照してください。前回とそれ以降のメールで下のような議論がありました。
>>> 
>>> 日本語組版の文字クラスはグリフベースであるべきではないか → ギリシャ文字などは全角かどうかでレイアウトが変わり、簡略化文字クラスが E vs Fで変わってくる、という問いがきっかけ。しかし石井さんによると技術的に難しめのようです。もしこれが非常に重要な問題ならなんとか方法を見つけて開発者を説得するところですが、問題がギリシャ文字程度なら運用でカバーの方が良さそう。そういう結論で OK？
>>> 
>>> デジタルテキストの印刷と異なる作法についての議論があり、小林さんの提案により雑誌連載の構想に結びつきました。次期 JLReq の内容にもなります。メールの下に小林さんの提案書。”「印刷雑誌」連載企画書“ スレッドを参照してください。こんなお題が出ています。
>>> ・ラテン文字や数字、ギリシャ文字など全角ではなくて本来の文字を使うべき
>>> ・括弧類の前後のツメ → もっと具体的な問題として
>>> ・印刷標準字体の再現は可能でしょうか → ちょっとなあ（by 小林さん）
>>> ・現状電子では和欧間のスペースが自動で入らないのですがこれはどうしておくべきでしょうか？
>>> ・和文と欧文書体の合わせ方
>>> ・和欧間のスペース
>>> ・欧文を正立させるのにふた通り（tatechuyoko / text orientation) があるがどちらを使うの？
>>> ・『電書ラボEPUB制作仕様』http://densholab.jp/page-29/page-70 ここは今は諦めてほしい部分のリスト
>>> 
>>> 木田
>>> 
>>> 【企画意図】
>>> 電子組版のページネーション現場では、活版や写植時代の伝統を、技術的な制約のためにやむを得ず行われていた方法も含め、墨守することを求めるクライアントへの対応に、苦慮する場合が多々見受けられる。
>>> JLreq FTでは、木田泰夫議長の下、JIS 4051のエディターであり、W3Cの技術ノート「日本語組版処理の要件」の主要執筆者でもある小林敏を中心に、電子時代の望ましい日本語組版処理の問題を議論している。
>>> 今回の企画は、このJLreqの議論の中から、電子組版の現場で活動しているJLreqメンバーT氏（敢えて名を伏す）が、実際に直面したクライアントからの《無理な注文》を糸口として、電子組版処理のありうべき姿と、それを実現するための技法を、いわばおばあさんのレシピのような形で紐解いていく。
>>> この連載を継続して読むことにより、最終的には、日本語電子組版のリテラシーといったものが身につくことを目指す。
>>> 
>>> 【記事の構成】
>>> T氏からの相談を契機に、小林敏氏が、日本語組版の伝統を踏まえた上で、それを墨守するのではなく、また現在の技術的な制約に囚われることもない、電子時代にふさわしい解決方法を示す。
>>> 毎回、AdobeでIn Desingの開発に携わっているNatが、現状における技術的限界と解決への方向性についてのコメントを付す。
>>> 
>>> 【当面考えられる内容】
>>> ・和欧混植の問題を巡って（その1）縦組みの時、ラテンアルファベットには全角欧文があるので、それを使えばいいが、ギリシャ文字が入ってきたときには、どうすればいいの？クライアントに、ギリシャ文字も全角にしろって言われて、困り果てています。ウルウル。
>>> ・和欧混植の問題を巡って（その2）CSSとかの規則では、和欧文間スペースは4分アキが金科玉条となっていますが、空きすぎではありませんか？
>>> ・算用数字を横組にする際、一けたは全角、二けた以上は半角みたいな使い方をする例が散見されますが、これってどうなのよ。
>>> （以下、適宜追加してください）
>>> 
>>> ***************************************
>>> （株）三陽社
>>> 　メディア開発室
>>> 　http://www.sanyosha.co.jp/

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

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

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

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

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

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

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