7インチタブレットには文字ものの固定レイアウト書籍リーダとしては不向き。文字ものには10インチが欲しい

JPO・コンテンツ緊急電子化事業(緊デジ)フォーマットの第一次素案ではターゲットデバイスを7インチタブレットとしています。

そこで、7インチタブレットを書籍のリーダとしてどの程度まで使えるかを調べてみました。

〔結論〕現在主流の7インチタブレットは文字中心の電子書籍を読むためのリーダとしては不十分です。現状では、漫画・イラスト/写真集のように文字の少ない書籍でないと読者にはつらいでしょう。

〔注意〕現在の主流7インチタブレットの画面解像度は縦1024×横600ドットです。そして上の結論は1024×600ドットの場合です。新しい7インチタブレット製品は縦1280×横800ドットのものが出てきていますので解像度が上がると結果はまた変わると思います。

〔計算〕7インチタブレットのひとつであるICONIA Tab A100(縦1024×横600ドット)の画面で、書籍版面上の1文字に割り当てられるドット数を計算すると次のようになります(次の図には比較のためiPadの値を併記。また、余白はトリミングしないという前提です)。

計算式:
画面上の1文字に割り当てられるドット数=文字の大きさ(ポイント)/72 × 横ドット数/判型横幅(インチ)

〔実機確認〕実際の端末で表示すると、文字中心の頁をすいすい読むには16ドット/1文字くらい必要です。上の図では黄色にマークしたあたりが普通に読めると思われる範囲です。ただし、読みにくい・読みやすいというのは個人差があると思います。一般にPCの画面で漢字を表示するには1文字16ライン必要といわれていることと対応するように思います。

・ICONIA Tab A100で、16ドット/1文字になるのは新書の場合です。B6判、四六判では10ポイントの文字が16ドット/1文字となります。市販の書籍の頁を表示すると文字が少し小さくなります。

・iPadは横768ドットありますので、iBooksではA5以下の判型の文字が16ドット/1文字となります。つまり10インチのタブレットであれば市販書籍の頁をそのまま表示して読むことができるでしょう。

・余白をトリミングすると、トリミングしないときよりも版面を大きく表示できます。そこで、電子化にあたって余白量をできる限り小さくするような処理が望ましいことになります。つまり固定レイアウト電子書籍では余白をプリントとは異なる使い方をする必要があると思います。

〔テストデータ〕CAS-UBで判型別に基本版面をPDFで作成してみました。下記よりご覧いただくことができますので、端末をお持ちの方はお試しのうえ、コメントにご意見をお寄せください。

基本版面別組版サンプル

「電子書籍制作仕様書 第一次素案」Web公開版(3/20)と配布資料の相違点

出版デジタル機構のWebページに公開されている「電子書籍制作仕様書 第一次素案」(2012年3月20日夜公開されたもの)と3月23日にフォーマット説明会場における配布資料(3月23日付け)を付き合わせるといくつか変更された点があります。

電子書籍制作仕様書 第一次素案

以下に気がついた変更点を列挙します。

B-1:リフロー型電子文書(DTPから制作する場合)
●アーカイブ用データ保存の項
Web)本ファイルを(2)アーカイブ用中間フォーマットファイルとして納品する
紙)本ファイルを(2)アーカイブ用中間交換フォーマットファイルとして納品する

●配信用電子書籍データ書き出し(パッケージング)の項
Web)校正は機構の用意する校正用仮配信サーバーを利用する。校正の方法や回数などの詳細は現在検討中
紙)*校正は機構の用意する校正用仮配信サーバーを利用し、1回のみ行なう。
(追加)
*出版社は仮配信サーバから電子書籍をダウンロードして校正する
*修正は中間交換フォーマットに戻って作業し、配信用データを再書き出しする

(注意)読点と長音は配布資料のまま

B-2:リフロー型電子文書(印刷底本からテキスト作成する場合)
●目次の項
Web)目次リンクを作成する。章・見出しなどの大項目は相互リンク、その下の小項目は片リンクとする
紙)目次リンクを作成する。詳細は別紙を参照

(注意)別紙は配布されていない

●校正の項
Web)校正はテキスト作成時(原稿校正)とパッケージング完了時(実記などによるレイアウト校正)の両方で行う
紙)校正はテキスト作成時(原稿校正)とパッケージング完了時(実記などによるレイアウト校正)の計2回のみ行う

注意)「実記」は配布資料のまま

