- From: Kobayashi Toshi <binn@k.email.ne.jp>
- Date: Mon, 26 Feb 2024 10:01:30 +0900
- To: 木田泰夫 <kida@mac.com>
- Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
木田泰夫 様 みなさま 小林 敏 です. 詳細は,明日(27日)に議論するとして,とりあえず,コメントしておきます. 木田泰夫 さんwrote >> 3 日本語組版と文字 >> 3.1 日本語組版で使用する文字 >> 《なし》 >使用する文字については2章「日本語デジタルテキストの作り方」でカバーしています。 >この第3章で説明すべき追加事項はあるでしょうか? 第2章で記述すれはいいことで,念のために建てたもので,削除してよい >> 3.2 日本語フォントの要件 >> 《なし→Natさん》 >これは読者も限られますので、別の項を立てた方が良いかもしれません。 Natさんのフォントに付加される情報には何があるかは興味にあることで,どこに置くかまよったものです.忘れるといけないのいで,書いたものです. >> >> 3.3 大きい又は小さい文字サイズの問題 >> 《2.3.2 サイズの異なる文字への対応》 >とすると、これがちょっと浮いてきちゃいますね。 どこか迷ったもの,どうするか作業する中で決まってくるのかな. >> 4 日本語組版における縦組と横組 > >横組縦組の説明に下のようなアプローチがあるかと思います: >A. この案のようにまず縦組と横組の違いを説明する >B. 2章の構成のようにまず横組を基本にして説明し、後に縦組での変更点などを説明 >する項目を立てる >C. 横組でもない縦組でもない論理的な説明を行い、後に、 横組縦組に落とし込む > >デジタルでの多くの応用が横組ベースであり、縦組を行う場合でもまず横組でデータ >を作っていることが多いであろうことを考えると、まずは横組を説明し、そこから縦 >組を実現するための変更点や問題点を含め、縦組を説明した方が実用的かと思います。 >いかがでしょう? 縦組は,そのまま横組にしても,例えば,漢数字は,数字として認識がやや劣るとしても読むという点では,問題はでない.その意味では,横組のものを縦組する場合に問題が多く出る.という意味ではBでよい. >> 5 デジタルテキストの行組版処理 >> 5.1 ベタ組・アキ組・ツメ組 >> 《2.3.1 字間の処理》 >> *ベタ組以外にアキ組とツメ組がある >> 5.2 全角の定義の変更 >> 《2.2 “全角”という用語の定義の変更》 > > >・全角の定義は5の最初でなくて大丈夫ですか? ちょっとまよったところ. >・また、「変更」という言葉はここでは不要だと思います。変更したかどうかはこの >ドキュメントから入る人にはある意味どうでも良い問題ですし、え、変更って?と混 >乱させてしまうかと。変更したという情報は必要な背景情報だとは思いますが、side >note 的にカバーするのはどうでしょう? そうしましょう. >> 5.3 文字クラス >> 《2.6 文字クラスの変更と簡略化》 >> 《Unicode に拡張した字間プロパティの設計》 > > >文字クラスは、必要なレイアウトの実装のための道具ですし、また統一的な文字クラ >スはもはやなく、現象現象ごとにバラバラですので、ここで陽に説明せず、付属書で >はどうでしょう。 文字クラスについては,詳細は附属書にして,本文で詳細を説明しなくてもよいが,なにがしか触れておく必要があることと,仮想文字クラスは,本文で説明しておく必要はあるように思います. >JLreq / CSS でカバーされている機能が、それぞれにカバーされている必要がありま >すね。 >・連続約物の間の空間の取り方(Appendix B) >・行頭行末の空間の取り方(Appendix B) >・文字間での分割の可否(Appendix C) >・行の調整処理で詰める処理が可能な箇所(Appendix D) >・行の調整処理で空ける処理が可能な箇所(Appendix E) >・和欧間のアキ > >それぞれの機能において、非常に重要である場合(三点リーダ二つの間での分割はダ >メ)、議論のある場合(アクセシビリティを考えた時、本当に拗音を分割していい >の?)、ある意味どちらでも良い場合(絵文字と英字の間に空間は必要か?)、があ >るでしょうから、画一的に示すのではない方法があればいいなと思っています。 “画一的に示すのではない方法”を考える必要があると,私も思います. >> 5.4 問題となる約物の字間処理 >> 《2.4 約物の配置処理》 >> >> 5.5 ラテン文字との混植 >> 《2.13 ラテン文字と和文文字との混植》 > > >本質的な問題ではありませんが、混植、という意識はすでにないかと。 “混植”という用語は,やめてもかまいません. >> 5.6 強調の方法 >> 《2.8 強調の方法》 >> 5.7 行の調整処理 >> 《2.9 行の調整処理》 > >強調が先に来るのはなぜ? 入れるところがなかったからかなあ >行の調整処理は、段落の作り方に密接に関わりますので、段落の作り方の後か、その >周辺に欲しいかもしれませんね。 そうかもしれないが,“行の調整処理”は,まさに行の処理なので,…… >小林さんの言われる意味での、機能的に考えて「注」のやり方をまとめた場所も欲し >いですね。 後で注記の処理はあるので,そこでいいのではないか. >> 6 ルビ処理の簡略化と両側ルビの配置処理 > > >簡略化、という説明は不要かと思います。この中で、いわゆる簡略化された方法をま >ず説明して、また、その際の問題や、より洗練された方法も紹介するのはどうでしょ >う? いいたいとことはルビの処理は,ざまざまあって,どれが正解ということはない.一つの方法であるということ.また,今のテキストでは,複雑な処理も注で書いています. >また、両側ルビは、明に取り上げず、side note で歴史的な使用例の紹介程度で良い >のではと感じます。 ただ,JIS X 4051の処理方法は手抜きの方法で,宿題として思ってきた.私としては,もし考えれば,こんな風に考えられるよということは,どこかに示しておきたい感じもある. >> 《3 ルビ(と行間注)》 以下は詳細 >> 6.1 ルビ処理の簡略化の必要性 >> 6.2 ルビ及び注ルビとその使用 >> 6.3 ルビ及び注ルビの基本的な配置方法 >> 6.4 ルビの配置処理 >> 6.5 注ルビの配置処理 >> 6.6 両側ルビの配置処理 >> 7 分かち組の処理 >> 《2.5 分かち組》 > > >章として分ける? アクセシビリティに統合? その場合、「多様な読者への対応」 >といった言い方も良さげですね。 これも入れる箇所で悩んだものです. >> 8 デジタルテキストの段落処理 >> 8.1 行長と行間 >> 《2.12 行長の設定》 >> 《2.14 どのような行間が望ましいか》 >> 8.2 行送り方向の処理の問題点 >> *Natさんの以前のメール >> 8.3 行そろえの方法 >> 《2.7 行そろえの方法》 >> 8.4 段落区切りの示し方 >> 《2.10 段落の示し方》 >> 8.5 行取りの処理 >> 《2.15 行取りの処理》 > > >この辺りの全体、もしくは非常に基本的な部分(望ましい文字サイズと行長、行間、 >段落の作り方)はもっと前に持って来れないでしょうか? 基本的な部分は、JLReq >での基本版面的な重要性を持っているかと。 全体の構成が, 行処理 → 段落処理 → 見出しなど という流れですが,そこを大きく変えるには,まったく違った構成にする必要があるが,何か考えてみますが,明日には間に合わないかもしれない. >> 9 見出し・注・図版 >> 《なし》 > > >見出しは大きな文字のテキストですが、注や図版はそれとは別個かと感じます。 > >大きな文字の問題として、書体の選び方、字間の問題、行頭位置の揃え方(漢字が最 >初の文字である場合と、英字が最初の文字である場合でガタガタに見える)、などい >くつかカバーすべきことがありそうです。 ここは,原稿もないし,適当においてもの. >> 10 読みやすさとアクセシビリティ >> 《6. 読みやすさとアクセシビリティ》 >> 11 デジタルテキストのテキスト処理 >> 《なし》 >> *原稿の準備 >> *検索の問題 >> *データのマルチユースとコピーペースト > >上記二つ、基本的情報はこのドキュメント全体にわたって各項目(デジタルテキスト、 >縦書き、ルビ、などの項目)にも書いておくべきかと思いますが、改めてまとめるの >は良いアイディアだと思います。 > >木田
Received on Monday, 26 February 2024 01:04:07 UTC