「全角ダーシ」の問題

　主にDTPデータからの電子化での問題です。私の把握している限りで、DTP等のデータで「ダーシ」として使われている文字は以下のものがあります。

　U+2014（EM DASH）
　U+2015（HORIZONTAL BAR）
　U+FE31（PRESENTATION FORM FOR VERTICAL EM DASH）
　U+2500（罫線素片）

　このうち、U+2014は、フォントによって縦書きで中央に来ないケースが多くあるため、DTPではこれを嫌ってU+2015を使用しているケースが多く見られるようです。
　U+FE31は中央に来るようですが、電子化に際して書き出すと自動で横棒にならず、縦棒のまま残ってしまうため別の文字に置換する必要があります。

　また、ダーシは1文字幅で使うだけではなく、2文字幅の「二倍ダーシ」として使用するケースが多く見られます。二倍ダーシとして連続入力した場合、U+2014/U+2015ともに文字間に隙間ができるデザインのフォントが多く、これを避けるために本来はダーシとして使うべきでないU+2500の罫線素片を使っているケースがあるようです。これは実質的に現状フォントの指定ができない電子書籍では通常の対応となっているのではないかと思います。
　DTPではU+2015を使い、縦200％の変倍をかけているケースが多く見られるようですが、これは電子化のためにそのままテキスト化すれば変倍の情報が飛んで1倍ダーシになります。このため置換処理が必要となります。さらにU+2015はJIS X 0213外の文字であり、厳密にJIS X 0213内での電子化対応を求める場合^※1には何らかの文字に置換しなければならないという問題もあります。

（参考：https://www.youtube.com/watch?v=p9YUx_AeypA）

波ダッシュと全角チルダの問題

　Webを含めさまざまな場面で起きている問題です。過去のさまざまな経緯により以下の文字が混用されています。
　U+301C（WAVE DASH）
　U+FF5E（FULLWIDTH TILDE）

　現在多くの商用フォントではグリフで見分けがつきません。このためDTP的には問題は顕在化していませんが、U+FF5EはJIS X 0213外の文字のため、電子化では置換処理が必要になることがあります。なおこれ以外の文字混用問題も別項目で取り上げていますが、このケースはUnicodeの規格のミスなども絡んでいてだいぶ根が深いので単独で挙げておきます。参考リンク先の記述がかなり詳細ですので、この問題の概要はそちらをご覧ください。

（参考：https://qiita.com/kasei-san/items/3ce2249f0a1c1af1cbd2）

和文引用符の問題

　DTPデータからの電子化での問題です。U+201C/U+201Dのダブルクォートは、InDesignの機能によってダブルミニュート^※2として表示させることができます。ただし、バックグラウンドで持っている文字情報はU+201C/U+201Dのままなので、電子化に際してテキスト化するとグリフが変わってしまいます。このため置換処理が必要となります。U+301D/U+301Fのダブルミニュートをそのまま使えばこの問題はクリアできますが、これはInDesignの禁則文字に入っていない文字のため、InDesignで禁則文字のカスタマイズが必要となります。

（参考：https://www.youtube.com/watch?v=p9YUx_AeypA）

和文中の欧文引用符の問題

　DTPデータからの電子化での問題です。和文組版では通常、和文中の欧文であっても引用符にU+0022を使わず、U+201C/U+201Dをダブルクォートとして使うケースが多く見られます。同様に、アポストロフィとしてU+2019を使い、U+0027を使わないことも慣例となっているようです。
　これはU+0022/U+0027の字形が「間抜け引用符」などと呼ばれてデザイン的に嫌われたために起きたものですが、U+201C/U+201D/U+2019はUnicode上では全角幅／半角幅で異なるコードポイントを与えられてはいないため、テキストとして書き出した際に不自然なアキが引用符の前後に入るケースがあります。このため、電子化に際してはU+0022/U+0027に適宜置換して対応したりします。これはまた、Kindleが縦組み時にU+201C/U+201Dを強制的にU+301D/U+301Fのグリフで表示してしまうことへの対応策でもあります^※3。