Web)校正は機構の用意する校正用仮配信サーバーを利用する。校正の方法や回数などの詳細は現在検討中
紙)・パッケージング完了時の校正は機構の用意する校正用の仮配信サーバーを利用する
(追加)・出版社は仮配信サーバから電子書籍をダウンロードして校正する
(追加)・修正は中間交換フォーマットに戻って作業し、配信用データを再書き出しする

注意)「仮配信サーバ」は配布資料のまま

●アーカイブ用データ保存の項
Web)本ファイルを(2)アーカイブ用中間フォーマットファイルとして納品する
紙)本ファイルを(2)アーカイブ用中間交換フォーマットファイルとして納品する

JPO・コンテンツ緊急電子化事業(緊デジ)フォーマット説明会報告

3月23日、15時から17時に日本出版インフラセンター(JPO)が行なった「JPO・コンテンツ緊急電子化事業(緊デジ)フォーマット」(緊デジフォーマット)の説明会に参加しました。この説明会は、電子書籍制作会社、電子書籍販売会社、出版社制作部門担当者向けのものです。標準化委員会の沢辺 均氏よりフォーマットについての説明がありました。

説明の内容は、「出版デジタル化機構」のWebページより公開されている電子書籍制作仕様書 第一次素案に沿ったものでした。

電子書籍制作仕様書 第一次素案

注)説明会場において配布された資料をWebページ(3/23夜時点)と付き合わせたところ改訂された点がありました。右に改訂内容を一覧にしました。「電子書籍制作仕様書 第一次素案」Web公開版(3/20)と配布資料の相違点

以下では、Webページに公開されている仕様と重複する部分もありますが、説明会の内容のメモと会場での質問と回答です。

1.緊デジフォーマットは、緊デジ事業で制作する電子書籍の仕様書であり、同時に出版デジタル機構で制作する電子書籍の仕様書としても使う。(緊デジ事業ではJPOから「中核企業」に電子化を発注することになっており、3月23日に中核企業は株式会社パブリッシングリンクと決定した。)

以下、フォーマットの策定にあたっては次のことを考慮に入れた。

(1) 現実に販売できることを重点とした。ドットブック、XMDFは現実に販売する電子書店が多数ある。EPUB3は現実に作れる環境が整いつつあるが販売している店は少ない。PDFは販売している電子書店が少ないので採用しない。

(2) 技術の変化に耐えること。EPUB3が普及する可能性は高い。そこでEPUB3に簡便に手間をかけずに変換可能なフォーマットであること。フィックス型もそれなりに作る。再度OCRできる。

(3) 低コストでやりたい。

2.説明の段取り
・3月23日、27日に東京で説明会を行い、4月9日に東北でも説明会を行なう。
・説明会で意見が出たら、それを議事録とする。
・4月中には仕様を公開する。

3.電子書籍の制作
・緊デジ事業での制作はパブリッシングリンク(中核企業)が差配する。JPOはパブリッシングリンクに制作を発注する。
・出版デジタル機構は100万タイトルの制作を目指す。
・緊デジフォーマットは出版デジタル機構でも採用する。

4.緊デジフォーマットはA、B2種類で3パターンある。
A:フィックス型電子書籍であり、写真集、漫画型のようなものを対象とする。
B:リフロー型電子書籍である。リフロー型は制作コストの相違からB-1とB-2に分けた。この二つではコストに重大な差がある。
B-1はDTPデータなどのなんらかのデジタルデータがあるもの。
B-2は紙のもの。入力と底本との付け合せを含めて1文字1円を想定している。コストを減らすことができれば大歓迎である。

5.入稿と納入形式説明

A:フィックス型電子書籍
入稿データは紙の本で底本は1冊(可能なら2冊)

納品物は画像データと配信用データ
(1)画像データはすっぴんのものをアーカイブする。
(2)配信用は軽くなるようにする。

画像データはスキャンして作る。スキャン範囲は次の通り。
(a)カバー
・RGBカラーでスキャンし、販売時の書影につかう。
・背もスキャンする。
・折り返しから折り返しまで全部取る。

(b)底本
・グレースケール 600DPI原寸
・見返しの印刷は現場で判断する。
・本文は白でも一気にスキャンする。
・ゴミは飛ばす

アーカイブ用の保存フォルダー
・フォルダー名 20桁のe-コード コミックはe-コードが普及している。

