Re: JLReq and Gap Analyses

皆さん、

基本版面という考え方は活版になって初めて出現
したものでしょうか？それとも、似た考え方は木版
や肉筆のころからあるのでしょうか？

村田 真

2019年6月18日(火) 10:09 Kobayashi Toshi <binn@k.email.ne.jp>:

> Nat McCully 様
>
> 小林敏です
>
> 基本版面の問題について，すいませんが日本語で少しコメントして
> おきます．
>
> 以下の内容を十分に理解しているか不安ですが，たしかに，基本版
> 面はWebでは必要なのか，必要でないのか，必要でないなら，基本
> 版面としての機能は，すべてなくてよいのか，基本版面の持ってい
> る一部の機能は，それを必要としないWebでも必要とするのではな
> いか，ということだろうと思います．
>
> 基本版面の持っている主な機能，役割としては，以下があります．
>
> 版面サイズを規定する．それにより各ページの版面がそろう．
> 全角文字を並べていく（字詰め方向の文字の配置）際に，ベタ組で
> 文字サイズ整数倍の行長を維持できる．
> 文字サイズと行間についても，整数行の配置し，版面サイズに半端
> がでないようにする．また，特に本文とは違った組体裁のものが入
> らない限り，行が紙面の同一位置に配置できる．
> 本文とは異なった配置方法の要素（見出し，図版，表，注など）を
> 配置する場合の，その大きさ，配置位置の基準ともなる
>
> 特に，3番目の問題は，日本の紙は，一般にうすいというか，裏面
> が透けて見えることもあり，紙面の両側について，同一位置に行が
> あると，そうした裏面（裏面からいえば表面）の文字が透けても，
> 行が同一位置にあることにより，ある程度，その問題が回避できた
> からです．（この問題はWebでは，まったく考える必要はありませ
> ん．）
>
> 以下は，Webではどう考えるかという問題です．
>
> 字詰め方向の文字を配置する場合，行頭そろえにするのであれば，W
> ebでの文字配置領域のサイズは自由です．しかし，行頭行末そろえ
> （ジャスティファイ）する場合は，配置する行長は，文字サイズの
> 整数倍にしてほしいという問題は残ります．（この問題は図や表を
> 配置した場合に，回り込みの際の行長をどうするかという問題でも
> あります）．
>
> また，行長が可変となった場合に，そこには限界はないかという問
> 題も，Webでは出てきます．日本語についていうと，40字を超える
> 行長は，読みにくくなります．
>
> 行送り方向については，行中に文字サイズが異なる，ルビが付く，
> 圏点が付く，小さい（逆に大きい）文字サイズが挿入された場合に
> どうするか．そこには，基本版面で設定した行位置をできるだけ維
> 持するということを，基本版面の機能として要求していますが，こ
> れは可変なWebでは，どう考えるか．一般的にいえば，デフォルト
> である文字サイズと行間は維持するということで，これはWebで必
> 要か，という問題かと思います．私の読書経験では，行間が乱れて
> いると，読むことは可能でも，ちょっと違和感を感じ，これは何か
> 意味があるのかな，という余分な意識を働かせるので，望ましくな
> いと考えています．
>
> 上記の基本版面の4番目の機能は，Webでどう考えるか，それが一
> 番大きな問題のように思います．いくつか問題例をあげておきま
> す．
>
> 段落途中に挿入される文字サイズを小さくし，行間も狭くした注
> 記，あるいは引用文が挿入される場合，その前後の行間をどう処理
> するか．これは，DTPでも，いつも苦労しているのですが，指定し
> たアキがどう機能するか読めないので，いつもテストして処理して
> います．ここは，行間で指定する，行送りで指定する，line height
> で指定する，グリッドで配置位置を決める等，それらによっても異
> なるだけでなく，それぞれの振る舞いがよく分からないという問題
> もあります．
>
> 見出しの配置位置を，特に行送り方向の領域を行ドリで指定すると
> いう便利な機能はどう考えたらよいか．これはグリッドで解決する
> のか．
>
> 文字サイズや字詰めが可変となると，それに応じて行間も可変であ
> ってほしい．その指定はどうしたらできるのか．
>
> 表や図版の配置位置の基準はどこか．これはグリッドで解決できる
> のか．問題は2つあり，表や図版の配置位置をどうするか（これは2
> つあって，図版のサイズや配置位置を決める目安になること，ま
> た，実際に配置する際にどこが基準となるかということ），という
> 点と，その周囲に配置する文字の配置位置をどうするかという点で
> す．
>
> なお，基本版面で決めた行送り方向の版面の幅は，できるだけ維持
> するという機能ですが，これは途中に異物が入った場合の版面サイ
> ズをそろえる処理（いってみれが字詰め方向の行長の調整処理と似
> ていて，行送り方向のサイズの調整処理といえる）の問題（これは
> コンピュータ組版でもDTPでも問題が解決されていません）は，We
> bでは，そろえることそのものの必要性は少なくなりますので，異
> 物の前後のアキが設定できればよいことになります．
>
> 以上です．
>
> Nat McCully さん wrote
>
> > Colleagues -
> >
> > Kida-san asked me to forward some thoughts to the list, that we were
> discussing on a private thread, in case it would be useful for all to
> consider...
> >
> > In the last F2F meeting of the JLReq TF, the group was discussing the
> charter of making sure that the Gap Analysis is complete, and how to test
> the current implementations of JLReq requirements.
> >
> > In reading through the JLReq once again with this in mind, I am struck
> not only by the wealth of information of print publishing as it has been
> done at the highest level on proprietary systems and in Desktop Publishing;
> but also how it clearly was written from the point of view of the expert in
> Japanese typography and layout.
> >
> > It is the intent of the document to be a key source of truth for the
> implementer of text layout engines; but for those authors who are less
> familiar with Japanese, much more has to be explained for them truly to
> understand and prioritize the information in JLReq.
> >
> > An example of what I mean: Several pages are devoted to the Kihon
> Hanmen, yet for the expert, I feel the Kihon Hanmen is so core to the
> management of space on the page, and the fact that it derives its
> dimensions from the em-bodies of body text so obvious, that its true
> context and importance is lost on the neophyte. It may appear to be a relic
> of print publishing, something only used for static paged material,
> something used only to speed up production and assure a staid consistency.
> What place
> > has such a thing in the world of reflowable, dynamic documents? Perhaps
> it can be ignored altogether?
> >
> > In my opinion the central role of the Kihon Hanmen is overlooked because
> it has not been explained properly from the context of how it advances the
> basic control of white space in the design, and that its interplay with the
> text on the design is so central to how the balance of white space and
> content in the design is achieved. Japanese text, being largely square and
> often monospaced, is grid-like in that it evokes two axes for the eye to
> latch upon in looking at and navigating a design. The esta
> > blishment of a basic grid, that is essentially text-based, is not
> unique. However, the way other objects are placed on the design in relation
> to this text grid, and the use of the grid or grids to determine optimal
> placement, seems to me to be an under-served aspect of Japanese graphic
> design--especially when it comes to responsive layout and automatic reflow.
> >
> > It is my hope that we revisit how the JLReq sets the context of its
> trove of information so that these "obvious to the authors" concepts are
> more fully fleshed out for the neophyte to understand.
> >
> > As for the Gap Analysis and Tests, I hope that they can serve the role
> of showing not only which CSS properties have been created to solve the
> problem of a lack of support for basic Japanese layout needs; but also to
> show if basic and more advanced layout can actually be achieved using them,
> across the major Web rendering stacks. The value of the Gap Analysis goes
> up when it can show not only that a given CSS property exists, but that the
> property can be used to achieve a representative use case
> > for the feature. We probably need to review the existing tests to make
> sure they can show this.
> >
> > The Web is changing faster and faster, and so for new CSS properties
> under review or discussion, we should draw up a set of tests that
> essentially make sure the property will fulfill its promise for the
> Japanese use-case, as it makes its way from draft to
> implemented-in-all-browsers finality, to aid in its utility for the
> originally intended use-case.
> >
> > --Nat
>
> ―――――――――――――――――――――
> 小林 敏（toshi） 2019年 6月18日
> e-mail: binn@k.email.ne.jp
> ―――――――――――――――――――――
>
>

-- 
Regards,
Makoto