グリフで見分けが付かないが使うべきでない文字の混用問題

　Webを含めさまざまな場面で起きている問題です。よく見られるのが「康熙部首」としてUnicodeに収録されている文字（U+2F00〜U+2FD5）を、通常の漢字と混用しているケースや、キリル文字の「А」「В」「С」「Е」「О」「Р」などを通常のアルファベットの文字と混用しているケースです。また、漢字の「二」とカタカナの「ニ」の混用も時々見られます。
　これらはおそらくOCRの誤認識などが混入の原因と思われますが、グリフを目視で見分けて修正することが極めて困難であるため、何らかの機械的な処理で混用を防ぐことが期待されます。康熙部首などは特殊なケース以外では使用されない文字であるため、機械的な1対1の置換でかなりの場合カバーできるかと思います。

絵文字の異体字表示文字の混入問題

　現在、Web等で絵文字が日常的に使われるようになってきており、それに伴って絵文字の異体字表示文字がDTPの元データや電子書籍のテキストに混入し、意図しない表示結果を引き起こすケースがあるようです。符号位置としてはU+FE00〜U+FE0Fがそれに当たります。

時計数字や丸数字などかつての機種依存文字対応の残滓

　現在、時計数字や丸数字などはその多くがUnicodeに独自のコードポイントが与えられており、テキストとして扱えるようになっていますが、かつて機種依存文字として扱われた経緯があるため、現在でも例えば時計数字の「Ⅳ」をアルファベットの組み合わせの「IV」で入力する等の対応をしているケースがあります。少なくともDTPデータや電子書籍では、アクセシビリティへの正しい対応のために本来のUnicodeの文字を使うべきと思います^※4。また、丸数字の外字での対応等も極力控えた方がよいと考えています。

その他問題がありそうな文字

　一部の文字が電子化の際に縦組みで左右中央に来ないため、別の文字に置換したり、場合によっては外字化しているケースがあるようです。確認できている文字は以下の通りです。こういったものはフォントのグリフに依存するため、まだ同種のものがあるかもしれません。
　「•」（U+2022/BULLET）
　「…」（U+2026/三点リーダー）

JLREQ 4.2.1 注の種類

　以下の種類があると記述されている。

1. 後注（こうちゅう）：「縦組でも横組でも利用される形式で，段落の後ろ，項・節・章の後ろ又は本全体の本文の後ろに掲げる注」
2. 頭注（縦組）：「縦組において，基本版面の天側に掲げられる注」
3. 脚注（横組）：「脚注は，基本版面の地側に掲げられる注」
4. 脚注（縦組）：「縦組の脚注は，基本版面の設計段階であらかじめ注のための領域を基本版面の地側に確保し，そこに配置していく．頭注の形式に似ているが，注の配置位置を下部にした形式」
5. 傍注（縦組）：「縦組において，見開きを単位として，その範囲にある項目に関連した注を，見開きの左ページ（奇数ページ）の小口側に掲げる注
6. 傍注（横組）：「横組おける傍注は，サイドノートとよばれており，基本版面の設計段階であらかじめ注のための領域を小口側に確保し，ページを単位として，その範囲にある項目に関連した注をそこに配置していく」

※「縦組の傍注の使用例は少ないが，本文の流れを阻害しないで，かつ，関連項目の近くに注を掲げることができるので，もっと利用が増えてもよい形式である．」という文言があるが、執筆者の好みに過ぎず、自動処理的なハードルの高さからもこの文言を規格に入れるのはどうなのかという意見があった。
※「横組おける傍注」→「横組における傍注」と思う。まあ些末だけども。

　このほか、「上記に掲げた注の形式以外に，学習参考書や歴史の教科書などで人物や事項の簡単な説明，古典の現代文への翻訳などを行間に配置する例がある．」という記述もある。これは組版処理としては両側ルビ的な話になるだろうか。