配信用電子書籍仕様
・TIFFから変換する。
・余白に関しては迷っている。iPadなどは天地・小口・のどはビューア側で余白を自動的に取る。
スマホは余白が多いと厳しい。本には断ち落としのページがあるので、余白をギリギリまで落とすと困る。結局、余白のトリミングは頁ごとに判断する必要がある。
・配信形式はEPUB3にしたい。大きな決断である。とはいえ、強い要望があれば、XMDFも可能性がある。
・目次はクリッカブルマップによるリンクをつける。この仕様はコストアップの要因になるので、かなり揺れている。
・画像の長辺は1536ピクセル。7インチタブレット。

クレジットどうするか?
・紙の本の奥付けはスキャンする
・電子書籍のクレジットを追加する

B-1:リフロー型(DTPデータ)
入稿データ
・底本+DTPデータを提供する
・DTPのアプリケーション種類については相談して対処する。写研はどうするか?という相談受けた例もある。
・リフローはEPUB3間に合わないので、ドットブック、XMDFから作る。
・広告は捨てる。(スキャンとの違い。)
・奥付けは写真にする。

写真の権利関係を考慮する必要性を鑑みて、出版社の指示があるときは、写真をはずすことを可能とする。
・ページ幅60%以内の図表は近傍の段落の間におく
・ページ幅60%以上の図表は単独1ページとする
・図表のキャプションはワンセットで画像化する。

JIS第一水準、第二水準の範囲外はあえて画像を差し込む方式をとる。
タグにCIDコードをつける。CIDからUnicodeに変換できる。

交換形式からほぼ自動的にEPUBに変換できる。

校正は出版社が1回する。実際は出版社は校正はかなり苦労していると聞いている。
その理由として、現在のリーダはプリントアウトの機能が消えている。そうするとプリントしての校正ができない。
赤字をいれるときの戻し方ははっきりしていない。
ネットワーク上に出版社専用の書店ができないか、と考えている。
プリントができるようにする。
仮配信サーバからダウンロードして修正する。
中間交換フォーマットに戻って修正する。

B-2:リフロー型(紙:印刷底本からテキスト作成する)
・文字入力を人間がする
・平均10万円以上かかる。
・2回の校正を行なう。
・仮配信サーバからダウンロードして校正するスキームを作る。
・中間交換フォーマットに戻って修正する。
・アーカイブは中間交換フォーマットで行なう。

■質疑応答
1) パブリッシングリンクの出資会社は?
回答)
・ソニー、講談社、大日本、凸版ほか15社である。Webページからはサードプランニングが1社抜けている。
(永井専務理事)

2) 電子書籍の制作の手伝いをしたいが、出版社から制作会社に発注がいくのか。
回答)
・出版社から個々に発注はない。
・今後は電子化事業者への発注業務は、パブリッシングリンクから発注が行く。4月以降の段階で話をするのが一番良いだろう。
・東北の被災地支援がスキームに入っている。安くやるので中国でやる、というのはお断り。何からの形で被災地の復興支援として行ないたい。
(永井専務理事)

3) フィックス型でPDFの選択はなかったのか?
回答)
・PDFといえば透明テキスト付きPDFが多いだろう。しかしPDFの透明テキストを検索する機能は、電子書店のリーダの中では実現できていない。
・PDFは画像をくるんでいるものという理解であり、画像があれば必要に応じていつでもPDFに変換することが簡単にできる。
・効率を考えるとPDFでも良いが、PDFはアドビが主導権をもっているし、政治的に変わるのは望ましくない。
・PDFは売れないものを作るという点で脱落である。
(沢辺氏)

4) タグのつけ方は自由で良いのか?各社のアプローチの相違点はどうするのか?出版デジタル機構の方からサンプルは出てくるのか?
回答)
・中間交換フォーマットはXMDFとドットブックを包含しているので、どちらにもできる。
・そこの世界にこだわるのはやめようよ。という意識である。
・ボイジャーとシャープの両方が実現してきたことを包含していれば良い。
(沢辺氏)

5) フィックス型が中心とのことだが、それなら東北でもできる。東京で開催したのはなぜか?
回答)
・20億円をいきなり東北にもっていったらとまどうだろう。
・東京で出版社が長いお付き合いをしているところをきることはできない。
・東北で請け負ったけれども、翌年ゼロでは困るだろう。
・来年3月までとりあえず伸びた。
(永井専務理事)

6) 発注先の選択について客観性の確保はどうするのか?本ごとにやるのか?評点でやるのか?
回答)
・入札で安いところにお願いするわけではない。
・1万円でかかるものが1万2千円でもよい。
・事業の趣旨を生かして、多少値段が高くても良いのでという中核企業の公募をかけた。
(永井専務理事)

