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

> この問題、例の九つの「本当はコードポイントが必要なんじゃない？疑惑」の文字全体の問題とも関わりますね。今日その話を先に話し合いましょうか？


Recap すると、問題点はこれらのコードポイントの文字はデバイスの日本語環境や、和文フォントを指定しても欧文用のグリフが出てくることが多い。和文用はどうやって使うん？　ということです。

議論では、別コードポイントがあってしかるべきでは、という意見も出ました。が、字形が異なるだけでは Unicode の別のコードポイントとはなりません。そこに用法（つまり意味）や挙動の違いはあるでしょうか？

詳しくは4月初めの「議論の必要な文字9つ」のスレッドを参照してください。


> 2021/06/01 7:53、木田泰夫 <kida@mac.com>のメール:
> 
> この問題、例の九つの「本当はコードポイントが必要なんじゃない？疑惑」の文字全体の問題とも関わりますね。今日その話を先に話し合いましょうか？
> 
> AJ1 は二倍三倍ダーシなどのグリフは持っているんですっけ？　U+2014 EM DASH の二倍三倍のコードポイント U+2E3A, U+2E3B がありますね。
> 
> 木田
> 
>> 2021/06/01 4:58、Nat McCully <nmccully@adobe.com>のメール:
>> 
>> 追伸：
>> https://twitter.com/works014/status/1396070995300032512?s=20

>> 
>> http://works014.hatenablog.com/entry/20160410

>> 
>> <image001.jpg>
>> 
>> 
>> From: Nat McCully <nmccully@adobe.com>
>> Date: Monday, May 31, 2021 at 12:29 PM
>> To: 田嶋 淳 <tajima@sanyosha.co.jp>, Yasuo Kida <kida@mac.com>
>> Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>, Taro Yamamoto <tyamamot@adobe.com>
>> Subject: Re: 6/1 火曜日のミーティング
>> 
>> 田嶋さま、木田さま、みなさま
>> 
>> U+2014, U+2015についてですが、以下はインデザイン開発のときに気づいたことです。これらのコードポイントはいろんな問題はありますが、その問題をワークアラウンドしたら、また他の問題が発生したので、結局解決方法も複雑です。
>> 
>> 入力の問題：
>> IMEやキーボードからの入力では、em-dashは ‘-‘ キーを打ちますが、MacではU+2014は入力されるのに対してWindowsではU+2015が入力されます。これはSJISからの変換の問題からであって、詳しくはhttp://blue-red.ddo.jp/~ao/wiki/wiki.cgi?page=Java+%A4%CE+MS932%2C+Cp943C%2C+SJIS+%A4%CE%B0%E3%A4%A4をご参照ください。Authoring platformのbackwards compatibility対策によって入力されるUnicodeが違うというのは、結局字形に依存する問題も発生されます。
>> 
>> SJISの0x815Cの「―」の字形ですが、これは日本語組版に適しているデザインで仮想ボディーの中央に来ていて、縦組み用の切り替えもあり、幅はいっぱいに来ているので二倍ダッシュの時は２つ連続して配置すれば済みます。さて、Unicodeフォントの時、U+2014とU+2015とで、どちらが標準字形として日本語用のデザインを持ちますか。どちらが欧文用のem-dashにしているのか。しかも、Unicodeのnameを見てみると、U+2015が「horizontal bar」で、U+2014が「em-dash」。Horizontal barはそもそも縦組み用の時はたて？　Em-dashは、幅はいっぱいのはず？　さー。開発者は混乱。IME入力の問題を頭に入れておいて、Mac/Winの標準字形はそれで決まってしまいますので簡単なことではありません。Macを最優先にすればU+2014を日本語用にしますが、Winユーザはそれで欧文様のになってしまいます。フォントメーカーはそれぞれ標準字形を決めてしまいます（みなは大体AdobeJapan1のパターンで行くかと思いますが）。
>> 
>> OpenTypeで解決：
>> 上の問題はGSUBでなんとなくコントロールできます。それに、２倍ダッシュは字形として提供もできます。ただ、入力は簡単ではないし、プレーンテキストではフォントデータと機能を必要とします。
>> 
>> これはやはり、ちゃんとした日本語組版にするには、フォント機能も必要なケースですね。
>> 
>> 
>> ナット
>> 
>> 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/
>> ***************************************
>