JLREQ 4.2.2 注の番号

　「注は，本文の該当箇所との関連を示さないで，そのページにある項目に関連した注を配置する例もある．しかし，多くは本文の該当箇所との関連を示す注の番号を付け，関連を示す方法をとっている．」
　さまざまな注の番号の付け方を例示。

JLREQ 4.2.3 合印の処理

※「1.文字サイズは，6ポイントくらいとする．」とあるが、本文のサイズが書かれていないのに合印のサイズだけが絶対値で出てきていてちょっと違和感がある。合印の本文に対しての相対サイズを書くべきなのではとの指摘があった。
　なお、電子書籍での注は現在、本文中の合印と段落末等に配置した注の説明文との間に相互リンクを貼って処理することが多い。この際にスマートフォン等での操作の都合上、合印のリンク面積を一定量確保する必要があり、必ずしも底本の体裁をそのまま保てない。今後の課題のひとつである。

JLREQ 4.2.4 縦組又は横組の後注処理

　「2.字下げは，基本版面の文字サイズの2倍くらいにする．後注の行長は，後注の文字サイズの整数倍にする．」という記述があるが、これは仕事として組版処理に従事していない規格策定者向けの文書の説明としてはだいぶわかりにくいのではないかと思う。補足はされているもののここだけいきなり組版者向けの業務指示的になってしまっている。もう少しかみ砕いた方がよいのではないか。

JLREQ 4.2.5 横組の脚注処理

　「多段組の場合，各段ごとに段の領域に脚注は配置する（図251 ）．しかし，合印があるページの下端に全段を通して配置する方法も行われている（図252）．」
　図252の方がよく見る感がある。組版自動処理の技術的難易度としては段抜きになっている分図252の方が難しそう。

JLREQ 4.2.6 縦組の傍注処理

1. 「縦組の傍注は，その見開き内に付いている合印に対応する注を，奇数ページの左端にそろえて配置する．多段組では最下段の左端にそろえて配置する．」
2. 「注の分量が多い場合は，偶数ページにはみ出してよい．多段組の場合は，上の段にはみ出してよい．」
3. 「対応する傍注の全部又は一部が入りきらない場合には，入りきらない傍注部分を，直後の見開きにおける奇数ページ又は奇数ページの最下段に，次の見開きの合印に対応する傍注の前に挿入する．」

　などなど、Web等での自動組版処理を前提にした際、相当にハードルの高い処理のように思われる。技術的手段の記録としてはよいが、今後Webなどで規格やビューア実装の要望を出していく際にこれをこのまま持って行くのは難しそうと思う。ページ固定で手作業での調整が前提になっている部分が多い。

JLREQ 4.2.7 頭注（縦組）・脚注（縦組）・傍注（横組）の処理

　注の番号を付ける方法、記号などで示す方法、そのページ又は見開きにある項目に関係する並列注を掲げるが本文との対応を示さない方法など、様々な注と本文との対応を示す方法の例示。
※技術書などでは本文のエリアを削って注を入れるようなケースもあるという指摘があった。
※注の中だけ組方向が変わるパターンがあるのではないかという指摘があった。索引などでは逆丁はよく見る。

CSS：注
CSS Generated Content for Paged Media Moduleの中で規格化が検討されている。画面内にfootnoteのエリアを自動定義して生成し、表示するような形。

脚注の指定は例えば以下のような形。

@page { @footnote { float: bottom; } } span.footnote { float: footnote; }

1 2 3 4 5 6

@page {   @footnote {     float: bottom;   } } span.footnote { float: footnote; }

このように指定すると、本文内の<span class="footnote">〜</span>で囲まれた範囲内のテキストを脚注として表示してくれるようになるはず。

自動生成される注の表示記号に関しては、CSS Generated Content for Paged Media Module 2.5 footnote counterで、詳細に定義できるようにすることが検討されている。
footnote-callは本文の中で注を入れるための合印の場所を定義するための疑似要素。
footnote-markerは同じく注の側に付けるための疑似要素。
将来的には傍注や段で分かれるタイプの注（JLREQ 図251参照）、複数の種類の注も使えるようになる予定。（参考）

