Re: 縦組のドキュメントのスクロール方向のドラフト

　shimonoです

　random reply状態ですみません、、、、（いまだドタバタ中、、、

On 2025/09/30 8:48, Yasuo Kida wrote:
> 下農さん、例をありがとうございます。
> 
> この辺り、どう解決しているんでしょうね。文字がどこまで伸びるのかはフォントや文字列に依存しますので、レイアウトするまでわからん、ということですよね。静的な値を取ろうにも、例えばフォントの属性から最大値なりを取ってしまうと、Unicodeフォントなどは大変なことになりそう。

　字送り方向の配置、shapingとか含めて、はharfbuzzの（ような？？）ライブラリが行って
いる、というのがここでのざっくりとした理解だったと思います。フォントのオプションとか
もろもろ設定して戻りを行長と比較してとかのイテレーションを行う、みたいに。
 が、その際に行送り方向について明確な議論がどうなったかというのはちょっと記憶がない
です。。まだ難しい問題が多いよね、というようなうっすらとした覚えはあります・・・。


> 昨日の話の私の理解は：日本語ではボディの端を基準としたマージンを設定したいことがある、とういことですね。あらかじめ与えられた領域があって、その中に文字が流れ込んでゆく場合、つまり例えば普通のwebでの場合は下端は成り行きになります。つまり視覚上のマージンは、設定されたマージン以上に広くなります。
> 
> ボディの下端を基準としたマージンを設定したい場合は、領域の高さ（横書きの場合）とフォントサイズ＆行間、が相互に関係します。つまり基本版面ですね。領域の高さを、フォントサイズ＆行間を単位として決められれば技術的に可能。

 この2パターンについては、InDesignみたいな版面デザインと、（理想条件下においてかも
しれませんが）同じく事前計算結果をもって調整されたWeb/CSSでの設定値、の2つの間では同
じ、ですが 1) 結局はいつreflowが起こるかわからない状況下ではそんな理想状態になるわ
きゃない、というのが問題。 2) で、現状の行送り方向のbaselineとbaseline skipをベース
にするものでなく、CSS rythmみたいな基本版面の計算をベースにして全体的な値、baseline
skipを含めて、を計算で落とし込んでいって調整するような逆アプローチの機構が必要でearly
draftの提案は出ている。3) しかし、既存との整合性などを含めて議論が錯綜してきちんと検
討・仕様策定を継続していける段階までまだ達していない。
　という理解です。(で、正しいですよね・・・？)

# 版面サイズに相当する直接接するブロック要素の縦横サイズ（や画面サイズ）がユーザ環境
に合わせて可変である、というのもありますが、どちらかというと（CSSとかで固定されていな
い限り？）自分のブロックが欲しいサイズを出してそれをもとに周囲と調整していく必要もあ
るという、リフロー的な観念と相性が悪すぎるというのも大変なところなのかなとは思ってい
ます。。



> もちろん、文字列に上下に長いスクリプトの文字が混じっていたり、ルビの上に圏点があったり、などの撹乱要素があると狂ってきます。が、内容固定のものならOK。
> 
> 木田
> 
>> 2025/09/29 23:32、Atsushi Shimono (W3C Team) <atsushi@w3.org>のメール:
>>
>>  shimonoです
>>
>> 　今日の編集会議で、ここら辺の行送り量とか最終行が収まるかの議論があって、何らか
>> のはみ出るような事象はあるのか？という話がちらっとありましたが、そこまでの問題は
>> なさそうかな、ではありますが、多少の影響は出るのかなという例はあるのかも？という
>> 気はしました。
>> https://jlreq.w3c.himor.in/20250929-javanese.html

>> 　上の方が上下に長く伸びるという例示でよく使われるJavaneseですが、黒枠がspanで囲っ
>> た、赤枠がそれを含むdivやpで囲ったものになります。下の方に同じマークアップでラテ
>> ン文字とアラビア文字のサンプルを入れてあります。（これらを含め、ほかの文字種で同
>> 様の事例は発見できてません）
>> 　spanのborderを文字が突き抜けるのは仕様上どうなのかというのはちょっと調べきれて
>> ないのですが、こういうこともあり得る、という一例まで。
>>
>> 　ただ、gap-analysisの方には特に何もなさそうではあるので、仕様内なのかもしれませ
>> ん。。。
>> https://w3c.github.io/sealreq/gap-analysis/java-gap#h_lines_and_paragraphs

>>
>>
>>
>> On 2025/09/18 9:10, Kobayashi Toshi wrote:
>>> Yasuo Kida　様
>>> 　小林　敏　です．
>>> “6.4　縦組のドキュメントのスクロール方向”は，たぶん，以下だと思う．Githubの“Discussions”の“JLReq-d 編集会議 2025-3-27”に記事があった．
>>> -------以下が6.4のドラフト--------
>>> 縦組みにおけるマルチカラムの必要性（4章の一部）……この部分は削除
>>> 縦スクロール前提のUIと縦組表現の適応……この部分は削除
>>> 6.4 縦組のドキュメントのスクロール方向
>>> Webサイトやスマートフォンの多くのユーザーインターフェース（UI）は、縦スクロールを前提として設計されている。例えば、広告配信の仕組みや配置は縦スクロールを前提に構築されており、コンテンツが縦方向に連続して並ぶ構造が一般的である。
>>> また、CBT（Computer Based Testing）においては、国語の問題を縦組、理数系の問題を横組で表示することが想定されるが、受験番号やナビゲーションなどの共通インターフェース部分は横組で統一されることが多い。さらに、スマートフォンでは、横方向のスワイプ操作に特定の機能（ページ移動やメニューの呼び出しなど）が割り当てられている場合もあり、インターフェースの構造上、縦方向の流れが基本となっている。
>>> このように、著者または読み手が達成したい読みの方法は柔軟であるべきなのに対して、そのテキストが置かれる環境は縦スクロールから変え難いことが多い。
>>> 縦スクロール主体の環境では、横幅は環境によって固定であり、コンテンツは縦方向にのみ伸びることができる。このような縦スクロール主体の環境において、縦組コンテンツを適切に表示するには工夫が必要である。縦組の文章は、リフローさせた場合、横方向に伸びてしまうという特性がある。そのため、縦スクロール環境においては、縦組を複数の縦列（段）に分割して縦方向に並べる「マルチカラム」方式が有効な解決手段となる。これは、縦組の可読性を保ちつつ、縦スクロール中心のユーザー体験に適応させる方法である。
>>> マルチカラム方式を実現するためには次のような処理方法が必要になる。
>>> - 画面に対する行長の制御：一行は画面をスクロールしなくても読める長さが望ましい
>>> - 行長の制御。和字で最小10文字、最大40文字程度が読みやすい。
>>> - カラム間は最小1字から2字開ける必要がある。
>>
>