CAS-UBで制作・販売中の下記の本2冊についてGoogle Booksへの登録が完了しました。
１．「はたらくひとのための転職実学」
２．「魔性のプレゼンテーション」
登録したのはいづれもPDF形式の本です。
Google Booksに登録する際には、立ち読みを許可する割合を設定することができます。
CAS-UB本は20%設定としています。
米国ではGoogle独自の決済機能を提供しているようですが、日本ではまだ決済機能は提供されていません。現在のところ、Google Booksで検索した本が気に入った場合は、そこから販売サイトをリンクすることができますので販売サイトで買っていただくことになります。
現在は、2冊の本の販売サイトはDLマーケットにしています。
CAS-UBは本日のメンテナンスでV2サービスにむけて編集機能の刷新を大よそ完了しました。
昨年のサービス開始（V1）のときには、「主原稿」がホームポジションになっていました。
V2メニューでは、従来の「主原稿」に集約していた編集機能を機能別に３つのメニューに分離して、それぞれのメニューをより単純な目的に絞ることで理解しやすくしました。
「記事編集」を導入してホームポジションにしました。また、出版物のアウトラインを編集する「構成編集」を新規追加。従来の「主原稿」はコンテンツを順次表示する機能に限定しました。編集機能は次のようになります。
１．記事編集 出版物を構成する記事のアウトラインを表示し、記事をクリックすると各記事の内容を編集します。コンテンツ編集機能を担当します。
２．構成編集 出版物を構成する記事の階層や並びを編集します。また、出版物の型についての設定を表示したり、目次作成時に、各記事が型の中でどの種類になるかを指定したり、一括で行なうなどのアウトライン編集機能を担当します。
３．主原稿 記事のコンテンツを表示します。
出力機能につきましてはEPUB3出力の機能をベータ版としました。次の変更を行なっています。
・EPUB2互換のNCX出力の有無の設定を追加
・EPUB3対応のCSS3テーマを整理して、「縦中横」、「圏点」などの機能を追加しています。
縦中横や圏点はコンテンツにマークアップしておく必要があります。コンテンツに縦中横や圏点を設定する方法は、来週公開予定の新利用ガイドに記載されます。
またEPUBの出力方法を改善しました。Internet Explorerの一部のバージョンでEPUBをダウンロードできないという問題が報告されましたので、これに対応しました。また、従来よりもファイルサイズが小さくなります。
来週3月1日のメンテナンスでCAS-UBサービスは正式にV2とする予定です。
◎関連ページ：ニュース・リリース
縦書きにおける文字のデフォルト方向を定義するUnicodeの技術レポートUTR#50の新しい草案（Revison 3）が2月10日に公開されています。
Working draft of Proposed Draft Unicode Technical Report #50
UNICODE PROPERTIES FOR VERTICAL TEXT LAYOUT
http://www.unicode.org/reports/tr50/tr50-3.html
まだ作業中のようですが、以下に内容のあらましを紹介します。
Revision 2からの変更点は次のとおりです。
EACは「日本語組版処理の要件」をもとにした空き量の調整ですが、これは、「縦組みにおける英数字成立論」でも疑問を提示しました通り、横組みにも適用されるものですし、そもそも空き量の調整は綺麗な組版のためのものなのでUnicodeのような文字コードレベルで規定するのがふさわしいかどうか疑問があります。取り除いたのは賢明と思います。
Revision 2ではEAOがEACに依存していましたが、この依存性に関する記述はなくなりました。この結果、本文からは全角文字と半角文字に関する記述はなくなりました。
DVOは次のように定義されています:
「文字がほとんど直立する世界における縦書きに使うことを意図している」（5 Properties）
この文章の意味はあまり明確ではありませんが、次の例が挙がっています。
EAOとDVOをどのように組み合わせるか、あるいは、なんらかの規則を設けるかなどは今後の検討課題となります（Editorial Warningsより）。
縦組みのときの方向特性値は従来どおりで変わりません。次のような定義です。
U：文字コード表に現れるのと同じ方向で直立する
S：文字コード表の方向から右に90度回転する
SB：横倒しにする括弧類
T：直立・横倒しではなくて縦組み時に異なるグリフ（字形）にする必要がある
新しいデータファイルが用意されています。
データファイル
基本ラテンの文字コード別にどのような割り当てになっているかを調べて見ます。
文字コード, DVOの値, EAVOの値
0020(‘ ‘), S , S (空白)
0021(!), U , S
0022(“) , U , S
0023(#) , U , S
0024($) , U , S
0025(%) , U , S
0026(&) , U , S
0027(‘) , U , S
0028(‘(‘) , S , S (開き括弧)
0029(‘)’) , S , S (閉じ括弧)
002A(*) , U , S
002B(+) , U , S
002C(,) , U , S
002D(-) , S , S
002E(.) , U , S
002F(/) , U , S
0030…0039(0…9) , U, S
003A(:) , U, S
003B(;) , U, S
003C(<) , U, S
003D(=) , U, S
003E(>) , U, S
003F(?) , U, S
0040(@) , U, S
0041…005A(A…Z) , U, S
005B([) , S , S
005C(\) , U , S (バックスラッシュ）
005D(]) , S , S
005E(^) , U , S
005F(_) , S , S
0060(`) , U , S
0061..007A(a…z) , U , S
007B({) , S , S
007C(|) , U , S
007D(}) , S , S
007E(~) , U , S
EAVOでは基本ラテンの（～U+007Eまでの）文字はすべて横倒しとなりますが、DVOでは縦書きにおいて括弧類など一部の文字（表でSになっている文字）のみを横倒し、ラテンアルファベットとアラビア数字はデフォルトで正立となります。DVOを使うと「縦組みにおける英数字正立論」の主張と同じとなります。
ここで規定する方向特性の値は、あくまでデフォルト値です。英数字はマークアップで明示的に指定して横倒しにすることはできます。
「縦組みにおける英数字正立論」では記号類は未検討でしたので、これから記号類を含めてもう少し精密な検討をして改訂したいと考えています。
○「縦組みにおける英数字正立論」：http://www.cas-ub.com/project/index.html
○UTR#50付属のデータファイルでは、EAVO-A方式とEAVO-B方式の二通りがあります。A方式とはすべての記号類に’U’を割り当てる方式、B方式は矢印、数学記号、罫線記号、括弧に’S’を割り当て、その他の記号を’U’とする方式です。どちらが良いか意見を求めています。
J-Stage新システム（J-Stage3）の開発が大詰めに来ている。次のJ-Stage新システムに関するWebページによると、4月から新システムの稼動予定となっており、その時点で学会誌などの受け入れは新しい方式に切り替わるようだ。
http://info.jstage.jst.go.jp/society/development/index.html
J-Stage3では、学会誌や予稿集の受け入れデータ形式が次の2種類となる。
全文XML化はまだ選択肢のひとつであるが、将来は全文XML化の方向へ進むものと期待されている。全文XML化になればHTMLをはじめとしてさまざまな出力形式に変換できる。例えば、EPUBなどの電子書籍形式に変換してスマートフォンなどの上で読むのも簡単にできる。J-Stage3でこうした可能性が視野に入ってきたといえる。
現在、学術情報誌の制作では、紙による出版に備えて論文PDFをまず制作し、そのデータからXMLを作るというワークフローが主流になっている。しかし、最初から論文を全文XMLでオーサリングすることができれば、XMLデータからPDFを自動生成することができる。もちろん、HTML・EPUBを同時に作ることもできるので、そうなると学術情報誌のビジネスモデルはデジタルデータを先に配信して紙はオプションというデジタルファーストに転換するだろう。こうしてみるとJ-Stage3で学術情報誌の全文XMLによる受け入れはプリントファーストからデジタルファーストへの転換の引き金である。
もっとも、英語圏では学術情報はデジタルファーストどころか、デジタルオンリーになってしまっているようなのでいまさら「引き金」といっても誰も驚かないかもしれない。
上述のシナリオが絵に描いた餅でないことを次に具体的に説明する。
J-Stage3のXMLはJATS0.4形式である。JATS0.4形式はNLM-DTD 3.1に相当するもので、米国のNISOで標準化が進んでいる。
詳しくは：NLM DTDからJournal Article Tag Suiteへの進展：これまでの経過整理
先のJ-Stage3の紹介ページにはサンプルの論文ファイルがある。
【資料3別紙】サンプルファイル(BIB, XML:BIB-J, XML:Full-J)
このサンプル論文ファイルは上記のNISOのページから提供されているXSLスタイルシートでHTMLとPDFに変換することができる。AH Formatterを使ってPDF変換を試してみた。
１．AH Formatterを起動して、①入力ファイルにJ-Stage3で提供しているサンプルXMLを指定し、②スタイルシートに、NISOのページから提供されているスタイルシートを指定する。
２．サンプルのJATS形式論文ファイルは次のように表示される。AH Formatter（スタンドアロン版）はこの画面からPDFを出力できる。
ここで使ったXSLスタイルシートはプレビュー用途として提供されているものなので簡潔なレイアウトになっている。このXSLスタイルシートを見栄えのする論文レイアウト出力に改造する作業は容易である。論文のレイアウトは学会誌によって若干違うので学会誌毎に用意することになる。
論文を最初からJATS形式で編集することができれば、このようにしてPDFを作ることができるので、DTPによるPDF制作は不要となる。但し、JATSをどうやってオーサリングするかという課題が残り、実はここが大きな壁なのである。
いつ、どこがこの壁を破って、プリントファーストからデジタルファーストへの引き金を引くのか、4月以降の動きから目を離せない。
あくまで日本国内の話ですが、2010年を電子書籍元年としますと、今年、2012年は電子書籍3年となります。
2010年を総括しますと、実体が現れないフィーバーの年だったと想います。次の2011年はパピレスやイーブックイニシアティブジャパンの上場など華々しい話題で電子書籍市場が注目されました。そしてEPUB3の仕様が決まって、いよいよEPUB3のツールがいろいろ出てきてEPUB3の電子書籍が市場の主導権をとるかと期待していました。しかし、振り返ってみますと電子書籍販売店の業績は上向いているようですが、どうも電子書籍の形式はと見ますとどうやらXMDFが増えたのではないかという感触です。
2012年は始まったばかりですが、最近はどうもEPUB人気は少ししぼんでしまったように感じます。でも水面下ではEPUBコンテンツの制作も進んでいるようですし、また、最大の懸案事項である「EPUB3のリーダ」については、このほど、IDPFがWebKitベースのEPUBリーダ開発プロジェクト（http://readium.org/）を開始するというアナウンスがありました。プリントからデジタルへの流れは変わることはないと思います。その要は繰り返しですが優れたEPUB3のリーダです。一刻も早く優れたリーダが登場して欲しいものです。
CAS-UBで作成したPDFとEPUBのサンプルなどを紹介しています。
１．有償・無償で頒布の出版物
http://www.cas-ub.com/project/index.html
２．CAS-UB操作説明書
CAS-UBの操作説明書自体もCAS-UBで制作してEPUBとPDFにして公開しています。こちらからダウンロードしていただくことができます。
http://www.cas-ub.com/howto/support.html
※2014/9/13 「利用ガイド」のCAS-UB V2.2用を更新しました。
３．PDFとEPUBのサンプル
3.1 「電子書籍の時代」（サンプルテキスト）
3.2 「船中八策」（坂本 竜馬）
青空文庫より（図書カード：No.4254）
(1) 縦組みEPUBとPDF
(2) 縦組みEPUBとPDF(画像中央配置のページを追加）
解説：「縦書き書籍（EPUB）で画像を左右中央配置するためのCAS-UBの指定方法」
3.3 ランドマーク（Landmarks）を指定したEPUB3
ランドマーク関係は次をご参照ください。
(2014/6/12)
(2014/6/22)
3.4 SVGを直接spineに登録したサンプル
*SVG記事のサンプル：svg-entry-sample.epub
3.5 CAS-SUPPORTブログ記事のEPUB版
CAS-SUPPORTのブログ記事を月毎にWordPressからエクスポートしてCAS-UBでEPUB3にしてみました。ブログの月刊雑誌化！?です。
※WordPressの外部形式ファイル（WRX）インポート機能の利用例として
※2014/9/23リンク切れを訂正
4. CAS-UBによる数式の扱い
次はCAS-UBで数式を編集する方法に関する説明です。本機能は開発中であり、現在、アルファ版の段階です。今後、仕様を変更する可能性があることを予めご了承ください。
.CAS-UB で数式を使う方法について（開発中！暫定版）
5．CAS-UBで生成するPDFの基本版面のサンプル
http://www.cas-ub.com/samples/han-men-size.html
6. EPUB2段組
簡単な2段組のサンプル（EPUB3）
※iBooks（2.1.1）ではページ単位の2段組を正しく表示できません。上の簡単な例はファイルの最後まで2段組とした上で、２つのページに分割します（文字の大きさを変更するとわかります）。ページ単位で2段組にして欲しいところです。
7．CAS-UBのメルマガ変換を使って簡単な操作でメルマガをEPUBに！
・メルマガテキスト（変換前）
・メルマガから変換したEPUB（2014/9/23更新）
※本サンプルは「メルマガ変換」メニューの「メルマガ種別：メルマガT」の設定で変換できます。
8. EPUB Reader 評価用サンプル
2月8日～10日池袋で開催されたPage 2012が終了しました。Page2012は印刷技術協会主催のイベントなので来場者は、印刷会社や制作会社が多く、書籍を作っている著者や出版社は比較的少ないようです。このためか、展示会の会場では電子書籍に関する製品やサービスは比較的少なかったように思います。
そういうなかで、この期間にワークフローについての話をいくつか聞き、印象に残りましたので少しまとめてみたいと思います。
１．スユアe-パブリシング研究会オープンフォーラムでのインプレスR&D 電子出版システム研究所 福浦一広氏の講演は、実際に、PDF、EPUBなどの電子書籍、POD（プリント・オン・デマンド）を採用した出版の新しいビジネスモデル構築に挑戦しているリアルな報告でたいへん触発されました。「最高！」です。以下は、概要です。
(1)OnDeckで行なっていること
・EPUBから自動変換で出版可能なPDFを作る
・記事単位で販売もする
・PODで紙版を販売する（在庫なしでAmazonの倉庫の中で印刷する方式）
(2)OnDeckの本当のイノベーションはデジタルファーストを実践している点であり、電子フォーマットを前提に作っていること。つまり、印刷出版物のデータを再利用していないことである。原稿に関しても、執筆者との間でマルチデバイス展開を合意済みになっていてコンテンツの再利用が可能になっている。
(3)印刷物から作るのではなくて、EPUBをDTPする方が話は簡単になる。記事はXHMLの集合として作り、EPUBにもKindleにもできるし、XHTML単位で再利用ができる。これをPDFにもできる。
(4)デジタルファーストを成功させるには、構造（XHML）とレイアウト（CSS）を完全分離して、XHTMLの中にスタイルを書かないことである。
(5)デジタルファーストは劇薬過ぎて出版社の社内で主張すると仲間はずれになる。しかし、出版業界は冷静に考えるとそうなるだろう。再利用可能な形式でコンテンツを作れば、手間もコストも削減できる。
(6)実はデジタルファーストはツールでしかなくて欠けているのはいいコンテンツなのだ。OnDeckの欠点は専門誌の範囲でしかなくて、まだ、万人には受けないことで、それを未来の出版のあり方とはいえない。デジタルファーストを浸透させるにはヒット作が必要である。
最後の「デジタルファーストを浸透させるにはヒット作が必要」というのはまさしくポイントをついた言葉だと思います。
２．ePubPubでのある出版社の電子書籍実践の話は、DTPから電子書籍を作ることを実践している現場の声で参考になりました。出版社の本作りは、現在、PTPで完成版を作り、そこから電子書籍展開するというワークフローが多いようです。DTPでは、以前は、スタイル機能を使わずにレイアウトをしていたため再利用がとても難しかったのですが、最近はスタイル機能を使うようになってきているので、電子書籍化がしやすくなっているという話でした。実は、プリントファーストでは電子書籍を作るのに苦労するという話と受け止めました。
３．デジタルファーストとは少し違いますが、類似の仕組みで目覚ましいコストダウンを実現した例としては、株式会社エヌ･エヌ・エーのWeb入稿によるニューズレター制作があります。昨年の12月に行なわれた「AH Formatter事例紹介セミナー」に詳しく報告されたものです。
※レジュメのPDFはこちらに公開されています：CSSレイアウトによる日刊情報誌「The Daily NNA」18 紙の制作
この仕組みを少し変えると直ちにデジタルファーストの仕組みを実現できます。
キーワードとしてコンテンツをXML特に「XHTML」で制作し、レイアウトをCSSで指定していることがあります。
現在、書籍の出版ではプリントを先に作って、これを頒布する方法で行なわれています。これを仮にプリントファーストと呼ぶと、図示してみると分かるとおり、プリントファーストとデジタルファーストは真っ向から対立する方法です。
プリントファーストでは、DTPによる「印刷用の版」を最初に作るのに対して、デジタルファーストのスタートラインは、「XHTML＋CSS」となります。このXHTMLをどのように効率的に作るか成功の鍵です。以上は、制作ツールのレベルの話です。
さらに、デジタルファーストは出版販売までを統合した仕組みとして実現されることになります。そして、これが普及するための最重要要素は電子出版のための販売チャネルです。しかし日本ではこれが欠落しているためにまだ本格展開ができないという状態と思います。
1月11日以来随時ブログで紹介してきましたUTR#50関係の話を「縦組みにおける英数字正立論」として整理しました。
「縦組みにおける英数字正立論１～１８」としてストーリー化しましたが、これをCAS-UBでPDFとEPUBにしたバージョンもあります。
こちらからダウンロードしていただくことができます。
http://www.cas-ub.com/project/verticalwriting.epub
http://www.cas-ub.com/project/verticalwriting.pdf
「英数字正立論」を思いついたのはUTR#50（ドラフト）を読んで「これではだめだ。」と感じたからなのです。では、なぜ、そう感じたかと言いますとCAS-UBを開発する過程で、全角文字と半角文字を使い分けて縦組みのときの正立・横倒しを区別するという現状のやり方にいろいろと壁を感じていて解決策を模索していたことが背景にあります。UTR#50（ドラフト）は、解決どころかさらに壁を厚くしてしまうものと見えてしまったのです。
「英数字正立」をデフォルトにすべきという話を、W3CのCSSメーリング・リストに投稿したところ、ある日本人エディターから「日本でそんなことをいう人は他にはいない」と宣告されました。
CAS-UBは、コンテンツを出版形式とは完全に切り離したかたちで制作して、PDFもEPUBも自在に生成します。さらには、横組み・縦組みも自在に切り替えできます。おそらく、このようなことのできる出版コンテンツ制作サービスは世界に唯一と思います。
従って、CAS-UBの開発過程で生まれたアイデアが、「日本でそんなことをいう人は他にいない」と批評されるのは自然です。言ってみれば、独創性についてのお墨付きのようなものです:-)
「英数字正立」で問題点が解決できるかどうかは、もう少し検討を要するとは思いますが、どうやら、縦組みでは英数字を横に寝かせるのをデフォルトとするよりも、正立をデフォルトにするほうが、問題をスムースに解決できそうに感じています。
１．Unicodeで縦組みの文字の向きの標準を決める新しい仕様案 UTR#50 （http://unicode.org/reports/tr50/）
２．パブリックコメント：http://unicode.org/forum/viewforum.php?f=35
３．日本語での議論は「EPUB仕様についての情報・意見交換」でもhttp://groups.google.com/group/epub-spec-discussions
４．Twitter ハッシュタグは #UTR50
５．参考ブログ記事
５－１ CSSの縦組みとUnicodeの縦組みの文字の向き（UTR#50）の話題（CSS組版ブログ）http://blog.antenna.co.jp/CSSPage/2012/02/cssunicodeutr50.html
６．「PDFインフラストラクチャ解説」http://www.cas-ub.com/project/index.html
英数字正立論はまだラフなアイデアのレベルです。これを精緻なものにするには検討すべきことがあります。
さしあたっては次のような批判が考えられます。
プレーン・テキストへの適用
【批判】プレーン・テキストのレベルではマークアップが使えない。すべて正立してしまうと困ることがあるだろう。
【対応】全角文字を使うというのは、XHTMLでは文字単位のマークアップにほぼ同じです。全角文字を廃止してしまうと、プレーン・テキストの段階では横倒しする文字と正立する文字を区別する方法がなくなり、結果として英語の文章などを横倒しさせることもできなくなります。従って、プレーン・テキストの中で横倒ししたい範囲を示したいときは、Unicodeに制御用コードを導入するなどの方式をとること必要があるでしょう。これと類似の方法はラテン文字とアラビア文字が混在したときの方向を制御するために、Unicodeでは古くから採用されており、特に新しい方法ではありません（Unicode Bidirectional Algorithm（UAX#9））。
正立させるに向かない文字列
【批判】アラビア数字で表した小数点がある数値、桁区切りのある数値はどうするか。
【対応】確かに、これを文字単位で正立させてしまうとおかしな表示になります。従って、このような数字は、text-orientationを指定して横倒しにするのが良いと思います。一方で、逆に縦組み用に全角文字で表した小数点のある数値や桁区切りのある数値を横組みにするとおかしな表示になります。つまり全角文字をつかっても縦横切り替えの問題は解消できません。このように数値については縦組みと横組みの互換をとるために何らかの新しい記法変換を考案する必要があります。
互換性
【批判】過去のデータ資産をどうするつもりか？
【対応】確かに、英数字正立論の最大の問題は過去との互換性となります。指摘の通り、過去のデータをどうするかということは大きな問題です。英数字の半角文字と全角文字の使い分けをやめて正規化文字に統一するのは相当な決断が必要になりますので、さらに慎重な検討が必要です。しかし、Webや電子書籍における縦組みはまだ始まったばかりなので、新しい方式を導入するのはいまの時点しかないことも確かです。