2.8. Rendering footnotes and footnote policyは注の配置位置に関しての定義。
autoだと注が本文の該当項目の下に収まらない場合は成り行きで次ページに配置しようとする。
lineだと本文の側をその行で改ページさせて必ず本文と注を同じページに収めようとする。
blockだとlineと似ているが、段落単位で移動させる。
なお横組の脚注などは、float:left/float:rightで現状でもレイアウト的に似たようなことはできる。

JLREQ 4.3.1 図版配置の指定方法

　図版配置の2つの方針についての記述。

1. 「あらかじめ本文のテキストについて指定の文字サイズ，字詰めや行間で組版し，文字の配置領域のサイズを分かるようにしておき，それを利用して，ページごとにレイアウトを行い，図版を配置する具体的なページと，そのページ内での詳細な配置位置を指定する方法．」
2. 「図版と本文のテキストとの対応を指示し，ページ内での図版配置位置は原則のみを指定する方法．」

　1はDTPでの組版作業が必須な雑誌的なレイアウトのものか。2は読み物などでの流し込み。Web等での自動組版処理の場合は基本的に2に準じることになる。

JLREQ 4.3.2 図版配置の基本的な考え方

　図版の配置位置の指針。
　「図版と本文のテキストとの対応を指示し，ページ内での図版配置位置は原則のみを指定する場合，本文のテキストの説明と図版配置位置との関係は，同一ページのできるだけ近い位置が望ましい．」
　現状電子書籍では図版の配置位置をページ内のテキストの行数を勘案して前後にずらすような実装は望めないため、画像のサイズによって盛大に余白が生じたりする。特に縦組みで目立つ。将来的に自動で余白領域に連続するテキストを流し入れるような処理を望みたい。

JLREQ 4.3.3 縦組における図版配置の条件

　「本文のテキストを図版の周囲に配置する場合で，その配置領域の字詰め方向の長さが極端に短い場合（例えば基本版面で指定する1行の行長の1/4又は9字以下の場合）は，本文のテキストは配置しないで，空けておいた方がよい」
　これを自動処理でやるのは相当に負荷が高そう。常に表示文字数をカウントして表示を切り替えるような話になる。

4.3.4 横組における図版配置の条件

　段落間に図版を置く場合の画像前後のアキに関する記述がここには見当たらず、JLREQ 4.5.3 行送り方向の領域の調整処理に簡単な記述があった（図312）。こういうのはJLREQ内での内部参照リンクが欲しいところ。

　なおJLREQ 4.5.3は、箇条書きの項目立てが親項目と子項目の見かけがほとんど同じで、インデント等ではっきりわかる形にもなっていないため大変わかりにくい。修正を望みたい。

CSS：図の回り込み
CSS Page Floatsで規格化が進行中。

3.1. The float-reference property
float referenceでどこを基準としてfloatさせるかを選ぶ形に。今のfloatの挙動と同じなのがinline。加えて段落、ページなども選べるようになるはず。
3.2. The float property
これで top | bottom などを指定することでページ内上部、下部などの指定もできるように。top right、top leftなどの指定も検討されている。
なお現状のfloatの挙動は inline-start、inline-end に相当する。

JLREQ 4.4.1 表の構成

　「表は，こま（小間，セル）内に数字や事項などを配置し，そのこまを縦及び横の列又は行として配置，一覧できるようにしたものである．」
　表は項目のセルだけ組み方向が変わったり、ページまたぎの要素があったりとかなり複雑な処理を必要とする組版処理である。InDesignでもページをまたぐ大きな表の作成では手動でセルを分割して調整をする必要があり、自動で流し込んで終わりというわけにはいかない。当然電子書籍でのTableタグを用いた表組みもビューアの側の対応が追いついていないケースはあり、また項目の数が多い表を画面サイズの小さなデバイスで表示する際などはどうしても表示が破綻してしまうケースはある。
　図293 見開きを単位として配置した表の例には、見開きの図表の場合にノドをまたいでキャプションが入る例が紹介されている。こちらなどは自動組版処理での対応は相当以上に難しいと考えざるを得ない。

