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

どちらも良いネタですねー。今から出来上がりが楽しみになります。

> ちょっと懸念しているのは、今現在の作業負荷を考えるとわかっていてもできないことはあるので、そのあたりが読者に伝わるようにはしておきたいなというところです。

これはとても重要なポイントかと思います。この話題単独で取り上げるのもアリじゃないでしょうか。

木田

> 2021/05/31 13:32、田嶋 淳 <tajima@sanyosha.co.jp>のメール:
> 
> みなさま
> 
> お世話になっております。ちょっとまとまった時間が取れず、電書ラボ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 <mailto:kida@mac.com>>のメール:
>> 
>> JLReq TF の皆様、
>> 
>> 次回ミーティングは週明け火曜日 6/1 10:00 からです。
>> https://www.w3.org/2021/04/jlreq-meeting-info.html <https://www.w3.org/2021/04/jlreq-meeting-info.html>
>> 
>> お題は
>> ・GitHub 活用について(軽く)
>> ・簡略化クラス & Unicode 拡張の wrap up(軽く?)
>> 	・「字間のため(だけ)のクラス、簡便化案」参照。だいたい終わり
>> 		・クォーテーションマークがなやましげ
>> 		・リーダー、ダッシュ類などの検討がまだ。別コードポイント or バリエーションシーケンス欲しい?
>> 	・ドキュメントにする
>> 	・行の折り返しの JLReq vs Unicode の比較がまだ
>> 	・
>> ・デジタルテキストの日本語組版について、雑誌連載の話(本題その1)
>> 	・『「印刷雑誌」連載企画書』、スレッド参照
>> 	・企画会議など議論をどこでやるか?
>> ・JLReq 次期バージョン(仮称)への筋道(本題その2)
>>  ・内容となるものが集まってきたと思っています
>>  ・がどんな内容が含まれるべきか
>>  ・JLReq の新バージョンとなるのか他の形なのか、はもっと進んでから考えてもOK?
>> 
>> 全部はカバーできそうにないですね。
>> 
>> 
>> 
>> 前回までのお話し
>> フォント分科会が間に挟まったので、ちょっと思い出しましょう。前回4/27のミーティングとその後の議論の簡単な recap です。
>> 
>> 簡略化クラスについての議論を進めてきました。だいたい終わり。「字間のため(だけ)のクラス、簡便化案」のスレッドを参照してください。前回とそれ以降のメールで下のような議論がありました。
>> 
>> 日本語組版の文字クラスはグリフベースであるべきではないか → ギリシャ文字などは全角かどうかでレイアウトが変わり、簡略化文字クラスが E vs F で変わってくる、という問いがきっかけ。しかし石井さんによると技術的に難しめのようです。もしこれが非常に重要な問題ならなんとか方法を見つけて開発者を説得するところですが、問題がギリシャ文字程度なら運用でカバーの方が良さそう。そういう結論で OK?
>> 
>> デジタルテキストの印刷と異なる作法についての議論があり、小林さんの提案により雑誌連載の構想に結びつきました。次期 JLReq の内容にもなります。メールの下に小林さんの提案書。”「印刷雑誌」連載企画書“ スレッドを参照してください。こんなお題が出ています。
>> ・ラテン文字や数字、ギリシャ文字など全角ではなくて本来の文字を使うべき
>> ・括弧類の前後のツメ → もっと具体的な問題として
>> ・印刷標準字体の再現は可能でしょうか → ちょっとなあ(by 小林さん)
>> ・現状電子では和欧間のスペースが自動で入らないのですがこれはどうしておくべきでしょうか?
>> ・和文と欧文書体の合わせ方
>> ・和欧間のスペース
>> ・欧文を正立させるのにふた通り(tatechuyoko / text orientation) があるがどちらを使うの?
>> ・『電書ラボEPUB制作仕様』http://densholab.jp/page-29/page-70 <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/ <http://www.sanyosha.co.jp/>
>  
>  田嶋 淳
>  tajima@sanyosha.co.jp <mailto:tajima@sanyosha.co.jp>
>  
>  ※ブログ運営中です。
>   ご意見をいただければ幸いです。
>   http://densyodamasii.com/ <http://densyodamasii.com/>
> ***************************************
> 

Received on Monday, 31 May 2021 10:23:37 UTC