─グーテンベルクの遙か彼方へ─このブログはEPUB3をはじめとした電子書籍制作の現場からの「現地レポート」を目指しています。電子書籍制作、アプリケーション開発など、多方面の方々からの積極的なご意見をお待ちしております。※『InDesign→EPUB3用XHTML作成ワークフロー』は通常エントリに移動しました。『ジャンル別まとめ/ダウンロード』からアクセスできます。要件」(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.『電書魂』のコンテンツはクリエイティブ・コモンズによりライセンスされています。記事名の記載と、記事へのリンクを貼って頂ければ、コンテンツを自由にご利用いただくことができます。