CSS：表が複数ページになった場合にページ先頭にヘッダーを繰り返し表示する処理
CSS Repeated Headers and Footersで一応提案はされているが、まだドラフトにもなっていない。細かな挙動の制御ができることを目指している。
最低限の繰り返しの挙動の定義はこちら。ここまではドラフトになっている。
表の外側の罫線を分割した双方のページに表示させるかさせないかの制御はCSS Fragmentation Module Level 3のbox-decoration-breakで指定。

JLREQ 4.5.1 ルビなどが付いた場合の行間の処理

　「次のような例では，文字の大きさなどにより行間にはみ出して配置する場合がある．」とあり、例の中に「5.段落で指定された文字サイズより大きいサイズの文字列」の記述がある（図301）。この本文の文字のサイズに従って行間（line-heightの値）を固定する処理が現状Webや電子書籍ではできない。いくつかドラフトでの提案は行われている模様。
　「行間に配置する次のa～cを版面又は段の領域の先頭行に配置する場合は，先頭行に接する版面又は段の領域の外側に配置する」
　ここは現状Webや電書では難しい処理（Webのページレイアウトののボックスモデルの例外になるため）。ぶら下がりなども同様の理由で難しい。

JLREQ 4.1.1 見出しの種類

　「見出しは，組版処理の方法で分けると，次の4つになる．
　a.中扉又は半扉
　b.別行見出し
　c.同行見出し
　d.窓見出し」
※同行見出しで見出しと本文との間がJLREQでは「全角」とあるが（図188）、必ずしも全角とは限らないのではないかという指摘があった。活版の時代のルールと思われる。

JLREQ 4.1.2 別行見出しの構成

　「別行見出しの構成については，JIS X 4051では大見出し，中見出し及び小見出しについて，それぞれラベル名，番号，見出し文字列及び副題で構成するとしている（図190）．ただし，ラベル名，番号及び副題は，必須要素ではなく，省略してもよいとなっている．」
「なお，これ以外に見出しの前後に記号を付ける，あるいは罫線を見出しの前後に配置する，罫線で見出しを囲むなどといったことも行われている」
※このあたりの記述はデザインの話が入り込んでしまっており、規格文書の記述としてはいらないのではないかという指摘があった。

JLREQ 4.1.3 見出しにアクセントを付ける

　ここもほぼデザインの話。技術的にそう多くのオプションがなかった活版時代のデザインの典型例としては興味深いものがあるが、デザイン回りの話だけに異論も多く出そう。

JLREQ 4.1.4 改丁・改ページ・改段処理

　「大見出しなどでは，区切りを明確にするために新しいページから始める方法も行われている．」
　章扉などで見られるような必ず奇数ページから始める処理が改丁、奇数偶数ページにこだわらず、単にページを改めるのが改ページ。雑誌やムック本などで見られるように必ず偶数ページで始めて見開きで記事を読ませるパターンもある。

CSS:扉などの改ページ
CSS Fragmentation module Level3 3.1. Breaks Between Boxes: the break-before and break-after properties
break-after:auto、break-bofore:autoで通常の改ページ。
いわゆる改丁や見開き始まり指定はright/leftでできるようになるはず。
recto/versoは論理値なのでこれが使えれば縦書き横書き共通で改丁などを指定できる。
見開きの最初のページにするのがverso。

　なお現状EPUB3では改丁／見開き始まりはOPFファイル内のspine項目で「properties=”page-spread-left”」のように指定する。ただしこれに対応しているEPUBビューアは現状あまりない（観測範囲ではhonto、kinoppyくらい。BOOK☆WALKERも対応しているという報告があった）。全体としてはリフロー型で、中途に見開きの図が挟まるような本で問題となりがち。