5) 現在、出版社の依頼で印刷用データを作ったりしている。出版社がスキームを通して、当社に出すように指名できるか?
回答)
・6万タイトルを電子化スムーズにやるには馴染みの企業に頼むのが良いが、それだと本来の趣旨である東北にお金が回らない。
・ジャンル別に優先順位をつけるかもしれない。
・16時の段階で仮申請175社 42,000タイトル。
・175社の中に大手の出版社は入っていない。だから間違いなく6万タイトルは超える。そうなると優先順位をつけざるを得ないだろう。これから計画を立てる。段取りを決めないといけない。
・期限は2013年3月末まで期間延長された。5月以降実施する。
(永井専務理事)

6) アーカイブファイルは誰が管理するのか?
回答)
・出版デジタル機構が代行したものはできるだけ速い機会に販売する。
(沢辺氏)

7) DTPデータから、固定レイアウトのEPUB3を制作しても良いですか?
回答)
・主流になるとは思わないが、制作してもよい。
(沢辺氏)

8) リフロー型電子書籍においては、レイアウトの再現性についての仕様がないですが、どの程度まで要求しますか?
回答) 
・小画像の配置を「近傍の段落の間」と言っているくらいでレイアウト再現性はあまり問わない。(沢辺氏)
・補足すると、再現性を要求する場合は出版社が自分で負担することになるだろう。
(永井専務理事)

9) 固定レイアウトのEPUB3はいろいろな作り方があり、今回の第一次素案だけではどうしたら良いかわからないですが。
回答)
これについては、今後仕様をつめて公開する。(沢辺氏)

■免責事項のお願い
このメモは個人的に理解した内容をまとめたものです。できるだけ正確を期したつもりですが、聞き違いや理解の間違いを含んでいる可能性があります。メモに記載された情報の利用はご自身の責任において判断されるようにお願いします。メモの内容が間違っていたことに関する責任は負うことができません。

電子書籍フォーマットポリシー第1次案への感想―市場の変化に備えるには

出版デジタル機構から16日「電子書籍フォーマットポリシー第1次案」が公開されましたので、ざっと読んでみました。

リンク:電子書籍フォーマットポリシー第1次案

最初に私の理解したところを整理しておきます。

1.方針概要

電子書籍の数を増やすことを最優先とする。

2.フィックス型とリフロー型

フィックス型を大量に作成して市場に投入し、市場ができるにつれてリフロー型の点数を増やす。

3.フィックス型フォーマット

本文画像を600dpi程度の高品質でスキャンして蓄積する。
まず、XMDFかドットブックを作成し、様子を見ながらEPUB3の作成に切り替える

4.リフロー型フォーマット

当初はXMDFとドットブックを作成する
納品されるファイルの仕様を厳密に規定する
中間交換フォーマットもアーカイブする

以上の1~4の方針となっています。以下は感想です。

この方針は基本的に同意できる部分が多いし、まず大勢が支持するものと思いますが、それだけに、現状ベースでありかなり保守的です。しかし、市場の変化に対応できないのではないかという不安があります。たとえば、強力な市場=販売チャネルが登場したときに、それに迅速に対応できないと、せっかくためたデジタルデータが宝の持ち腐れになります。具体的には、この方式を利用する出版社にとっての当面最大のリスクはAmazonに対応できない事態が生じる可能性でしょう。Amazonと機構でどういう話し合いがなされたかは知りませんが。そう思ってみますと、角川グループはAmazonと契約したと伝えられますが、機構の賛同出版社に入っていませんね。邪推しすぎかな?

出版デジタル機構(仮称)準備会・賛同出版社:239社(2012.3.13現在)

では、このようなリスクに備える対策はというと、電子書籍を作るためのデータをコンピュータで100%自動変換できる形で蓄えることでしょう。つまり新しい形式の電子書籍を作り出すときには変換を100%自動で行なうことができることを保証しなければなりません。この実現はそう簡単ではないですが、「完全な」自動変換ができれば低コスト・短時間で新しい形式にできます。もし、そうでないと1点毎に変換後の書籍を検品・校正する作業が発生することになり、この作業にコストと時間がかかり、二重投資かつ時間的なボトルネックとなります。

自動変換を妨げるものはいろいろあります。

