Re: 第3章以降の目次案

敏先生ありがとうございます！

以下インラインで：

> 2024/05/09 13:27、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
> 
> 木田泰夫　様
> みなさな
> 
> 　小林　敏　です．
> 
> 参考として，第3章以降の現時点での目次案をお送りいたします．第2章の内容により，変更される事項もあるかと思います．
> 
> 3 日本語デジタルテキストの組版処理
> 
> 3.1　日本語デジタルテキストの組版処理の特徴

第一章で長々とデジタルテキストはどこが違うか書いておきながらですが、次のような観点はどうだろう、と思う気持ちがちょっとあります。つまり：

以降の章は、しれっと、ずっと以前からデジタルテキストでしたよ、という顔で説明する。なぜかというと、今からの人にとって、テキストを読むということが、生まれた時からデジタルだから。どちらかというと、デジタルを知って、そこからの差分として、印刷を知る、という方向でしょう。へー、こうだったんだ、と。

反面、jlreq-dのできた当初は、どこがJLReqと違うのよ、という気持ちで見る人も多いと思われますので、違いはどこか、をまず持ってくる構成は合理的です。まずはこのような構成で書いておいて、20年後にjlreq, jlreq-dの後継になるような新しいドキュメントができるときに変えれば良いかな？ こちらのアプローチの方がやはり良いですかね。

> 　＊ここでは，JLReqで対象としている書籍との違いを簡単にまとめて示す
> 　＊以下では，JLReqで対象としている書籍をJLReqといい，デジタルテキストをjlreq-dということにする．
> 
> 主たる解説内容：
> JLReqでは，以下が前提となったいた．jlreq-dでは必ずしもそうではなく，他の方法も選択される．
> —漢字と仮名の文字の外枠は，正方形である
> —漢字や仮名などは，原則としてベタ組にする

この原則は、フォントがデフォルトの字間をベストとして作られている限り、やはりベタ組が原則なのかなと思っていますが、どうでしょう？　英文でも、文字間を広げるのは最後ですよね。ここから、行長を全角（必ずしも正方形でないバージョン）の整数倍にできて欲しいという要求が出てきます。

> —本文の段落は，行頭・行末そろえとする
> —基本版面を設定し，それを参照し，それをできるだけ維持する（問題としては，特に行取りの処理をjlreq-dでは考えなくてもよい）

ページを前提とするからですね。巻物ではその前提が全然違ってくる。

また、基本版面という用語に、はてな？と思う読者が多いと思いますので、「基本版面＝ページのテンプレート」と説明すると今の人にとって、ああ！と思えると思います。

> 以下，考慮すべき問題を示す
> 
> —jlreq-dでは，表示が一定しない
> 　→デバイスの違い，読む人により表示倍率，文字サイズなど変更可能なことが多い．
> 　→使用文字サイズの範囲が大きくなった
> 　→必ずしもベタ組が選択されるわけでない
> 　→行長，行間ではJLReqと変わらないか？

行間ですが、同じポイント数の英文に比べて広い行間が必要、という理解でいますが、これを触れると良いかもしれません。残念ながらデジタルにおいては多くのことが英文基準で作られているので、それじゃだめだよ、と。

> —jlreq-dでは，経済性の考慮は，どこまで考えるか
> 　→JLReqでは，行の調整処理や行長や行間なども，最適というよりは経済性も考慮して決めていた例がある，カラーもかなり費用を考えないで使用できる

確かに、強調の方法として、またルビに、など色の可能性が研究されるべきところは多いですね。その場合、色盲などのアクセシビリティーに十分考慮するべき、との書き添えが必要ですね。

> —JLReqでは，組版処理機能は，ある程度のものを前提としていた．jlreq-dでは，必ずしもそうではない．高機能のものから，そうでないものまである．
> 　→行頭・行末そろえが選択できない場合もある
> 　→字間の処理もベタ組しかできない場合もある
> —jlreq-dでは，文書の目的も多様である
> 　→JLReqでは，長文が前提であるが，jlreq-dでは，必ずしもそうではない．
> 　→文字サイズ，字間処理なども，ベタ組以外の処理も選択される場合もでてくる
> —jlreq-dでは，組方向も変更可能な場合がある
> 　→JLReqでも組方向は決まっていたが，jlreq-dでは，必ずしもそうではない．
> 　→縦組と横組とで，どんな違い，どんな問題が出るか．
> —jlreq-dでは，自動処理の機能を高めて行く必要がある
> 　→再表示が多いことがあり，すべての処理を自動で行うことがの望ましい

