- From: Atsushi Shimono (W3C Team) <atsushi@w3.org>
- Date: Mon, 28 Aug 2023 17:13:23 +0900
- To: 木田泰夫 <kida@mac.com>, Tatsuo KOBAYASHI <tlk@kobysh.com>
- Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-ID: <4fa9cad0-240b-4451-956c-69449f1a99b8@w3.org>
shimonoです On 2023/08/28 13:15, 木田泰夫 wrote: >> Natが繰り返し主張していることは、スクロールモデルにおいても、上下左右のマージン主導による基本版面サイズの設定ではなく、基本版面サイズをフォントサイズと行間スペースの《整数倍》に設定し、その後に、上下左右のマージンサイズを動的に決定するべきである、ということではないか。 > > この手順の差が具体的にどのような違いになって現れるのか、の理解こそが重要ですよね。単に手順が違うだけでは、別のやり方でもできるよね、で済んでしまいます。 山本さんの返信メールにもありますが、版面サイズというよりは、中に入れるグリフの扱いの 問題がメインなんじゃないのですかねぇ。 手順が違う、という話については、最近のサイトでは、本文の幅を決め打ちにして、画面サイ ズが変わったらそれより外側のマージンのサイズが変わる、というようなCSS設計もかなり普通 になってます。たとえば、FacebookやTwitterのウェブサイト版もUGCの部分の幅はある程度以上 の画面幅では変わらないはずです。逆に、広い画面だと両脇の空白が非常に大きくなって微妙感 はありますが・・・。 例えば、中央のコンテンツ領域を40emで決め打ち設定して、外側をautoにすれば(autoという よりは中央配置にするという設定になると思いますが、、)外側がやたら広くなる可能性がある とかを除けば基本版面のような概念を利用することはできるんじゃないでしょうか。 # まぁ、font-size: 2vw, margin-inline: 5vwとかで、フォントサイズを画面幅の2%、両脇5%ず つマージンとかもできなくはないですが、、小数点以下のフォントサイズもある程度は効くはず なのでうまくいく、かな? たぶん、ここで一番重要なのは、最後の「マージンのサイズが読みやすさに強く影響」という 概念で、文字数もフォントサイズも決め打ちしてそれに合わせた両脇マージンを考えられるよう な物理サイズがあるのと、どんな画面幅で表示されるかなんて表示されない限り分からないリフ ローでどーするか、なのかなぁ、とは思うところです。。 # マージンを考えられるとは書きましたけれど、敏先生とかの話では実際にはある程度は版面幅 とフォントサイズと文字数って相互にイテレーションしながら考えてる雰囲気も受けましたが。 # ただ、スクロールベースの議論で、上下のマージン、というのが出るのはなんかまだ外形に捕 らわれてる感は残る?? > 違いは結局、行長が全角の整数倍かどうか、の一点に帰着するとの理解で正しいでしょうか。 > > 整数倍にする理由は、そうでないと全ての文字の間に空間が入ってしまうので、活字の場合に生産性が劇的に下がるから、でしょうか。それとも、文字の間に空間が入ること自体でしょうか。前者はデジタルでは無視できるので後者だとして、行が40文字など比較的長い場合には文字間が 1/40 ずつと認識不能な量になるので問題は無く、行長がとても短い場合にのみ問題になると言えるでしょうか? また行頭揃えの場合には整数倍に限る理由はないと言えますかね? > > と、このあたりのことをきちんと理解したいと思います。 例えば、 ・まったく同じ文字列からなる文章をそのままで (この段階以降は処理系は文字列の中身には一切介入できない <= ここが重要) ・いくつかの版面サイズに流し込んで ・すべての版面サイズでの出力で美しく出力する ためには処理系はどうあるべきか?というような状況設定をしてでの処理内容を聞かせていただ く、とかは議論の対象になっているリフローに多少は近い課題設定なのかな、という気はしまし た。 >> その際、マージンのサイズが読みやすさに強く影響することは疑いをえないところではあるが、 > > 確かに他からコンテンツを切り取る額縁としての役割がありそうですね。同時に、マージンを小さくすると行が長くなって、そちらの影響で読みにくい、つまり行長をコントロールするという面もありますかね? その場合は欧文であっても行長ありきで、結果としてマージンが決まる、という順序になりますね。 > > 木田 > >> 2023/08/28 11:08、小林龍生 <tlk@kobysh.com>のメール: >> >> 木田さま、Nat、敏さま、 >> 小林龍生です。 >> >> Natが以前から、ことあるごとに言っていることが、ちょっと分かったような気がしたので。。。 >> どうも、日本語の組版における基本版面の設計手順と類似した手順が、リフロー可能なデジタル組版でも必要なのではないか、という話。まあ、Natの話がややこしくなるのは、そこに日本語の視覚的文章表現の伝統の中での美意識の問題が絡んでくるからね。 >> 以下は、J従来のJLreqとの比較を前提として、Lreq-dのどこかに入れたらいいのではないか、というメモ。 >> >> <---------------------------> >> 《日本的な》行長と行間の決め方 >> 従来のJLreqでは、2.2日本語文書の基本となる組体裁、2.4基本版面の設計 2.4.1基本版面の設計手順に相当。 >> スクロールモデルにおいても、従来の基本版面設計と同様の手順が必要となる。 >> 従来のJLreqにおける仕上りサイズは、(ユーザー側で設定された)窓のサイズに相当する。また、基本版面は、コンテンツをダイナミックに流し込む実際の領域の大きさに相当する。 >> 仕上がりサイズと基本版面のサイズについては、(ワードやインデザインなどの)欧文組版システムにも、同様な概念が存在する。一般的には(特に行長方向、欧文組版では横方向)のサイズは、仕上がりサイズ(紙の大きさ)に対して、適当なマージンを与えて設定することが多い(本当?>Nat) >> それに対して、和文組版では、基本版面の設計が先行し、まず、一行の行長を本文のフォントサイズの倍数(10ポイント42字など)と設定し、基本版面の幅は、1ページ文の行数(n行)を元に、本文フォントのサイズ(p)と行間の大きさ(s)を元に、 >> p×n+s×(n-1)として決定する。 >> この場合も、マージンは、仕上がりサイズと基本版面サイズの差分から決定される。 >> Natが繰り返し主張していることは、スクロールモデルにおいても、上下左右のマージン主導による基本版面サイズの設定ではなく、基本版面サイズをフォントサイズと行間スペースの《整数倍》に設定し、その後に、上下左右のマージンサイズを動的に決定するべきである、ということではないか。 >> その際、マージンのサイズが読みやすさに強く影響することは疑いをえないところではあるが、これは、コンテンツの提供側(著者、編集者、デザイナー)においても、受容側(閲覧機器、閲覧アプリケーション、読者)においても、それぞれの美意識や背後の環境(ベゼルの色など)によっても、多様に変化するので、《ベストプラクティス》として、どのような手順、値を提案するかは、思案のしどころとなる。 >> >> 2023年8月24日(木) 13:30 木田泰夫 <kida@mac.com <mailto:kida@mac.com>>: >> >> JLreq TF の皆さま、 >> >> 次回のミーティングが来週に迫ってきました。火曜日29日の10時からです。 >> >> 現時点での議題は: >> >> ・Open Font Format のミーティングからのアップデート(木田) >> ・WCAG 2.2 からのアップデート(下農) >> ・jlreq-d 八章「デジタルテキストと印刷の違い」を私が文章にしたものをレビュー(木田:奮闘中) >> >> です。小さいトピック、大きな問題など、議題提案歓迎します。 >> >> 木田 >> >
Received on Monday, 28 August 2023 08:13:30 UTC