─グーテンベルクの遙か彼方へ─このブログはEPUB3をはじめとした電子書籍制作の現場からの「現地レポート」を目指しています。電子書籍制作、アプリケーション開発など、多方面の方々からの積極的なご意見をお待ちしております。※『InDesign→EPUB3用XHTML作成ワークフロー』は通常エントリに移動しました。『ジャンル別まとめ/ダウンロード』からアクセスできます。Forceに協力することになりました。そもそもXMLパブリッシング準研究会での研究活動の最終的な目標のひとつはW3Cに何らかの形でフィードバックを行うことだったので、歓迎すべき流れです。Analysisを読み込んでみました。噛み砕いて日本語組版での用語に擦り合わせる作業が必要になり、ちょっと意味の取れない箇所もありました。お気づきの点は随時ご指摘いただければと思います。全体的な位置づけの確認まず、文書の全体的な位置づけを確認しておきます。世界中の書字言語でどこまでCSS等での組版処理が実現できているかを示すマトリックスがこちらです。運用可能なWebページをこの言語で作成するに当たって阻害する要素が残っているという意味です。その他に「?」が随所にあり、これは状況の調査がまだ済んでいないということのよう。この文書含めて何度も「Script」という単語が出てきますが、これはこの場合は「書字言語」、書き言葉の意味です。Languageだと話し言葉を含むもっと広い意味での言語の意味になるので峻別のために使っているのでしょう。マトリックスの列が項目分け、行が各国の言語です。Analysisのページが出てきます。日本語だけではなく各国語向けに同様のページがあるようです。世界中の言語を網羅的に項目を作っているので、項目自体が日本語には必要の無い箇所も多々あるのですがこれはまあ仕方ないところ。今回W3Cが求めているGitHubへの意見のフィードバックはこの大項目に従い、各項目内にIssueを立てて行く形で行われていくと思われるので項目内容の把握は大事です。それでは見ていってみましょう。あなたの言語の表示に必要な特別なフォントやOpenTypeの機能は利用できますか(Webフォントの使用などか)?コメント:日本語では筆記体はほぼ考慮しなくてよいと思う。現状Firefoxではドキュメント側の指定フォントよりブラウザの設定項目でユーザーが設定したフォントが優先されて表示される模様。「font-feature-settings」などフォントの内部情報をCSSで呼び出して実現する表現もここに分類されるか。イタリック体の合成表示に問題がありますか?コメント:網羅的な調査はしていないが、縦書き文中に挿入された欧文部分でイタリック表示の処理に問題を持つRSはある。現状、Kindle等の縦書き時のイタリック体の表示は不適切。Kinoppy等は適切に表示できている上、フォント側がイタリックのグリフを持っている場合にはそれを用いて表示しているように見える。本来はそれが望ましい。Edge等は単純に文字をシアー変形処理で傾けて表示する。Kinoppy等はフォントがイタリックのグリフを持っている場合にはそれを呼び出して表示させる。欧文の部分の表示最適化の意味ではもちろん後者がよい。イタリック体の情報を持たない漢字などに対してイタリックが指定された場合に傾けて表示することが適切かどうかは議論が必要そう。ひらがな、カタカナ、漢字などには本来はイタリック体の概念はなかったので本来的には当然イタリック体の合成も考慮する必要はないはず。最近モリサワなどから連綿体のフォントも出てきているが、また例外と考えてよいと思う。引用符をインデントしたり、特別に扱ったりするのは避けるべきですか?2.6.1〜2.6.3の子項目が立っているがこちらの守備範囲では無さそうなのでコメントはなし。HTMLのQタグを使った際に自動で付けられる引用符の挙動に関して言っているようなのだが、あまりそのあたりはなじみがない。論文などでの話だろうか。句読点を適用する際に、アプリケーションによって修正される可能性のある問題はありますか?(これらの質問に対する回答の一部は、改行や頭文字のスタイリングなど、他のセクションで扱うことができます)。コメント:ブラウザの挙動に関する項目だろうか。半角と全角の字形を変換する必要がありますか?コメント:字形の自動変換処理に関しての項目。日本語では縦書きと横書きで一部記号類の字形が変わるが、これは既にほぼサポートできている。Gecko(Firefox)でのみ動作するとあるが、これは英数字の縦書き時全角変換を指したものだろう。確かにInDesign等でそういった処理はあるが、そこまで一般的なルールでもないので後回しでよいと思う。Kindleは縦書きの際にダブルクォートをダブルミニュート(ノノカギとも言う)に強制自動変換して表示する実装を行っているが、これはどんな場合でもそうなるのが正しいというわけではないので明確な間違いである。コンテンツ制作者が選択すべき部分。一部の言語では、単語内の文字または音節の間隔を開けて強調またはその他の効果を表します。あなたの言語に関してまだサポートされていない要件はありますか?(均等割付に関連する間隔の処理については、下記を参照してください。)コメント:いわゆる「分かち書き」に関係する部分。一般的には日本語では分かち書きは行われないが、カナモジカイに見られるように過去に事例自体はあった。絵本や障がい者向けコンテンツでは分かち書きを行うことがあるようだ。日本語でもデザイン的な意味で見出しなどの文字の間隔を開けることはあり、これはletter-spacingで既に実現できている。future?↓ルビの規格は現在、ふりがな、ピンイン、(主に台湾で用いられる)注音符号のタイポグラフィの初期的なサブセットを規定しています。markup(表形式のマークアップ)コメント:いわゆる熟語ルビのマークアップに関する項目と思う。熟語ルビに関してはこちらを参照。現状ルビタグのマークアップは<ruby>親<rt>おや</rt></ruby><ruby>文<rt>も</rt></ruby><ruby>字<rt>じ</rt></ruby>のように行われるが、これを<ruby><rb>親</rb><rb>文</rb><rb>字</rb><rt>おや</rt><rt>も</rt><rt>じ</rt></ruby>のようにすることで、(過去に<rp>タグで行われていたような)ルビの表示が難しい環境でのふりがなの補完表示が可能になるということのようだ。通常のモノルビでのマークアップの場合の検索性の問題も指摘されている。characters.」がちょっと意味的にわからない。ruby(両側ルビ)コメント:縦組みで左右、横組みで上下に違ったルビを表示するための項目。ルビをどちら側に付けるかを指定するためのプロパティ、ruby-positionを使うことになる。Firefoxで標準動作、Safari、Chromeではベンダープレフィックスがいるが動作する、とある。styling(ルビの整列、その他のスタイリング)コメント:いわゆる肩付きルビ、中付きルビなどの指定に用いるプロパティ、ruby-alignに関する項目。Firefoxでのみ動作するほか、Edgeでは独自の構文で動作する、とある(ベンダープレフィックスのこと?)。今電子書籍では一般的にルビは全て中付きになるため、肩付き、中付きを指定できるようになるのは確かに進化ではある。絶対に必要とまでは言えないと思う。text?↓テキストに沿って描画される線(傍線)、もしくはテキストの上を通るような線(打ち消し線)の描画に関して、ローカルなタイポグラフィにおけるいくつかの側面を考慮しなければなりません。縦書きのテキストでの線の表現には問題がないですか?コメント:InDesign等の組版ソフトでは現状さまざまな種類の傍線、打ち消し線のバリエーションを選べるが、電子書籍ではそこまで種類を選べないのでギャップはある。波線などは使えるようになって欲しい。縦書き時にtext-decorationで指定した線がテキストのどちらの側に付くのかに関してEPUBのRS間で差異があった。このため、安全策としてtext-decorationではなくborderを使う方針としている例がある。傍線とテキストの間隔の調整などはtext-decorationでは指定できないがborderでpaddingを指定してやれば調整できる。text-decorationでも細かな調整ができるようになるべきなのかどうか。太字やイタリック体は強調の表現に常に適切というわけではなく、一部の言語はそれぞれに西洋の伝統にはない独自の強調表現方法を持っています。日本語は、テキストを強調または強調するための現在達成できていない部分のサポートを必要としていますか?コメント:日本語独自の強調表現としては圏点(傍点)があるが、これもEdgeなど一部を除けば基本的にほぼ使える状況にあるはず。圏点の色指定や、特定の文字を指定しての圏点表示などは調査がいりそう。追加要件としてルビと圏点が被った場合の表示についての記述がある。Firefoxは現在これを両方表示できる。Chrome、Safariは被った場合は圏点を表示しない。これはどちらが正しいのか議論が必要そう。Japanese」と例を上げてあるが、wakitenは傍点と同じでよいのだろうか。組み文字は「ミリ」「明治」のようなもののことのようで、これは既に表示できている。行末や行頭に来てはいけない文字はありますか、それを避けるためにどういう処理が行われますか?コメント:改行の禁則処理に関しての項目。JLREQでは拗音、促音を行頭に置くことを禁止する、いわゆる「強い禁則」を日本語の基本ルールとしているが、過去の出版物を見る限りでは必ずしもそうとも言えない。歴史ある出版社はむしろ拗音、促音を行頭に置くことは許容していたりする。今後Webで日本語のテキストを表示する機会が増えることを考慮すると、画面の小さな端末で1行文字数が少なくても組版の破綻しにくい「弱い禁則」を基本とした方が良いのではないかという意見もある。アラビア語のように単語のベースラインは伸びていますか?コメント:均等割付(ジャスティファイ)に関する項目。日本語は一般的に均等割付処理が行われる言語で、また単語と単語の間にスペースを入れることは一般的には行われず、均等割付のためのスペース調整は文字と文字の間をツメる、アケるという形で行われる。行頭字下げ、行末字上げや行中の括弧類、句読点など前後のツメ・アケ処理に関連する現在規格策定中のプロパティ、text-spacingはここで議論されるべき項目だろう。伝統的な日本語書籍組版には「書字方向のテキストボックスのサイズを本文文字サイズの整数倍にする」というルールがある(いわゆるベタ組)。これもここの項目の範疇だろう。Stylesの仕様はリストや章見出しの番号などに用いられる限定されたシンプルな、あるいは複雑なスタイルを規定しています。Styles.にリストアップされています。カウンターやリストに関して対処しなければならない別の側面の課題はありますか?コメント:リストや見出しの自動ナンバリングに関しての項目。現状<ol>タグで囲ったリストでは各項目先頭に自動でナンバリングされた数字やアルファベットを表示できるが、これの種類の拡張が検討されている。いったような項目も見える。縦書き時のリストナンバーにピリオド付き数字を使う例も挙げられている。}の指定を使うようだが、これはまだ一般的には使用できないとのこと。電書協ガイドでは本文中にリスト構文を使うことを禁止しているが、セマンティクスやアクセシビリティの観点からは本来はリストはリスト構文で記述されることが望ましい。これらのすべてが期待どおりに機能していますか?。コメント:ドロップキャップなど、段落の先頭文字に特殊な組版処理を行う例は日本語書籍ではあまり多くはないが、雑誌などを見るとそれなりの頻度では使われている。これは段落の最初に文字が来たときに限らないが、行中の一部の文字を大きくした際にline-heightがそれに引きずられて変わってしまい、レイアウトが崩れる例はずっとある。Sizingでそのあたりが手当てされるはずなので普及を待ちたい。general?↓ブラウザは、多言語混植の場合と一般的な場合それぞれに対してベースライン位置揃えができていますか?コメント:上付き、下付きなどで使われる行中の一部の文字の位置合わせの指定。上付き、下付き程度ならば現在もう使えるが、多言語の混植となるとちょっとわからない。あなたの言語に特有の段落デザインに関するそれ以外の機能はありますか?コメント:日本語は一般的に段落行頭字下げを行う言語なのでここは相当する。必要に応じた縦書き中の文字の向きの指定はサポートできていますか?コメント:和文中に英文が混じる程度の表記はほぼ表示が実現できているが、アラビア語のような右から左に書くような言語でどうなるかは調査してみないとちょっとわからない。縦横で文字の字形(句読点や括弧類など)を随時切り替える仕組みは既に動いている。セマンティックス的には異なる言語が挟まる際には属性値langおよびxml:langで該当部分を指定し、それに準じてフォントが変わる形が良いように思う。大きなギャップの一つがフォーム内テキストの縦書き時の表示です。現状Firefoxだけがこれをうまく処理できています。コメント:これは日本語組版ではなく完全にWebサイト制作での話。ひとりのユーザーとしてはフォームは横書きでよい気はしている。ドロップダウンメニューなどはそのまま横倒しにして配置されてもちょっと違和感がある。line.↓さらにCSSのtext-orientationプロパティにもギャップがあります。これはFirefoxのみでサポートされています。-webkitのベンダープリフィックスを使用している場合、Safariはバグのサポートを受けています。垂直に文字をセンタリングするときに問題があります。コメント:縦書き中の文字の正立横転指定(text-orientation)は効かないRSがまだ多い。関連してまだUnicodeの標準的な縦書き時の文字の向きの基準に準拠できていないRSもあり、表示するRS次第で文字の向きが変わってしまうような現象も起きている。Kindleでのキリル文字、ギリシャ文字などがこれに相当する。1桁の英数字を正立で表示させたい場合に一般的に行われているTIPSとして「全角文字に打ち替える」というものはある。困るのは必ずしも全角文字があるわけではない記号類なので早めのギャップ修正が望まれる。EPUB制作では現状text-orientationがアテにできないため、代替としてtext-combine-uprightを使うということが行われている。Tests:↓text-combine-upright:allは全てのメジャーなブラウザで動作しますが、Edgeではベンダープリフィックス付きの-ms-text-combine-horizontalを使う必要があります。text-combine-upright:’digits’(指定テキスト内の何桁の数字までを縦中横表示するかを指定する自動縦中横の指定)は現在Edgeで(ベンダープリフィックス付きで)のみサポートされていますが、Edgeは数字の横幅を縦組みの行の横幅に引き延ばして表示してしまいます。コメント:縦中横は動作する環境がほとんどだと思われるが、text-combineのみをサポートしていてtext-combine-upright(こちらが最新のプロパティ)のサポートが遅れているRSはあり、またまだベンダープリフィックスが必要なRSもある。縦中横の際の字形変化の挙動に関しても統一はされておらず、何桁あっても変形させて1emに入れようとするもの(これを1桁英数字の場合にも適用してしまうのがEdge)、変形はせずに横書きで表示し、文字数が多すぎると隣の行に重なる実装をしているものの2種に大別される。一部RSではフォント内のグリフ情報を呼び出して等幅3分字形、等幅4分字形などで表示するような実装も見られるようだ。表組みの個々のセルに対してwriting-mode:vertical-rlの指定をすると、そのセル内のテキストが縦組みで表示されます。Explorer、およびGeckoのブラウザ(Firefox)では正常に動作します。Blink(Chrome)とWebkit(Safari)のブラウザでは、テキストは水平のままで文字を左に回転させて表示してしまいます。いずれにせよ正しく表示させるために、これらのブラウザでセルの高さを設定する必要があることにも注意してください。コメント:表組みの項目行のみ縦組みというのはかなり目にはするので実現できるようになることを期待したい。text-align↓たとえば(padding、marginなどの)方向の指定のために上下左右ではなく「論理的」な値で指定することで、混乱を避け時間を大幅に削減できます。Properties仕様で論理的な指定のための値を決めていますが、これはまだ現在はエディターズドラフトの段階です。そこに記述されているプロパティの一部は、すでにブラウザでサポートされています。Edgeではtext-alignのstartとendの指定値はまだサポートされていません。culture?↓あなたの言語には注釈、脚注、後注などに対して何らかの特別な文化的要望がありますか?コメント:注に関する項目。日本語書籍での注の表示のひとつに「割注」があり、これはJLREQにも記述があるのだが、アルゴリズム的にはWebやEPUBでの実現は難しそう。個人的意見としては電子では必要ないのではないかと思う。紙の本の割注も決して読みやすいわけではない。Paragraphs」の中に項目を立てるべきかもしれない。EPUBで画面を分割して脚注を表示するのはコンテンツによってはニーズがありそうだがまだ一般的なブラウザでの実現はできていない。epub:type=”footnote”の指定による脚注のポップアップ表示は現在iBooksおよびKoboのiOS版、EdgeのEPUB表示(脚注のテキストが同一のXHTML内にある場合のみ)で実現できている。handled?↓ノンブルや柱文字の扱いに関して特別な規則がありますか?コメント:ノンブルや柱文字に関する項目。現状EPUBではOPFに記述された書名が柱に表示される実装を行っているRSが多いが、一部のRSではXHTMLのTITLEタグに記述されたテキストを表示するようだ。いずれにせよRS側の独自処理であり、制作側がCSS等で指定できるわけではない。LTR?↓いくつかの文化では、ページ領域とページ進行方向を西洋のそれとは非常に異なる形で定義しています(例:日本語の基本版面)。ページ進行方向は右→左ですか、あるいは左→右でしょうか?コメント:EPUBでのページ番号に関する話として、実ページリンクの話題がある。これは電子教科書方面でのニーズから策定された規格のようで、リフロー型EPUBのXHTMLの中に紙の本での各ページ開始位置をタグとして記述しておき、RS側の処理でページ番号を表示させるものだ。Kindleもパブリッシングガイドラインで対応を表明した(サーバ側処理が必要なため表示未確認)。専門書などでは底本内にとても多くのページ番号に基づく参照情報があり、その中には外部の他の本に対する参照情報も当然多数含まれる。EPUBには現状外部の他のEPUBパッケージ内の特定の箇所にリンクを貼る手段がない。このため、おそらく専門書のリフローでの電子化を今後進めていくには実ページリンクを広く使っていく必要が出てくるのではないかと考えている(あるいはフィックス型で電子化するかだが・・・)。言語は時に、その影響の圏外では通用しないことをすることもあります。これは以前には言及されていなかった追加項目に対応するための項目です。サポートなど)に関連する項目にも関係します。locally?↓SVG、HTML、Speech、MathML、その他の仕様はもちろんのこと、スクリプト固有の要件のレビューが必要な他の多くのCSSモジュールがあります。推測して用語を補足せざるを得なかった箇所もありますし、自分的にスコープ外の部分は流してもいます。全文の忠実な翻訳ではないことにご留意ください。意図の取り違え、単純な間違いなどありましたらご指摘いただけると助かります。関して肩文字→柱文字に訳語を修正しました。フィードで購読することができます。コメントを残すか、ご自分のサイトからトラックバックすることができます。スパム防止のためコメントは承認制とさせていただいております。Tajimaこちらにて、電子書籍&Web制作を担当しています。このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。整うことを願って、現場からの声を発信していこうと目論んでおります。当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。License.『電書魂』のコンテンツはクリエイティブ・コモンズによりライセンスされています。記事名の記載と、記事へのリンクを貼って頂ければ、コンテンツを自由にご利用いただくことができます。