ここは望ましいではなく、すべての処理は否応なく完全自動です。もちろん、作成の段階ではWYSIWYGな編集、目で見ての訂正が可能なのですが、それは作成の段階であって、一旦手を離れたら、誰も手出しをできないのがデジタル。

> —jlreq-dでは表示内容を読む際に変更できることもあり，アクセシビリティ等を考慮し，データを加工して表示できることもある
> 　→漢字の読みを示す，分かち書きにする，など
> 
> 3.2　フォントの要件と字間の選択
> —日本語フォントの要件と全角という用語
> —ベタ組・アキ組・ツメ組

オプティカルサイジングに触れると良いですね。

> 3.3　行組版の処理
> 　3.3.1　全角の定義
> 　3.3.2　文字クラスと文字間の処理
> 　3.3.3　問題となる約物の字間処理
> 　3.3.4　ラテン文字の処理
> 　3.3.5　行の調整処理
> 　3.3.6　分かち組の処理
> 　3.3.7　強調の方法
> 
> 4　ルビ処理
> 　4.1 ルビの使用
>  4.2 ルビ処理の簡略化
> 　4.3　ルビの基本的な配置方法
> 　4.4　ルビの配置処理

全体的にそうですが、簡略した方法も、高度な方法も、両方示したいです。その差を見ると、簡略方法は何を省略していてどのような問題があるのか、が見えてくると思います。書き方として例えば、簡略化した方法を示して、その方法での問題を列挙して、この問題の解決にはこうする、というのを問題に対してそれぞれ示して、全体を採用すると結果的に高度な方法になっている、というアプローチはどうでしょう。一気に一塊として高度な方法を示してしまうと、簡略 vs 高度、というゼロイチな選択しかできませんし、なぜ高度な方法が必要なのかも不明確です。問題と解決方法を個別に示すことで、教育になりますし、プライオリティを考えながら一つづつ採用というアプローチが可能になります。どうでしょうね？　ルビ以外の部分でもこれは言えるかもしれません。

> 5 縦組と横組
>  5.1 組方向（縦組と横組）とその変更の必要性
> 　5.2　組方向の変更のレベル
> 　5.3　縦組と横組で字形等が異なる例
> 　5.4　数字の表記と組版処理
> 　5.5　ラテン文字等の処理
> 　5.6　縦組と横組の句読点
> 　5.7　縦組と横組の括弧類
> 　5.8　縦組と横組で注意が必要な行処理等
> 　5.9　縦組と横組で異なる注等の配置処理
> 
> 6　段落の処理
> 　6.1　行長と行間
> 　6.2　行送り方向の処理の問題点
> 　6.3　行そろえの方法
> 　6.4　段落区切りの示し方
>  6.5 行取りの処理
> 　6.6　行長と行間の選択
> 
> 7　見出し・注・図版
> 
> 8　読みやすさとアクセシビリティ
> 
> 9　デジタルテキストのテキスト処理
> 　＊原稿の準備
> 　＊検索の問題
> 　＊データのマルチユースとコピーペースト

これは二章そのもの？

> 附属書A　大きな文字サイズにした場合の字間処理

大きな文字サイズの問題は附属書ではなく、本文で扱いたいです。

例えば、和字は全角の仮想ボディの中にマージンをとって、文字があるので、箇条書きにしたときに英字と先頭が合わない問題。またオプティカルサイジング絡めて、そのまま等倍拡大すると字間が広がって見える問題、など。詰めはオプティカルサイジングがないからそう処理せざるを得ないのだと思います（タイトル用に作られた書体ではどうなっているんでしょう？そのままで良いように作るのか、詰めを前提として作るのかどちらでしょうね）

> 附属書B　文字クラスと字間処理
> 附属書C　文字クラスと分割の可否
> 附属書D　文字クラスと行の調整処理
> 附属書E　両側ルビの配置処理

入れます？　完全自動のデジタルテキストで処理できるなら入れましょう。入れるとしたら本文で。

> 附属書F　注ルビの配置処理

これは本文でカバーするのはどうでしょう。つまり附属書はデータのみ。

木田

Received on Friday, 10 May 2024 00:17:38 UTC