EPUB 3.1 開発計画の概要 2015/10/20現在

EPUB3.1の開発が始まっています。状況をざっと整理しておきます。

・開発計画承認:2015年7月8日
・議長:Markus Gylling, IDPF、Tzviya Siegman, Wiley
・副議長:Garth Conboy, Google、Brady Duga, Google
・期限:2016年1月最初の草稿仕様、遅くても2016年第4四半期終了

開発計画概要:

EPUB 3.1 Work Plan

フォーカス
・ばらばらに開発されたモジュールの統合
・単純化。あまりサポートされていない機能は廃止しても良い。
・スクリプトと対話性について規則を明確化
・オープンWebプラットフォーム:W3CのDigital Publishing Interest Groupとベクトルを合わせる、サーバーサイドの表現
・新機能 機能要求に基づき追加が可

制約
・できるだけ後方互換性を保つ
・実装可能性を考慮して、新機能は保守的に追加

レポジトリー:https://github.com/IDPF/epub-revision/wiki/EPUB-3.1

10月8-9日初回のF2F会議(ニューヨーク)が開催された。参加者36名。
 議事録

【テーマ別コンセンサス】
・Journals(情報誌)―特別なサブグループにはしない。
・Metadata―特別なメタデータ表現言語は要求しない。外部リンクとする。
・Web-friendly manifestation―EPUBのWebフレンドリーな表現が必要なことに合意。
・Serialization―HTML表現の検討を続ける。epub:接頭辞はHTMLでは使えないのでどうするかを検討する。当面ssmlはHTMLでは表現できないがXHTMLのみ可とするで良い。
・Scripting―特別な合意はなし。
・External resources―外部リソースが必要な分野(スクリプト、リーダーのためのデータ、フォントなど)を認識。
・Restructuring―傘になる仕様を検討する方向。

【感想】
一番熱が入っているのはEPUB-Webの分野のように見えます。また、HTML表現についてもどうやら認められそうな雰囲気です(現在はXHTMLのみ)。HTMLについては予定調和的コンセンサスな気がします。

EPUB3.1というマイナーなバージョン番号と短い開発期間としては、大きなテーマが盛り込まれているのが懸念事項です。開発がスタートしたばかりなので、今のところ議論百出です。今後どちらの方向へ進むか興味深いところです。個人的にはEPUB-Webに期待するところが大きい。

AH Formatter事例紹介セミナー 10月16日(金) に開催します。講演数を増やして充実しました。

2015年度のAH Formatter事例紹介セミナーを今週、金曜日、午後13:20~18:00に開催致します。

いま、XML分野では、DITAが主要な応用領域となっています。
今回は、DITAの事例を日立金属株式会社様PFUテクニカルコミュニケーションズ株式会社様よりご講演いただきます。
その他、慶應義塾大学様より「電子書籍と博士論文インターネット公開義務化でのPDF活用例と問題」のご講演など、盛沢山の事例紹介となっており、ご参考にしていただけるかと存じます。

明後日開催で日時が迫っておりますが、お時間の余裕がございましたら、ぜひご参加ください。
今からでもご予定に入れていただきますようご案内申し上げます。

題名:アンテナハウス 事例紹介セミナー Autumn!
日時:2015年10月16日(金) 13:20〜18:00
場所:関東ITソフトウェア健保会館会議室(新宿区・大久保)
詳細のタイムテーブルとお申込み:こくちーず

SVG(草稿)

最終版: SVGとは

SVG (Scalable Vector Graphics)は、XMLを応用したマークアップにより、2次元画像を線画で表す(ベクトル画像という)形式である。ベクトル画像とラスター画像の混在も記述できる。単独の画像ファイルとして扱ったり、HTML5の中に直接記述したり、他のXML言語の中に埋め込んで使える。Javascriptなどによるプログラムを組込んで対話的な文書やアニメーションを表現できる。

