─グーテンベルクの遙か彼方へ─このブログはEPUB3をはじめとした電子書籍制作の現場からの「現地レポート」を目指しています。電子書籍制作、アプリケーション開発など、多方面の方々からの積極的なご意見をお待ちしております。※『InDesign→EPUB3用XHTML作成ワークフロー』は通常エントリに移動しました。『ジャンル別まとめ/ダウンロード』からアクセスできます。要件」(JLREQ)と、これに関連してVivliostyleの村上真雄さんたちが提出したW3Cメンバーサブミッション「Web技術を用いた日本語組版の現状」を取り扱っていることに伴い、会員以外の方の意見を広く求めるとともに、記録を残しておく目的で議事録をベースに補足したものを公開するものです。間違い、補足などございましたらご意見いただければ幸いです。当ブログはコメント許可制を取っているため、反映に時間がかかります。要件」(JLREQ)を先頭から読んでいき、各要素に対応するCSSが存在するのか、存在するとして実用段階なのか、InDesignなどの組版ソフトではどういった形で機能を実現しているのか(いないのか)、などについて見ています。全体に対しての包括的な説明の部分に関しては、細かな部分は次回以降にその部分の説明が出てきた時に掘り下げる、としてスルーしている箇所があります。こちらで取り上げております各CSSプロパティはまだドラフト仕様の段階のものも多いため、今現在すぐに使えるものばかりではありません。Webブラウザで使用出来るかどうかはこちらなどでご確認ください。電子書籍のRSで使用出来るかどうかは、現在広範に調査した資料がありません。当研究会の活動として調査を行いたく考えていますが、しばらく時間はかかるかと思います。以下の種類があると記述されている。※「縦組の傍注の使用例は少ないが,本文の流れを阻害しないで,かつ,関連項目の近くに注を掲げることができるので,もっと利用が増えてもよい形式である.」という文言があるが、執筆者の好みに過ぎず、自動処理的なハードルの高さからもこの文言を規格に入れるのはどうなのかという意見があった。※「横組おける傍注」→「横組における傍注」と思う。このほか、「上記に掲げた注の形式以外に,学習参考書や歴史の教科書などで人物や事項の簡単な説明,古典の現代文への翻訳などを行間に配置する例がある.」という記述もある。これは組版処理としては両側ルビ的な話になるだろうか。「注は,本文の該当箇所との関連を示さないで,そのページにある項目に関連した注を配置する例もある.しかし,多くは本文の該当箇所との関連を示す注の番号を付け,関連を示す方法をとっている.」さまざまな注の番号の付け方を例示。※「1.文字サイズは,6ポイントくらいとする.」とあるが、本文のサイズが書かれていないのに合印のサイズだけが絶対値で出てきていてちょっと違和感がある。合印の本文に対しての相対サイズを書くべきなのではとの指摘があった。電子書籍での注は現在、本文中の合印と段落末等に配置した注の説明文との間に相互リンクを貼って処理することが多い。この際にスマートフォン等での操作の都合上、合印のリンク面積を一定量確保する必要があり、必ずしも底本の体裁をそのまま保てない。今後の課題のひとつである。「2.字下げは,基本版面の文字サイズの2倍くらいにする.後注の行長は,後注の文字サイズの整数倍にする.」という記述があるが、これは仕事として組版処理に従事していない規格策定者向けの文書の説明としてはだいぶわかりにくいのではないかと思う。補足はされているもののここだけいきなり組版者向けの業務指示的になってしまっている。かみ砕いた方がよいのではないか。図252の方がよく見る感がある。組版自動処理の技術的難易度としては段抜きになっている分図252の方が難しそう。「対応する傍注の全部又は一部が入りきらない場合には,入りきらない傍注部分を,直後の見開きにおける奇数ページ又は奇数ページの最下段に,次の見開きの合印に対応する傍注の前に挿入する.」などなど、Web等での自動組版処理を前提にした際、相当にハードルの高い処理のように思われる。技術的手段の記録としてはよいが、今後Webなどで規格やビューア実装の要望を出していく際にこれをこのまま持って行くのは難しそうと思う。ページ固定で手作業での調整が前提になっている部分が多い。注の番号を付ける方法、記号などで示す方法、そのページ又は見開きにある項目に関係する並列注を掲げるが本文との対応を示さない方法など、様々な注と本文との対応を示す方法の例示。※技術書などでは本文のエリアを削って注を入れるようなケースもあるという指摘があった。※注の中だけ組方向が変わるパターンがあるのではないかという指摘があった。索引などでは逆丁はよく見る。Moduleの中で規格化が検討されている。画面内にfootnoteのエリアを自動定義して生成し、表示するような形。脚注の指定は例えば以下のような形。class="footnote">〜</span>で囲まれた範囲内のテキストを脚注として表示してくれるようになるはず。counterで、詳細に定義できるようにすることが検討されている。footnote-callは本文の中で注を入れるための合印の場所を定義するための疑似要素。footnote-markerは同じく注の側に付けるための疑似要素。図251参照)、複数の種類の注も使えるようになる予定。policyは注の配置位置に関しての定義。autoだと注が本文の該当項目の下に収まらない場合は成り行きで次ページに配置しようとする。lineだと本文の側をその行で改ページさせて必ず本文と注を同じページに収めようとする。blockだとlineと似ているが、段落単位で移動させる。横組の脚注などは、float:left/float:rightで現状でもレイアウト的に似たようなことはできる。図版配置の2つの方針についての記述。「図版と本文のテキストとの対応を指示し,ページ内での図版配置位置は原則のみを指定する方法.」1はDTPでの組版作業が必須な雑誌的なレイアウトのものか。2は読み物などでの流し込み。Web等での自動組版処理の場合は基本的に2に準じることになる。図版の配置位置の指針。現状電子書籍では図版の配置位置をページ内のテキストの行数を勘案して前後にずらすような実装は望めないため、画像のサイズによって盛大に余白が生じたりする。将来的に自動で余白領域に連続するテキストを流し入れるような処理を望みたい。「本文のテキストを図版の周囲に配置する場合で,その配置領域の字詰め方向の長さが極端に短い場合(例えば基本版面で指定する1行の行長の1/4又は9字以下の場合)は,本文のテキストは配置しないで,空けておいた方がよい」これを自動処理でやるのは相当に負荷が高そう。常に表示文字数をカウントして表示を切り替えるような話になる。行送り方向の領域の調整処理に簡単な記述があった(図312)。いうのはJLREQ内での内部参照リンクが欲しいところ。4.5.3は、箇条書きの項目立てが親項目と子項目の見かけがほとんど同じで、インデント等ではっきりわかる形にもなっていないため大変わかりにくい。Floatsで規格化が進行中。referenceでどこを基準としてfloatさせるかを選ぶ形に。今のfloatの挙動と同じなのがinline。加えて段落、ページなども選べるようになるはず。指定することでページ内上部、下部などの指定もできるように。leftなどの指定も検討されている。表は項目のセルだけ組み方向が変わったり、ページまたぎの要素があったりとかなり複雑な処理を必要とする組版処理である。InDesignでもページをまたぐ大きな表の作成では手動でセルを分割して調整をする必要があり、自動で流し込んで終わりというわけにはいかない。電子書籍でのTableタグを用いた表組みもビューアの側の対応が追いついていないケースはあり、また項目の数が多い表を画面サイズの小さなデバイスで表示する際などはどうしても表示が破綻してしまうケースはある。見開きを単位として配置した表の例には、見開きの図表の場合にノドをまたいでキャプションが入る例が紹介されている。こちらなどは自動組版処理での対応は相当以上に難しいと考えざるを得ない。Footersで一応提案はされているが、まだドラフトにもなっていない。細かな挙動の制御ができることを目指している。最低限の繰り返しの挙動の定義はこちら。ここまではドラフトになっている。3のbox-decoration-breakで指定。「次のような例では,文字の大きさなどにより行間にはみ出して配置する場合がある.」とあり、例の中に「5.段落で指定された文字サイズより大きいサイズの文字列」の記述がある(図301)。この本文の文字のサイズに従って行間(line-heightの値)を固定する処理が現状Webや電子書籍ではできない。いくつかドラフトでの提案は行われている模様。「行間に配置する次のa~cを版面又は段の領域の先頭行に配置する場合は,先頭行に接する版面又は段の領域の外側に配置する」ここは現状Webや電書では難しい処理(Webのページレイアウトののボックスモデルの例外になるため)。ぶら下がりなども同様の理由で難しい。JLREQはこの後の部分は資料となるので、本文に当たるパートは今回で一応全て読み終えたことになる。次回以降、要望の優先順位の検討や電子書籍用RSの対応をチェックしていく予定。要件」(JLREQ)と、これに関連してVivliostyleの村上真雄さんたちが提出したW3Cメンバーサブミッション「Web技術を用いた日本語組版の現状」を取り扱っていることに伴い、会員以外の方の意見を広く求めるとともに、記録を残しておく目的で議事録をベースに補足したものを公開するものです。間違い、補足などございましたらご意見いただければ幸いです。当ブログはコメント許可制を取っているため、反映に時間がかかります。要件」(JLREQ)を先頭から読んでいき、各要素に対応するCSSが存在するのか、存在するとして実用段階なのか、InDesignなどの組版ソフトではどういった形で機能を実現しているのか(いないのか)、などについて見ています。全体に対しての包括的な説明の部分に関しては、細かな部分は次回以降にその部分の説明が出てきた時に掘り下げる、としてスルーしている箇所があります。こちらで取り上げております各CSSプロパティはまだドラフト仕様の段階のものも多いため、今現在すぐに使えるものばかりではありません。Webブラウザで使用出来るかどうかはこちらなどでご確認ください。電子書籍のRSで使用出来るかどうかは、現在広範に調査した資料がありません。当研究会の活動として調査を行いたく考えていますが、しばらく時間はかかるかと思います。※同行見出しで見出しと本文との間がJLREQでは「全角」とあるが(図188)、必ずしも全角とは限らないのではないかという指摘があった。活版の時代のルールと思われる。※このあたりの記述はデザインの話が入り込んでしまっており、規格文書の記述としてはいらないのではないかという指摘があった。見出しにアクセントを付けるここもほぼデザインの話。技術的にそう多くのオプションがなかった活版時代のデザインの典型例としては興味深いものがあるが、デザイン回りの話だけに異論も多く出そう。章扉などで見られるような必ず奇数ページから始める処理が改丁、奇数偶数ページにこだわらず、単にページを改めるのが改ページ。雑誌やムック本などで見られるように必ず偶数ページで始めて見開きで記事を読ませるパターンもある。propertiesbreak-after:auto、break-bofore:autoで通常の改ページ。いわゆる改丁や見開き始まり指定はright/leftでできるようになるはず。recto/versoは論理値なのでこれが使えれば縦書き横書き共通で改丁などを指定できる。見開きの最初のページにするのがverso。現状EPUB3では改丁/見開き始まりはOPFファイル内のspine項目で「properties=”page-spread-left”」のように指定する。これに対応しているEPUBビューアは現状あまりない(観測範囲ではhonto、kinoppyくらい。BOOK☆WALKERも対応しているという報告があった)。全体としてはリフロー型で、中途に見開きの図が挟まるような本で問題となりがち。dへの参照リンクが欲しい。※ページ先頭に行取りの空改行が入った場合、欧文組版では(上側の)スペースを削除するのが普通で、CSSも現状そうなっている。和文の図201などの処理は行頭でも(右側の)アキを入れる点が違う、という指摘があった。図203のような本題と副題が2行の場合、泣き別れを防ぐにはbreak-inside:avoidの指定が必要。行取り含めて本文級数×行数で版面を決めて厳密にそれを守る日本語組版では基本となる処理を再現するために、現状議論中のCSS規格で一番近いのはLine-gridなどだが、まだこれも議論中でどうなりそうかはっきりしないとのこと。ここがどうにかならないと、行取りをCSSで指定するといったような話にもならないだろうと思われる。行末に入りきれなかった場合にはブロックごと次ページに。eの「なりゆき」の記述も参照)。見出しと本文の泣き別れを防ぐのはbreak-inside:avoidなどを指定することで可能だが、ノド側に来た場合には見出しと本文との泣き別れを許容する(見開きで次ページの1行目に本文が来るため)ルールを採用しているケースもあるため、そこまでを自動で処理するのはかなり難しそうではある。class="midashi">見出し</span>本文本文本文本文</p>といったような形のマークアップが想起されるが、構造化文書として本来的には<hn>見出し</hn><p>本文本文本文本文</p>といった形で本文と見出しを記述しておき、CSS指定で同行で見せる方が望ましい。窓見出しの処理これも本来は上記のように<hn>タグと<p>タグを分けてマークアップするべきだが、まだRSの実装的に実際にweb等で再現するのは難しいかもしれない。CSS:同行見出し/窓見出し同行見出し、窓見出しもHTMLの構造としてはhnタグでマークアップした方がよいはず。ドラフト規格として考案されている。run-in;のように指定。level3ではdisplayプロパティでdisplay-outsideとdisplay-insideを別に指定できるようになっているため、窓見出しの表現も可能になるはず。flow-root;になるか。floatの指定も必要かもしれない。新聞や雑誌で多く見られる段組の複数の段をぶち抜く形の見出し。これはリフローで処理するのは相当負荷が大きそう。一応CSSではできなくはない。Moduleのcolumn-spanで指定できる。全段抜きか段抜きをしないかの2択。Level2ではinteger(整数値)での指定も提案されてはいるとのこと。これがもし実用段階に入れば、例えば5段組のうち2段を使った段抜き見出しのようなレイアウトも可能になるだろう。InDesignでは段落パレットの「段抜きと段分割」で指定できる。段抜きを行うためにはテキストフレームをひとつにしておかないとならないなどの制約はあり、現状どこまで実用されているかはわからない。要件」(JLREQ)と、これに関連してVivliostyleの村上真雄さんたちが提出したW3Cメンバーサブミッション「Web技術を用いた日本語組版の現状」を取り扱っていることに伴い、会員以外の方の意見を広く求めるとともに、記録を残しておく目的で議事録をベースに補足したものを公開するものです。間違い、補足などございましたらご意見いただければ幸いです。当ブログはコメント許可制を取っているため、反映に時間がかかります。要件」(JLREQ)を先頭から読んでいき、各要素に対応するCSSが存在するのか、存在するとして実用段階なのか、InDesignなどの組版ソフトではどういった形で機能を実現しているのか(いないのか)、などについて見ています。全体に対しての包括的な説明の部分に関しては、細かな部分は次回以降にその部分の説明が出てきた時に掘り下げる、としてスルーしている箇所があります。こちらで取り上げております各CSSプロパティはまだドラフト仕様の段階のものも多いため、今現在すぐに使えるものばかりではありません。Webブラウザで使用出来るかどうかはこちらなどでご確認ください。電子書籍のRSで使用出来るかどうかは、現在広範に調査した資料がありません。当研究会の活動として調査を行いたく考えていますが、しばらく時間はかかるかと思います。「振分けとは,1行の途中に複数の言葉や文を配置する処理である.複数の選択肢を示す場合などに利用されている.学習参考書,マニュアル,解説書などで使用している例がある.振分けを行う場合,複数の行を括弧類でくくることも多い.」この処理自体は見たことがあるが、「振分け」という用語自体にはあまり聞き覚えがなかった。「また,同一の振分け行を複数の行に分割した場合の行間は0とする」ここだけずいぶん具体的な行間表記。CSS的にはdisplay:inline-blockで表現自体は可能。上下をブレースで囲む表現が今ちょっと難しそうな感じ(border-imageプロパティでできなくはないが)。そろえの処理」に関連情報がある。「○○文字分」という考え方になるところが考え方として違うところか。」といったような形で指定が来る。※図173と図174は違う処理の例になるのではないか。項を分けた方が良くないかという指摘があった。CSS的には前出のtext-alignを参照。4051にはない項目になる、とのこと。※図176の等号類、演算記号の文字の例が全角になっているのに違和感がある、との指摘。プロポーショナルの記号であるべき。(和欧混植で英文ブロックを和文内に入れる場合には欧文ブロックの中は欧文の組版ルールに従うべき、というのと同種の話か)※図177、演算としてのマイナス符号と負の値を表す符号がこの例だと判別できないという指摘。和文フォントのデザインに表記が引きずられている?「別行式で,2行に分割する位置をある程度任意に選択できる場合は,まず等号類の前で2行に分割するとよい.それができない場合は,演算記号の前で2行に分割するとよい.」に関して、数学方面での書籍組版の常識としては、別行式ではJLReqの記述の通りであるが,行中式(インライン)では式が繋がっていることを示すために等号類や演算記号の「後ろ」で改行する、という指摘あり。行中式での改行の記述自体が抜けている、という指摘もあった。行の調整処理には空き量を詰める処理(追込み処理)と字間を空ける処理(追出し処理)がある。「通常,詰める処理(追込み処理)を優先し,それで処理できない場合は空ける処理(追出し処理)を行う.詰める処理(追込み処理)を優先するのは,ベタ組の箇所はできるだけ空けないという考え方による.」書籍組版などでは空ける処理を優先するケースもある。どちらを優先するかはそれぞれの現場でのルール付けによるものと思われる。「a.規定されている空き量を詰める処理(追込み処理).追込み処理では,読点類又は終わり括弧類の後ろの二分アキや,始め括弧類の前の二分アキ,欧文間隔などの空き量を規定の範囲内で詰める処理を行う.」とある。JLREQの規定では欧文単語間のスペースを3分と規定しているが、実際のフォントのデザインでは0.25em程度にしているパターンが多いため、実際にはほとんど詰まらないことになるのではないか、という指摘。現在のDTPの組版では、カタカナ、ひらがな類の前後スペースの調整処理なども行われている。これは技術の進展により、より細かな調整が可能になったためと思う。この項目の注にぶら下げ組の解説がある。ぶら下げはCSSのボックスモデルの例外的な処理を必要とする要素でもあり、1項立てて解説しても良いのではないかと感じた。アンバランスさがある。行末の句読点は全てぶら下げた方が綺麗に揃って見えるという意見もある。これを反映してか、InDesignでは段落パレットの指定でぶら下がりの強制、標準、なしを選べる。propertyforce-endが強制、allow-endが標準。firstは段落はじめの開き括弧などを通常位置より外側にはみ出させる処理。日本語だとあまり見ないが、欧文ではそれなりに多い。段落先頭だけに関連する点がtext-spacingとは違う。lastはそれを行末側でやる処理。今Kindle(だけ)が段落はじめのカギを天付きとして扱うので扱いが面倒くさい。「詰める処理(追込み処理)を行う場合は,通常,優先順位と詰める限界を決めて行う.詰める処理は,次の順序で行う.a.欧文間隔を,最小で四分アキまで文字サイズ比で均等に詰める.b.行末に配置する終わり括弧類,読点類及び句点類の後ろの二分アキをベタ組にする.c.行末に配置する中点類の前及び後ろの四分アキを一緒にベタ組にする.d.行中の中点類の前後の四分アキを,最小でベタ組まで文字サイズ比で均等に詰める.e.行中の始め括弧類の前側,並びに終わり括弧類及び読点類の後ろ側の二分アキを,最小でベタ組まで文字サイズ比で均等に詰める.」ツメ処理優先順位の記述が断定的過ぎないかという指摘があった。この順番で必ずツメ処理を行う話ではないのではないか。順不同の箇条書きとしてはわかる。機械的な処理としてはわかるが実際にはもう少し状況によって臨機応変な処理をしているのでは、との話も。ここでのツメ処理はJustificationに関連して起こるもので、デザイン上の必要性からくるツメ組の話とは別枠。Methodに関連する。空ける処理の優先順位ここの項目への指摘も3.8.3と同じ。CSSとしては同じ項目で扱われている。Tajimaこちらにて、電子書籍&Web制作を担当しています。このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。整うことを願って、現場からの声を発信していこうと目論んでおります。当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。License.『電書魂』のコンテンツはクリエイティブ・コモンズによりライセンスされています。記事名の記載と、記事へのリンクを貼って頂ければ、コンテンツを自由にご利用いただくことができます。