まず、外字です。この点からドットブックでオリジナルコンテンツを作るのはあまり推奨できません。ドットブックはシフトJISのため表現できる文字数が不足しており、外字を画像で表しているケースが多いためです。XMDFは理論上はUnicodeを使えるはずですが、実際はシフトJISにすることが多いようです。シフトJISを使うときは外字を画像で表しますが、その文字のUnicodeのコードポイントをかならずどこかに保持しておく必要があります。このあたりの取り決めが必須です。

自動変換を妨げるものの2つめは構造です。本文の見出し、図表のキャプション、上付き文字、下付き文字、注など最低限の必要な項目を調べてこれらをきちんと構造化しておく必要があります。現在のXMDFやドットブックは、見栄え優先、すなわち、フォントの大きさなどで見出しを示すといったタグの使い方をしているものが多いのですが、こういうタグの使い方は変換の自動化にあたっての阻害要因になりますので禁止しなければなりません。タグ付けのガイドラインの整備と準拠が必須です。

既存のDTPデータもPDFデータは無論ですが、私が調べた範囲では、既存のリフロー型ドットブックとXMDFでさえもソースをほかの形式に自動変換することは困難です。すなわち再利用性があまり高くありません。完全自動化ができないと人手による処理加工作業、それにともない検品・校正が必要になり再利用するときに新たなコストと日数が加わります。今回、あらたにリフロー型ドットブックとXMDFを作るときはこうした事態を繰り返さないように相当な注意が必要です。EPUBも不用意につくると同じ問題が起きます。つまり、タグをつけたら再利用性があるというわけではないのです。

中間交換フォーマットをアーカイブするといっています。「中間交換フォーマットV1.1(2月13日版)仕様書をざっとみたところではまだ実用的に完成していないのではないかと思います。完成度を高めるには、もっと徹底的に使ってみる必要がありますし、オープンな変換実証実験の繰り返しが必要と思います。

EPUBをメジャーにするには「隗より始めよ」

EPUB3が制定されて「JBasic」、「EPUBJP」、「EPUB3用XHTML作成ガイド」のような規約書がでてきました。