歴史
SVGはW3C (World Wide Web Consortium)が策定したものである。2001年9月にV1.0が勧告となり、2003年1月にV1.1となった。その後、2011年8月にV1.1第2版となっている。V1.1第2版までに長い年月が経過した。SVGは初期の携帯電話で扱うには仕様が重すぎたため、SVG BasicやSVG Tinyというモバイル用の仕様が策定された。しかし、その後、携帯端末でもフルブラウザが使える時代となりモバイルSVG仕様の必要性はなくなった。SVG 1.1の第2版はSVG Tinyの仕様が逆に本体仕様に反映されるなど、V1.1からかなり大幅な変更が加えられている。現在は、HTML5やCSS3と整合性のよいSVG 2.0の仕様開発がすすめられている。

ブラウザサポート
現在、SVGはGoogle Chrome、FireFox、Internet Explorer (IE)、 Microsoft Edgeなどの主要なブラウザで表示できる。しかし、当初マイクロソフトはVML (Vector Markup Language)という独自のベクトル画像形式を提案し、IEはVMLを採用していた。IEがSVG 1.1第2版を実装したのはIE9からである。そして、IE10ではVML機能が削除された。このようにして、長い時間がかかったが、現在、SVGはWebの標準画像形式の一つとなった。

HTML4までは、SVGは外部の画像として用意したり、object要素を利用してSVGで記述した画像を埋め込んだ。HTML5ではbody要素の内部にsvg要素を直接記述できる(インラインSVGという)ので、SVGによる線画マークアップをHTML5に張り付けることができる。またブラウザのJavascriptで簡単にSVGのコンテンツを操作できる。

特徴
・svg要素の内部に画像を記述する。svg要素は入れ子になってもよいので画像を断片として再利用できる。グループ化したり、コンテナに入れたりできる。
・線画は汎用のパスで表すが、線、多角形、円・楕円、などの基本図形を表すタグと属性が定義されている。
・フィルターを記述できるので、ぼかし、影付けや照明などの効果を指定できる。
・文字は文字コードを保持するテキスト列として表せる。但し、テキスト列内で自動改行やワードラップしないので、SVGの作成時に行毎にマークアップする必要がある。
・文字の形や位置がずれないようにするため、Webフォントを使ったり、SVG独自のフォント記述(SVGフォント)ができる。
・SVG はSMIL (Synchronized Multimedia Integration Language)を使って動画および静止画をメディアの部品として利用できる
・CSSスタイルシートでスタイル付けできる。多くのプロパティをCSSと共有しているが、SVG独自のプロパティも定義されている。

作り方
簡単なものはSVGのマークアップをテキストエディタで編集したりプログラムで作成することができる。複雑な画像はIllustratorなどで編集してSVG形式で保存して作成するのが普通である。また、Inkscapeのような無償のSVG編集ソフトもある。

EPUB
EPUB3ではSVGの画像ファイルをコンテンツ文書として指定することもできるし、HTML5の内部にSVGで記述した画像を含めることもできる。

外字(草稿)

最終版:外 字

外字は、使用頻度の少ない文字の配置場所、あるいは、その字形の表し方をいう。漢字のような図形に意味を持たせる文字では外字は常に大きな問題である。しかし、活版の時代、文字コードのサイズが小さい時代、現在のように大規模文字コードが使われる時代で外字の問題は変質している。

活版印刷の時代には漢字は活字として用意され、文撰職人が原稿を見ながら文撰用の棚に並んだなかから活字を拾った。この作業を効率化するため、印刷会社では漢字を使用頻度の多い順から、大出張、第一出張、第二出張など、外字として分類し、棚に並べるにあたりその配置を工夫していた。大出張は使用頻度の多い文字なので、中央のかなの上部で拾いやすい位置に配置し、外字は使用頻度が少ない文字なので活字を拾うのに背を伸ばしたり、かがんだりしなければならない位置に置かれた。文撰用の棚が沢山ある場合は、さらに使用頻度の少ない外字は工場の一角に別の棚を設けることもあった。

