3.7.2 振分け処理

　「振分けとは，1行の途中に複数の言葉や文を配置する処理である．複数の選択肢を示す場合などに利用されている．学習参考書，マニュアル，解説書などで使用している例がある．振分けを行う場合，複数の行を括弧類でくくることも多い．」この処理自体は見たことがあるが、「振分け」という用語自体にはあまり聞き覚えがなかった。
　「また，同一の振分け行を複数の行に分割した場合の行間は0とする」ここだけずいぶん具体的な行間表記。
　CSS的にはdisplay:inline-blockで表現自体は可能。上下をブレースで囲む表現が今ちょっと難しそうな感じ（border-imageプロパティでできなくはないが）。

3.7.3 字取り処理

　「日本人名の名簿を一覧にする場合など，行中の文字列の一部について全長を指定する例がある．このような場合に，行中の指定された文字列を，字間を調整して，字詰め方向について指定された長さにする処理が字取り処理である．人名など字数の異なる文字列を指定した一定の長さでそろえたい場合に利用できる．」
　「3.5.3 そろえの処理」に関連情報がある。「○○文字分」という考え方になるところが考え方として違うところか。実際に制作の現場には、「○○字取均等割り」といったような形で指定が来る。
※図173と図174は違う処理の例になるのではないか。項を分けた方が良くないかという指摘があった。
CSS的には前出のtext-alignを参照。

3.7.4 等号類と演算記号の処理

　このブロックは数式組版に関する部分であり、JIS X 4051にはない項目になる、とのこと。
※図176の等号類、演算記号の文字の例が全角になっているのに違和感がある、との指摘。プロポーショナルの記号であるべき。（和欧混植で英文ブロックを和文内に入れる場合には欧文ブロックの中は欧文の組版ルールに従うべき、というのと同種の話か）
※図177、演算としてのマイナス符号と負の値を表す符号がこの例だと判別できないという指摘。和文フォントのデザインに表記が引きずられている？
　「別行式で，2行に分割する位置をある程度任意に選択できる場合は，まず等号類の前で2行に分割するとよい．それができない場合は，演算記号の前で2行に分割するとよい．」に関して、数学方面での書籍組版の常識としては、別行式ではJLReqの記述の通りであるが，行中式（インライン）では式が繋がっていることを示すために等号類や演算記号の「後ろ」で改行する、という指摘あり。また、行中式での改行の記述自体が抜けている、という指摘もあった。

3.8.2 詰める処理と空ける処理

　行の調整処理には空き量を詰める処理（追込み処理）と字間を空ける処理（追出し処理）がある。
　「通常，詰める処理（追込み処理）を優先し，それで処理できない場合は空ける処理（追出し処理）を行う．詰める処理（追込み処理）を優先するのは，ベタ組の箇所はできるだけ空けないという考え方による．」書籍組版などでは空ける処理を優先するケースもある。どちらを優先するかはそれぞれの現場でのルール付けによるものと思われる。
　「a.規定されている空き量を詰める処理（追込み処理）．追込み処理では，読点類又は終わり括弧類の後ろの二分アキや，始め括弧類の前の二分アキ，欧文間隔などの空き量を規定の範囲内で詰める処理を行う．」とある。
　JLREQの規定では欧文単語間のスペースを3分と規定しているが、実際のフォントのデザインでは0.25em程度にしているパターンが多いため、実際にはほとんど詰まらないことになるのではないか、という指摘。
　現在のDTPの組版では、カタカナ、ひらがな類の前後スペースの調整処理なども行われている。これは技術の進展により、より細かな調整が可能になったためと思う。

　また、この項目の注にぶら下げ組の解説がある。ぶら下げはCSSのボックスモデルの例外的な処理を必要とする要素でもあり、1項立てて解説しても良いのではないかと感じた。ちょっとアンバランスさがある。
　「DTPなどでは，このような句読点を3行目のようにぶら下げ組にする処理を行っている例があるが，不必要な処理といえよう．」
　行末の句読点は全てぶら下げた方が綺麗に揃って見えるという意見もある。これを反映してか、InDesignでは段落パレットの指定でぶら下がりの強制、標準、なしを選べる。

CSS:ぶら下がり
CSS text module Level3 9.2. Hanging Punctuation: the hanging-punctuation property
force-endが強制、allow-endが標準。firstは段落はじめの開き括弧などを通常位置より外側にはみ出させる処理。日本語だとあまり見ないが、欧文ではそれなりに多い。段落先頭だけに関連する点がtext-spacingとは違う。lastはそれを行末側でやる処理。
参照：Text Level4 10.1.3. Japanese Paragraph-start Conventions in CSS
括弧類が段落始めに来た際の字下げ量の区分
今Kindle（だけ）が段落はじめのカギを天付きとして扱うので扱いが面倒くさい。

3.8.3 詰める処理の優先順位

「詰める処理（追込み処理）を行う場合は，通常，優先順位と詰める限界を決めて行う．詰める処理は，次の順序で行う．
a.欧文間隔を，最小で四分アキまで文字サイズ比で均等に詰める．
b.行末に配置する終わり括弧類，読点類及び句点類の後ろの二分アキをベタ組にする．
c.行末に配置する中点類の前及び後ろの四分アキを一緒にベタ組にする．
d.行中の中点類の前後の四分アキを，最小でベタ組まで文字サイズ比で均等に詰める．
e.行中の始め括弧類の前側，並びに終わり括弧類及び読点類の後ろ側の二分アキを，最小でベタ組まで文字サイズ比で均等に詰める．」

　ツメ処理優先順位の記述が断定的過ぎないかという指摘があった。この順番で必ずツメ処理を行う話ではないのではないか。順不同の箇条書きとしてはわかる。
　また、機械的な処理としてはわかるが実際にはもう少し状況によって臨機応変な処理をしているのでは、との話も。
　なお、ここでのツメ処理はJustificationに関連して起こるもので、デザイン上の必要性からくるツメ組の話とは別枠。CSS的にはText-JutifyのJustification Methodに関連する。

3.8.4 空ける処理の優先順位

　ここの項目への指摘も3.8.3と同じ。CSSとしては同じ項目で扱われている。