JBasic
EPUBJP: EPUB3日本語ベーシック基準
・EPUB3用XHTML作成ガイド(技術評論社https://gihyo.jp/dp)

また、「EPUB3スタンダード・デザインガイド」のような仕様の解説書が出てきて、EPUB3の仕様に関する技術情報が増えてきました。

ところで、このような技術的な規約集はEPUB3で出すのが最適な分野だと思います。

・規約集は参照して初めて意味があるので、厚い書籍にしたら持ち歩けないですし、手元でパッとみようとしたらスマホで見るととても良いと思います。
・横書きなので無理にEPUB3にする必要はなく、EPUB2でも十分。
・EPUB2ならとりあえずiBooksをはじめとしてリーダはあります。
・EPUB版をiPad、iPhone、Androidなどの端末に入れておけばいつでも参照できます。

しかし、これらの中でEPUBで提供されているのは「EPUB3用XHTML作成ガイド」だけであとは皆PDFと紙です。推進者がEPUBを使ってないんじゃねー。こんなところにもまだままEPUBがメジャーになれない理由があるのかもしれませんね。

ということで、かくいうCAS-UBもサンプル書籍をもっとふやさなくっちゃなー。

隗より始めよ(かいよりはじめよ)

IDPFに加入、EPUBをはじめとする電子書籍の普及をめざす

CAS-UBのサービスを始めて6ヶ月経過して、現在、V2になりました。機能面ではまだよちよち歩きというべき段階であり、今後さらに検討・改良すべき項目が沢山あります。これは今後強化を続けます。

基本的なところとして、この仕組みで実際に電子書籍を制作できることは既に立証できたと考えています。そうすると、あとはどれだけの人に使ってもらえるか、ということなのですが、この点はEPUB3の普及にかかっています。

EPUB3が普及しなければ、現状のCAS-UBの利用価値も小さいことになります。なんとかEPUB3の普及を図らなければなりません。そんなことで、3月6日にEPUB3の仕様の制定しているInternational Digital Publishing Forum (IDPF)に加入することにしました。EPUB3の普及のために努力したいと考えています。

UTR#50: 文字の方向特性に関するカウンター提案の概要紹介

縦書き時の文字の方向特性を決めようとするUTR#50に関して新しい提案が3月5日に公開されました。現在公開されているUTR#50(Revision 3)は、Eric Mullerさん(アドビ)によるものですが、このカウンター提案は、LaurentiuさんとDwayneさん(両者ともMS)の共同によるものです。

「Updated Proposal to Revise UTR#50 Unicode Properties for Vertical Text Layout」

Unicode コンソーシアムのUTC #130会議で発表されたものを元にして、(1) Unicode全文字についての方向クラス(Orientation_Class)特性値の組を含めたのと、(2) UTR#50のRevision 3への参照を含むように更新されたものです。

UTR#50のrevision 3(2012年2月10日版、以下、UTR#50-20120210)についての説明はこちらを参照してください:縦書きにおける文字の方向について、UTR#50改訂版ドラフトの内容紹介

1.本提案の概要

(1) UTR#50-20120210は日本語を中心に考えているが、縦書きは日本語だけではないので、一般的な言語の縦組みレイアウトを実装するための文字特性とガイドを定義しなければならない。次のようなシナリオにおける縦書きレイアウトのグリフの方向を決めることができるような文字のデフォルトのクラス化を提供したい。

  • モンゴル、’Phags-paのような縦書きの文字、漢字・ハングルなどの縦書き記法のデフォルト・レイアウト
  • アラビア・デバナガリのような横書き文字のグリフを回転して表示して接続特性を維持する縦書きのデフォルト・レイアウト
  • ラテン文字のような横書き文字をサイン看板などのように垂直に積み重ねる方式のレイアウト

(2) Orientation_Class(以下、方向クラス)という列挙型のUnicode文字特性とアルゴリズムを提案する。これにより次の二つの縦書きレイアウトモードにおいて、任意のテキストのグリフの方向を決定することができる。

  • デフォルトモードでは縦書き時における文字の普通の方向を表す。デフォルトでは漢字は正立であり、ラテン文字は右に回転して横倒しになる。CSS3のtext-orientation特性値”upright-right”にあたる。
  • スタックモードでは、普通は横倒しになる文字が垂直の方向になり、垂直方向に積み重なる。例えば、スタックモードでは漢字は垂直のままであり、ラテン文字は垂直に戻る。CSS3のtext-orientation特性値”upright”にあたる。

方向クラス値はすべてのUnicode文字の上記の二つのモードにおける挙動を記述するもので、一以上の方向属性(次の表)の組み合わせにより定義される。

表1.方向属性
属性 名前 説明
S Stackable 縦書きでグリフを正立して表示可能な文字
R Rotatable 縦書きでグリフを横倒しして表示可能な文字
T Transformable OpenTypeのGSUB ’vert’による置き換えのようにフォントの特性をつかってグリフの字形変換がなされる文字
I Inherited 結合文字のように先行するグリフから方向を継承する文字
A Arrow 矢印や類似の文字
B Break 改行特性値を持つ文字

例えば、ラテン文字の方向クラス値はRS(Rotatable とStackable)であり、デフォルトモードでは回転し、スタックモードでは正立する。アラビア文字はRである。

表2.方向クラス値
クラス値 説明 例 
S Stackableのみ 任意の縦書きレイアウトでグリフが正立する分離記述の文字 象形文字、仮名、ハングルなど
RS Rotatable & Stackable の両方 デフォルトモードでは回転し、スタックモードでは正立する。 分離記述文字の大部分、句読点の一部、デバナガリ文字
R Rotatable のみ 結合記述文字のように隣のグリフとの結合を維持するために回転するもの、ベースラインに従う一部の括弧類
TS 字形変換とStackable グリフは正立のままでフォントの特性により字形変換を蒙る分離記述の文字 カタカナ組み文字、こがきのかな
TR 字形変換とRotatable フォントの特性による字形変換を受けた上でグリフは横倒しになる文字 CJKの括弧、全角幅の括弧
IS Inherited とStackable 結合時は基底文字の方向を継承、分離時は正立する結合文字 かなの濁音・半濁音
IRS InheritedでRotatableまたはStackable 結合時は基底文字の方向を継承、分離時はデフォルトモードで回転、スタックモードで正立する結合文字 一般の付加記号(かなの濁音・半濁音を除く)
IR Inheritedで分離時Rotatable 結合時は基底文字の方向を継承、分離時は回転する結合文字 アラビア、シリア、モンゴルなどの付加記号
A Arrows 矢印はAに分類し、上位のプロトコルでASまたはARSになる
AS Stackableのみの矢印 デフォルトモード、スタックモードともに正立する 一般の矢印
ARS RotatableとStackableの矢印 デフォルトモードで回転、スタックモードで正立する矢印 半角幅の矢印
BR 改行 
 
・方向クラス値は優先度の高い方から低い方への順に並んでいる。例えば、TRではTはRより優先し、TができないときRでも良い。

・方向クラス値は拡張可能である。

・方向属性Rは、UTR#50-20120210のEAVOのS(横倒し)とほぼ同じ。方向属性Sは、UTR#50-20120210のU(正立)とほぼ同じである。UTR#50-20120210のSとUは排他的であるが、方向属性RとSは組み合わせできる。

・多くの分離記述の非CJK文字はRSのようにデフォルトでR、スタック時Sの特性が与えられる。

(4)縦組みにおける双方向テキストについて(省略)

(5)アルゴリズム(概略)
1)Aの文字をAS, ARSに決定する
2)BRが先行しないなら先行モードを続ける
3)縦書きのモードがデフォルトモードのときとスタックモードでそれぞれの文字の方向と変形を行なう。