1970年代末にJIS漢字コード表が制定されたが、初期のJIS漢字コード(JIS C 6226:1978)では、第一水準漢字、第二水準漢字、非漢字を併せて6802文字が規定された。しかし、①、②などの丸付数字や、㈱、㈲を初めとして利用頻度の多い文字で規定されないものがあった。情報機器のメーカはJIS漢字コード表に規定されていない文字を独自に選定し外字として独自の文字コードを割りあてた。JIS漢字コード表は、第一バイト21~7E(94区)、第二バイト21~7E(94点)の矩形領域に文字種を割り当てるものであったが、一部の区、点は文字が割り当てられていなかった。そこで外字コードの割り当て方法としては、①JISコード表の区点範囲で文字が割り当てられていない空き領域に独自に追加文字を割り当てる方法、②JISコード表の表外の領域に追加文字を割り当てる方法(IBM拡張文字は7F区以降に割り当て)があった。

1970年代末にはワープロ専用機が登場したが、ワープロ専用機の多くはメーカーがあらかじめ空き領域に割り当てた外字(システム外字)に加えて、ユーザーが文字の字形をデザインするツールを用意し、ユーザーがデザインした外字(ユーザー外字)も使用可能とした。パソコンのMS-DOS、初期のWindowsやMacintoshも独自にシステム外字を定義した。このようにシステムで定義する外字は機種依存文字とも呼ばれ、システム間で非互換の文字が多かったため、JISコード外の文字を正しく情報交換するのが困難であった。

JIS C6226は、その後JIS X0208になり、さらにJIS X0208を包含し、1万文字を超える文字を規定するJIS X0213が制定された。そしてWindowsやMacOSでJIS X0213の文字がすべて使えるようになり、またUnicodeの普及など文字集合が大規模化することで、システム外字が必要という事態は少なくなった。しかし、現在は、新しい外字問題が生じている。

漢字の一番大きな分類は字種である。字種とは文字の意味(字義)や文字の読み(音)、正字・俗字のように歴史的経緯から見て同じ文字であるみなされる文字である。一方、一番細かい分類は目に見える文字の形である字形(デジタルフォントではグリフという)である。一つの文字に対してデザイン差までを考慮すれば字形は無数になる。これに対して、JISコード表は漢字の字体を符号化する。字体とは字形を抽象化した字の骨格であるとされている。JISコード番号には抽象的な字体が割り当てられており、そのコード番号の文字は字形(グリフ)を通じてしか可視化できない。印刷されたJISコード表に記載されているのは字形であるが、これは例示とされている。

現在、外字が使われるのは次の2つのケースがあるだろう。使用する文字コードの枠組みを、例えば、JIS X0213:2004と決めたとき、①JIS X0213:2004で規定する字体の範囲外の字体を使いたいとき、②JIS X0213:2004で規定する字体であるが、グリフが使用するフォントにない場合もしくは使いたいグリフをフォントに依存することなく指定したいときである。①は1970年代から継続する伝統的な外字問題である。

例えば、EPUB3の制作ガイドである電書協ガイドでは、「JIS X 0213:2004 の文字集合にない文字は外字画像化」するとされている。外字画像方式では外字には文字コードを使用しないで、外字を画像で表し、その画像を文字と同じ大きさで行中にインライン配置する。しかし、外字画像を利用すると、文字コードがないので検索ができなくなったり、音声読み上げができないなとの不都合が生じてしまう。

基準とする文字コードの枠組みで表せない文字は画像などで表すことになるのはやむをえない。外字画像を使わないようにするには基準とする文字コードをより大規模な文字集合にするしかない。

一方、②に属する問題は解決方法がある。市販のEPUB電子書籍にはJIS X 0213:2004 の文字集合で規定されている文字で、JIS X0213:2004に対応するフォントで使えるグリフが外字画像化されているケースもあることが、facebookなどのSNSなどで報告されている。これは制作時の環境のフォントではグリフがないところで、文字の形を優先したいという趣旨かもしれない。もし、このような問題が予想される時はフォント埋め込みが一つの解決策となる。使用したいフォントが埋め込みできない場合は当該の文字だけのフォントを制作してEPUBにフォントを埋め込むことを推奨したい。