- From: 木田泰夫 <kida@mac.com>
- Date: Sun, 25 Feb 2024 16:57:08 +0900
- To: Kobayashi Toshi <binn@k.email.ne.jp>
- Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-Id: <CDC6EEA8-C965-4697-BC9B-FA876CFDBA51@mac.com>
遅くなりました! フィードバックです。 > 2024/02/13 14:13、Kobayashi Toshi <binn@k.email.ne.jp>のメール: > > 木田泰夫 様 > みなさま > > 少し前にお送りしたメールに誤りがありましたので再送いたします. > *“8.2 行送り方向の処理の問題点”を追加した.それ以外は同じ. > > Kobayashi Toshi wrote > >> 3章以降の目次案を考えてみましたので,ご検討ください. 以降の議論の参考のために、最初の内容の章である2章「日本語デジタルテキストの作り方」の現在の章立て案を書いておきます: 2. 日本語デジタルテキストの作り方 2.1. 日本語デジタルテキストで使用する文字(仮名、漢字、など) 2.2. 文字セット(JIS、AdobeJapanなど) 2.3. 文字の使い方(主に英数字と約物) 2.4 組方向 2.5 日本語入力 この章にはユーザーが日本語のプレーンテキストデータを作るために必要な情報が整理されています。小林さんの提案でこの章ができたのですが、クリアな切り口でスッキリです。 さて、ユーザーが実際にワープロなどを使う場合を考えると、下のような情報もユーザーのために欲しくなります。 ・書体の選択 ・文字の大きさと行長 ・段落の作り方 ・強調の仕方 など。 この程度の簡単なフォーマットなら多くのアプリケーションで可能なのですが、全ての項目を「ユーザーの責任/システムの責任」という切り口で分けようとすると、あるアプリケーションでユーザーが可能なことが、別のアプリケーションではユーザーには変えられない、という場合も多くて、クリアに分けることは難しいように感じました。例えば上記の段落の作り方ですが、Webブラウザでは一字下げが可能ですが、普通のメールソフトでは、先頭に全角を挿入するという望ましくないデータの作り方をしない限り不可能です。 ということで、プレーンテキストを作る以上のレイアウトの話は「ユーザーの責任/システムの責任」の区別なく収めるのが良いのでしょうかね。現時点での第3章以降はそのようになっています。ただ、ユーザーがコントロールできる基本的なレイアウトは早めにカバーできると良いかなと思います。 >> なお,“2.日本語の組み方の詳細”という見出しに含まれる内容は,少し細かい見出しに分解してみました. > 3章以降の目次案 > *《》は,Wikiで示されている見出し名 > *《なし》は,現在,該当するテキストがないことを示す > *記しは,ごく簡単な説明 > > 3 日本語組版と文字 > 3.1 日本語組版で使用する文字 > 《なし》 使用する文字については2章「日本語デジタルテキストの作り方」でカバーしています。この第3章で説明すべき追加事項はあるでしょうか? > 3.2 日本語フォントの要件 > 《なし→Natさん》 これは読者も限られますので、別の項を立てた方が良いかもしれません。 > 3.3 大きい又は小さい文字サイズの問題 > 《2.3.2 サイズの異なる文字への対応》 とすると、これがちょっと浮いてきちゃいますね。 > 4 日本語組版における縦組と横組 > 《2.11 横組と縦組の組版処理》 以下は詳細 > 4.1 組方向(縦組と横組)とその変更の必要性 > 4.2 組方向の変更のレベル > 4.3 縦組と横組で字形等が異なる例 > 4.4 数字の表記と組版処理 > 4.5 ラテン文字等の処理 > 4.6 縦組と横組の句読点 > 4.7 縦組と横組の括弧類 > 4.8 縦組と横組で注意が必要な行処理等 > 4.9 縦組と横組で異なる注等の配置処理 横組縦組の説明に下のようなアプローチがあるかと思います: A. この案のようにまず縦組と横組の違いを説明する B. 2章の構成のようにまず横組を基本にして説明し、後に縦組での変更点などを説明する項目を立てる C. 横組でもない縦組でもない論理的な説明を行い、後に、 横組縦組に落とし込む デジタルでの多くの応用が横組ベースであり、縦組を行う場合でもまず横組でデータを作っていることが多いであろうことを考えると、まずは横組を説明し、そこから縦組を実現するための変更点や問題点を含め、縦組を説明した方が実用的かと思います。いかがでしょう? > 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 で歴史的な使用例の紹介程度で良いのではと感じます。 > 《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 Sunday, 25 February 2024 07:57:27 UTC