2.Unicodeの各文字についての方向クラス値

提案のPDFに含まれていますが、これをテキストにしたものがこちらにあります。

http://nadita.com/murakami/utr50-ms-table.txt

3.私見:この提案仕様について、ざっと読んでの疑問

1)デフォルトモードとスタックモードの切り替えのタイミングは?日本語の場合、ひとつの文書中で両方使われるので文書全体ではありえない。そうすると、どういうタイミングで切り替えるのか?段落の中でデフォルトモードとスタックモードを切り替えることになると、これを簡単に実現する仕組みが欲しい。(それともCSSのtext-orientationで切り替えるだけなのか?それなら、Unicodeの仕様にする必要はないだろう)。

2)アラビア文字には分離形と結合形があり、文字ではなくて、単語の中の位置でグリフの形を変える。つまりダイナミックに形が変わるが、この文章では文字のグリフ固定を想定しているように見えてしまう。日本語の漢字やかなの筆文字は結合する、つまり、分離形・結合形はフォント依存になるのではないのだろうか?英語だって手書きだと結合するんだけどな~~

上の1)、2)の疑問はもう少し考えないと・・・

第7回ePubPub参加。「見栄えから構造への跳躍」プレゼン

昨日(3月8日)夜、第7回ePubPubが開催されました。第5回から連続3回の参加です。現場のなまなましい話を聞くことができてなかなか楽しい会でした。

会場でのプレゼンの一番人気はインフォシティの岩浪社長の「bReader」を初めとするリーダのデモでした。やはりリーダへの期待が大きいようです。

ところで私も少し時間をいただいて「見栄えから構造への跳躍」という題でプレゼンをしました。

EPUB、XMDF、.book(TTX)という3つの電子書籍の形式はいずれもコンテンツをXHTML/HTMLなどのタグでマークアップするのですが、このマークアップの仕方に関する内容です。

第一のポイントは、「内容を見栄えでマークアップして表している場合、たとえば、見出しをフォントサイズとフォントのボールドで表しているときは、これを、h1のような見出しに変換するのは推定処理になります。推定は誤ることがありますので、チェックに人手がかかり、変換のコストが大きくなります。」ということです。一般的には、見栄えでマークアップした場合は、コンテンツを他の形式に変換するのが難しくなります。

第二のポイントは、「構造をマークアップすると、そのマークアップを使ってコンテンツのトランスフォーメーションを行なうことができます。このトランスフォーメーションできることがマークアップ表現の大きなご利益です。」

トランスフォーメーションについては、あまり一般的には認識されていないようなのですが、この重要性はもう少し強調しても良いのではないかと思います。

プレゼン資料(PDF)

縦書きの数学書における英数字の方向は混沌

縦組みのときに、英数字を正立させるか横倒しにするかということについて、少しづつ調べています。で、英数字が沢山でてきそうな書籍のジャンルのひとつに数学関係があります。数学書の多くは、横組みなのですが、一般向けの数学書には縦組みの本をときどき見かけます。

で、次の3冊の縦組み数学書を調べてみました。

1.「いやでも楽しめる算数」(清水 義範著、講談社刊、2001年8月20日)
2.「江戸の数学教科書」(桜井 進、集英社インターナショナル刊、2009年2月28日)
3.「5分で楽しむ数学50話」(エアハルト・ベーレンツ著、岩波書店、2007年12月12日)

この3冊の本の縦組みのテキストの中で、英数字、特に数式がどのように扱われているかを整理すると次のようになります。