JLREQ 4.1.6 行取りの処理例

　「各ページで行を配置していく場合，基本版面で設定した行位置にそろった方が望ましい．そこで，行送り方向の見出しの占める領域は，基本版面で設定した行位置を基準にして設定する方法が行われている．このような設定方法を行取りという．」（4.1.3 dより）
　ここは4.1.3 dへの参照リンクが欲しい。

※ページ先頭に行取りの空改行が入った場合、欧文組版では（上側の）スペースを削除するのが普通で、CSSも現状そうなっている。和文の図201などの処理は行頭でも（右側の）アキを入れる点が違う、という指摘があった。

　図203のような本題と副題が2行の場合、泣き別れを防ぐにはbreak-inside:avoidの指定が必要。

　行取り含めて本文級数×行数で版面を決めて厳密にそれを守る日本語組版では基本となる処理を再現するために、現状議論中のCSS規格で一番近いのはLine-gridなどだが、まだこれも議論中でどうなりそうかはっきりしないとのこと。ここがどうにかならないと、行取りをCSSで指定するといったような話にもならないだろうと思われる。

JLREQ 4.1.7 行取り処理した見出しがページ末にきた場合の処理

　行末に入りきれなかった場合にはブロックごと次ページに。これは行取り処理した見出しに限らず、ページ末尾に見出しが来てしまった場合に次ページに送る処理は一般的に行われている（JLREQ 4.1.4 eの「なりゆき」の記述も参照）。
　なお、見出しと本文の泣き別れを防ぐのはbreak-inside:avoidなどを指定することで可能だが、ノド側に来た場合には見出しと本文との泣き別れを許容する（見開きで次ページの1行目に本文が来るため）ルールを採用しているケースもあるため、そこまでを自動で処理するのはかなり難しそうではある。

JLREQ 4.1.9 同行見出しの処理

　同行見出しはレイアウト的に本文と同一行内に見出しを配置するもののため、例えば

　<p><span class="midashi">見出し</span>本文本文本文本文</p>

　といったような形のマークアップが想起されるが、構造化文書として本来的には

　<hn>見出し</hn>
　<p>本文本文本文本文</p>

　といった形で本文と見出しを記述しておき、CSS指定で同行で見せる方が望ましい。

JLREQ 4.1.10 窓見出しの処理

　これも本来は上記のように<hn>タグと<p>タグを分けてマークアップするべきだが、まだRSの実装的に実際にweb等で再現するのは難しいかもしれない。詳しくは以下参照。

CSS：同行見出し／窓見出し
同行見出し、窓見出しもHTMLの構造としてはhnタグでマークアップした方がよいはず。
そのためのものとして display要素の拡張として Run-In Layout がドラフト規格として考案されている。
display: run-in;
のように指定。

CSS display level3ではdisplayプロパティでdisplay-outsideとdisplay-insideを別に指定できるようになっているため、窓見出しの表現も可能になるはず。
display: run-in flow-root;
になるか。floatの指定も必要かもしれない。

JLREQ 4.1.11 段抜きの見出しの処理

　新聞や雑誌で多く見られる段組の複数の段をぶち抜く形の見出し。これはリフローで処理するのは相当負荷が大きそう。一応CSSではできなくはない。

CSS:段抜き見出し
CSS Multi-column Layout Moduleのcolumn-spanで指定できる。ただし、全段抜きか段抜きをしないかの2択。
なお、multi-column module Level2ではinteger（整数値）での指定も提案されてはいるとのこと。これがもし実用段階に入れば、例えば5段組のうち2段を使った段抜き見出しのようなレイアウトも可能になるだろう。
InDesignでは段落パレットの「段抜きと段分割」で指定できる。ただし、段抜きを行うためにはテキストフレームをひとつにしておかないとならないなどの制約はあり、現状どこまで実用されているかはわからない。