1.数式には文章の行の中に書くインライン数式と、数式だけで一つ以上の行領域を占めるブロック数式に分けることができます。

(1)ブロック数式はすべて数式ブロック全体を右に90°回転しています。従って、英数字も数式の記号もまとめて横倒しです。

(2)インライン数式の多くは数式の範囲を右に90°回転して横倒しで表記されます。長い数式ではすべて横倒しです。


(「5分で楽しむ数学50話」のp.12の一部)

上の図のe、xなどの数式中の1文字の定数や変数はすべて本文テキスト中で正立です。

上図左端行のeのx乗など1項の数式(べき乗)は正立表記です。

この中間の例として、上図の[3]の行f'(x)の横倒しと似たような数式を左端の行f(x)のように縦中横の形式で表記している例が見られます。この場合は、文字数にして4文字で正立、5文字で横倒しという区切りですが、むしろ1行の幅に入るなら正立、入らないなら横倒しとしているのかもしれません。

分数も同じようなことがあり、分母と分子が1桁の分数は分母の数値と分子数値を正立させ、分母と分子の桁数が大きくなるとYYY/XXXの形式で横倒しにしています。

他には長めのインライン数式を文字単位で正立させたり、「2n」を縦中横で表記したかと思うと、同一の本のなかで「πr」を横倒しにしてみたり、インライン数式を正立させるか横倒しにするかの判断は振れていることがわかります。特に2文字のインライン数式の方向性は振れています。

2.ラテンアルファベット

本文テキストの中のラテンアルファベットの方向は、通常の小説などと同じで、頭字語、1文字の大文字は正立です。

3.アラビア数字

アラビア数字は、1桁~2桁、場合によっては3桁までは縦中横正立です。それ以上長い桁数のアラビア数字を文字単位で正立させるか、数値として横倒しするかもかならずしも統一されていません。

次の3つの図は、「いやでも楽しめる算数」、「江戸の数学教科書」の中で数字がどのように表記されているか、例を並べてみたものです。ご覧いただくとおわかりのように、1冊の本のなかで、同じような数値が正立、横倒しの2種類の表記ででていたりします。かなり振れがあるといって良いと思います。


「いやでも楽しめる算数」の中の数値の表記例1


「いやでも楽しめる算数」の中の数値の表記例2


「江戸の数学教科書」の中の数値の表記例

3.方向とグリフ

(1)英数字の字形(グリフ)には半角形(アルファベットはプロポーショナル)と全角形がありますが、上の図で分かるように数式の変数や定数の正立するアルファベット文字は横倒しの数式中の文字と同じグリフになります。

(2)数字のグリフは1冊の本の中では1種類です。

4.補足:数字の扱いについて

(この書籍のことではありませんが)Twitterで教えてもらったことによると、@works014さんは「全角文字コードを正立、半角文字コードを縦中横・横倒しで表して、そのあと見え方として字形を統一する」そうです。なお、別の印刷会社の方に聞いた話では「入稿された原稿の数字を最初に全部半角文字コードに統一してから、正立する文字は回転させる」そうです。つまり、縦書きで数字の制作実務上の取り扱い方には二通りある、ということになります。

CAS-UB Web サービスが今日からV2になります

本日よりCAS-UBのWebサービスのV2を正式サポートになります。

主な機能強化点は次の3項目です。

  • 編集メニューを刷新
  • EPUB3生成を正式サポート
  • PDFレイアウトV2を正式サポート

EPUB3、PDFレイアウトV2は長くα・β状態でしたが、この度正式版にしました。

PDFレイアウトV1機能につきましては、これまでご利用いただいている方向けに、メニューに残っていますが、時期をみてメニューからも削除することになります。PDFのレイアウトはV2の方がはるかに高機能になっていますので、お早めにV2をお試しいただくようにお願いします。

全般に大幅な機能の強化をおこないましたので、従来よりも簡単でかつ高機能になっていると思います。

CAS-UBの機能の詳細は、次のページに利用ガイド(V2版)を公開していますのでご参照ください。
http://www.cas-ub.com/howto/support.html

次のような機能を引き続き開発中です。
・EPUB3関係:全頁SVG、メディアオーバレイ、MathML(このあたりはまだビューアが対応していないこともありゆっくり開発です)
・その他:検索・置換関係、など

3月以降、出版物の型の追加など、多数の機能追加を予定しています。

この機会にぜひCAS-UBのご利用をご検討くださいますよう。よろしくお願いします。