作家の藤井大洋さんのSF作品「Gene Mapper」はDRMなしで各種電子書籍フォーマットを用意して販売されている、電子書籍について関心のあるSF者には見逃せない作品だ。
作品は、サイバーパンク的要素の強いハイスピード展開、テクノロジー満載の楽しい内容なのだが、いまサイバーパンクと書いた理由は、みっしりと振られたルビ。もはや古典の「ニューロマンサー」を彷彿とさせるものだったから。また、藤井氏はルビや圏点を意欲的に使い、英語の横倒しセンテンスに漢字かな交じりの日本語ルビ、日本語に英語横倒しルビ、まだ読んでいないがベトナム語に日本語ルビの箇所もあるらしい。当然英数字も増えるので、縦組みの場合は縦中横も頻発することになる。
で、Kobo TouchがWebKitに手を加えたNetFrontでうまく表示するのはともかくとして、さきほど藤井氏のブログエントリで、「Kindle Preview」という著者が実機でどう見えるかをPC上で確認するためのソフトウェアがKindle Touchの縦組み表示に対応していることを知り、Koboブックストアで購入した「Gene Mapper」のKEPUBを読み込ませてみた。
CaribreでMOBIにしなければ読めないかと思ったのだけれども、最初の画面でEPUBも読むと書いてあったので、DRM Freeな氏の作品をそのまま読み込ませたという経緯。
するとやはりMOBIに自動変換するようで、詳細画面を開くと、日本語で「コンパイラ」のバナーが出た後、変換処理の進行状況が現れ、いろいろと警告やエラーメッセージを出しながらもMOBIに変換し、完了したという表示が出た。すると、いままでグレーアウトされていた[OK]ボタンが押せるようになり、目次のページが開いたのだが、とにかく素晴らしい品質の縦組みをする。
本文に入れば、行末の揃えはもちろん禁則や追い込み、ぶら下げなど日本語組版のややこしいところをきちんとクリアしている。もちろん三点ダッシュや連続するダーシもきちんとつながっている（ChromiumやSafariでは、文字の間が少し空いてしまう）。本作品の特徴である大量のルビも、普通に印刷物で読むような、うまい配置をする。ルビの配置についてはもしかすると作家がCSSをうまく書いているためなのかもしれないけれども。
とにかく、この品質であれば、Kindle日本語版には十分期待していいと思う。実機の販売が楽しみだ。
なお、役物が連続するところでの空白はKobo Touchと同じだった。もしかするとKindleもWebKitを使っているのかもしれない。
2012年8月15日水曜日
2012年8月13日月曜日
KEPUBとはなにか（Kobo EPUB）
給料日までに少し財布に余裕があるような気がしたので、Koboブックストアで日本語書籍を購入してみた。それまでは、カナダのサイトで購入した英語の本とか、O'ReillyのDRM FreeのEPUBを入れていたので、日本語書籍は初めてだ。
それでようやく気づいたのだが、Kobo Touchの日本語書籍はACCESSのWebKitを使わなければならないから、従来のnickel（Kobo Touch内部のLinux上で動く読書アプリ）のレンダリングエンジンではなく、NetFront BookReader EPUB Editionを選択しなければ、日本語組版として破綻することになる（はず）。
Kobo Touchは、村上真雄氏のエントリにあるように、ファイルの拡張子で従来のEPUBのレンダリングエンジンとEPUB3対応レンダリングエンジンを切り替える。拡張子が単なる「.epub」なら前者、「.kepub.epub」なら後者ということだ。
KEPUB（Kobo EPUB）は、Koboのブックリーダーに合わせて作られたEPUBというような意味合いになるようだ。つまり、IDPFの規格からは逸脱していないが、他のブックリーダーでの表示は知らないよ、ということになる。
KEPUBについて、MobileReadのWikiの記述は必ずしも正確に記述されていないようだが、KoboブックリーダーとPC側アプリの関係についての記述はとりあえず現状に即している。詳しくは書かれていないが、ここで問題になるのはKDRMという独自のDRMだ。Wikiの記述どおり、PC側アプリやWiFi直接で入手する書籍は、KEPUBのみとなる。そして、KEPUBは3つのDRM方針、つまりDRM Free、Adobe DRM、KDRMの3つで配布されている。具体的にはDRM Freeは、藤井大洋氏の「Gene Mapper」。Adobe DRMは日本語書籍ではまだ確認されていないが、MobileReadのフォーラムには存在するようなコメントがある。そして、伊藤計劃の「虐殺器官」「ハーモニー」はKDRMだった。KDRMは、.kepub.epubをunzipして得られるトップディレクトリのrights.xmlで用いられている要素名なので、便宜的にそう呼ぶことにしている。
KDRMは、他のプラットフォームでは開くことができない。Adobe DRMと同様、ファイル名はそのままで、本文に関わるすべてのファイルが暗号化されており、unzipしても一切内容を見ることはできない。Adobe DRMならばそれに対応した他のリーダーでも開くことができるが、KDRMではそれができない。オープンプラットフォームと考えていたが、版元など権利者の要望及び営業の都合（Kobo独占発売や特価など）で囲い込む仕組みは用意されていたということになる。
カナダのサイトに接続すれば、「My Library」以下はAdobe DRMのダウンロードリンクがついた状態で表示される。しかし、日本語書籍は一切現れなかった。一方、日本向けKoboブックストアの「マイライブラリ」は書誌情報を出すのみ。たしかに日本語書籍はKEPUBで提供しているのだから、Webブラウザから個別に配信を受ける筋合いのものではないだろう。従来のKobo社の方針と齟齬はない。とはいえ、何か腑に落ちないものは残る。
ついでなので、SONY Readerについて誤解していたことをここに告白する。SONY ReaderはAdobe DRMのEPUBのみを扱っているものとばかり思っていた。しかし、日本の製品であれば、また、EPUB3の規格が定まる以前から販売していたのだから、当然日本独自の縦組み可能なフォーマットで本は配信されていたことに気づいていなければならなかった。具体的には、XDMFと.bookだ。日本のReaderストアで扱われている日本語書籍は多くがこのどちらかだろう。紀伊國屋書店のKinoppy以後、EPUB3の書籍もあるかもしれないが、KinoppyもXDMFと.bookに対応しているので何の保証もない。
XDMFと.bookは形式こそXMLに準じているが、シャープもボイジャーも古くから日本語の縦組み読書環境を提供してきた経緯があり、文字コードはシフトJISなのだそうだ。JIS X 0213:2004に対応したShift_JIS-2004というものがあるそうだが、入力システム(IME）が対応しているかどうかは知らない。いずれにせよ、JIS X 0213止まりではまだ多くの文字が「外字」として、XML文書のなかでは「画像」として組み込まれることになる。EPUB3においても、Unicode対応について明確な定めはないようだし、あれば逆に制約になるので、現状はJIS X 0213:2004を逸脱しない範囲のUTF-8ファイルをマークアップすることになるのだろう。実際、楽天Koboをセットアップして最初に入る青空文庫の「吾輩は猫である」には、OEBPS/Image/gaijiというフォルダがあり、ページごとに使われている「外字」がPNG形式で入っている（なぜかKDRMがかかっているので開けないのだが）。
こうした「外字」問題に対しては、特に多くの役物や各種異体字に関しては、2006年のUnicode 5.0でIVS（異体字辞書システム）が導入され、2012年現在Adobe Japan 1-6に対応したグリフを持つフォントならば公式にIVD（異体字辞書）に登録されている文字の多くが、さらに汎用電子コレクションを含めば、現時点で日本語でUnicode 6.1のコードポイントが割り当てられている文字はすべて表示できる。具体的には、IPAmjフォント（明朝のみ）には汎用電子コレクションが含まれ、Adobeの最新のヒラギノはAdobe Japan 1-6対応ということになるだろう。明治の活版印刷に由来し人気の高い秀英体は、2008年の「平成の大改刻」のAdobe Japan 1-5対応版をモリサワが販売しているのが現在最新の状況のようだ。IVSは拡張性のある規格なので、状況次第で今後グリフが追加されることはありえる。ただ、従来の印刷書籍でも作字して、全く独自の文字を版面に加えるということはあったので、そのような場合には画像、特にSVGやWebフォントのようなベクター形式の図形を用いることにはなるだろう。しかし、シフトJISという制約がない分、UTF-8を使うEPUBのほうがXDMFや.bookに比べ「外字」となる文字数は少なくなるはずで、EPUBが望ましいのだが、現在日本語書籍をEPUB3のみで提供しているのは楽天Koboのみ、しかしKDRMで囲い込まれているというのはどうにも釈然としない。
話がそれたついでに、EPUBと外字問題に関しては、先月のセミナーの動画をご覧いただくとよくわかると思う。
それでようやく気づいたのだが、Kobo Touchの日本語書籍はACCESSのWebKitを使わなければならないから、従来のnickel（Kobo Touch内部のLinux上で動く読書アプリ）のレンダリングエンジンではなく、NetFront BookReader EPUB Editionを選択しなければ、日本語組版として破綻することになる（はず）。
Kobo Touchは、村上真雄氏のエントリにあるように、ファイルの拡張子で従来のEPUBのレンダリングエンジンとEPUB3対応レンダリングエンジンを切り替える。拡張子が単なる「.epub」なら前者、「.kepub.epub」なら後者ということだ。
KEPUB（Kobo EPUB）は、Koboのブックリーダーに合わせて作られたEPUBというような意味合いになるようだ。つまり、IDPFの規格からは逸脱していないが、他のブックリーダーでの表示は知らないよ、ということになる。
KEPUBについて、MobileReadのWikiの記述は必ずしも正確に記述されていないようだが、KoboブックリーダーとPC側アプリの関係についての記述はとりあえず現状に即している。詳しくは書かれていないが、ここで問題になるのはKDRMという独自のDRMだ。Wikiの記述どおり、PC側アプリやWiFi直接で入手する書籍は、KEPUBのみとなる。そして、KEPUBは3つのDRM方針、つまりDRM Free、Adobe DRM、KDRMの3つで配布されている。具体的にはDRM Freeは、藤井大洋氏の「Gene Mapper」。Adobe DRMは日本語書籍ではまだ確認されていないが、MobileReadのフォーラムには存在するようなコメントがある。そして、伊藤計劃の「虐殺器官」「ハーモニー」はKDRMだった。KDRMは、.kepub.epubをunzipして得られるトップディレクトリのrights.xmlで用いられている要素名なので、便宜的にそう呼ぶことにしている。
KDRMは、他のプラットフォームでは開くことができない。Adobe DRMと同様、ファイル名はそのままで、本文に関わるすべてのファイルが暗号化されており、unzipしても一切内容を見ることはできない。Adobe DRMならばそれに対応した他のリーダーでも開くことができるが、KDRMではそれができない。オープンプラットフォームと考えていたが、版元など権利者の要望及び営業の都合（Kobo独占発売や特価など）で囲い込む仕組みは用意されていたということになる。
カナダのサイトに接続すれば、「My Library」以下はAdobe DRMのダウンロードリンクがついた状態で表示される。しかし、日本語書籍は一切現れなかった。一方、日本向けKoboブックストアの「マイライブラリ」は書誌情報を出すのみ。たしかに日本語書籍はKEPUBで提供しているのだから、Webブラウザから個別に配信を受ける筋合いのものではないだろう。従来のKobo社の方針と齟齬はない。とはいえ、何か腑に落ちないものは残る。
ついでなので、SONY Readerについて誤解していたことをここに告白する。SONY ReaderはAdobe DRMのEPUBのみを扱っているものとばかり思っていた。しかし、日本の製品であれば、また、EPUB3の規格が定まる以前から販売していたのだから、当然日本独自の縦組み可能なフォーマットで本は配信されていたことに気づいていなければならなかった。具体的には、XDMFと.bookだ。日本のReaderストアで扱われている日本語書籍は多くがこのどちらかだろう。紀伊國屋書店のKinoppy以後、EPUB3の書籍もあるかもしれないが、KinoppyもXDMFと.bookに対応しているので何の保証もない。
XDMFと.bookは形式こそXMLに準じているが、シャープもボイジャーも古くから日本語の縦組み読書環境を提供してきた経緯があり、文字コードはシフトJISなのだそうだ。JIS X 0213:2004に対応したShift_JIS-2004というものがあるそうだが、入力システム(IME）が対応しているかどうかは知らない。いずれにせよ、JIS X 0213止まりではまだ多くの文字が「外字」として、XML文書のなかでは「画像」として組み込まれることになる。EPUB3においても、Unicode対応について明確な定めはないようだし、あれば逆に制約になるので、現状はJIS X 0213:2004を逸脱しない範囲のUTF-8ファイルをマークアップすることになるのだろう。実際、楽天Koboをセットアップして最初に入る青空文庫の「吾輩は猫である」には、OEBPS/Image/gaijiというフォルダがあり、ページごとに使われている「外字」がPNG形式で入っている（なぜかKDRMがかかっているので開けないのだが）。
こうした「外字」問題に対しては、特に多くの役物や各種異体字に関しては、2006年のUnicode 5.0でIVS（異体字辞書システム）が導入され、2012年現在Adobe Japan 1-6に対応したグリフを持つフォントならば公式にIVD（異体字辞書）に登録されている文字の多くが、さらに汎用電子コレクションを含めば、現時点で日本語でUnicode 6.1のコードポイントが割り当てられている文字はすべて表示できる。具体的には、IPAmjフォント（明朝のみ）には汎用電子コレクションが含まれ、Adobeの最新のヒラギノはAdobe Japan 1-6対応ということになるだろう。明治の活版印刷に由来し人気の高い秀英体は、2008年の「平成の大改刻」のAdobe Japan 1-5対応版をモリサワが販売しているのが現在最新の状況のようだ。IVSは拡張性のある規格なので、状況次第で今後グリフが追加されることはありえる。ただ、従来の印刷書籍でも作字して、全く独自の文字を版面に加えるということはあったので、そのような場合には画像、特にSVGやWebフォントのようなベクター形式の図形を用いることにはなるだろう。しかし、シフトJISという制約がない分、UTF-8を使うEPUBのほうがXDMFや.bookに比べ「外字」となる文字数は少なくなるはずで、EPUBが望ましいのだが、現在日本語書籍をEPUB3のみで提供しているのは楽天Koboのみ、しかしKDRMで囲い込まれているというのはどうにも釈然としない。
話がそれたついでに、EPUBと外字問題に関しては、先月のセミナーの動画をご覧いただくとよくわかると思う。
2012年8月7日火曜日
Kobo Touchにはオープンソースが似合う
前のエントリに追記を書いていて、別エントリにすべきと思ったのであらためて。
まず、日本語EPUB対応はNetFront BookReader v1.0 EPUB Editionであるということ。これに関しては、下川さんのEPUBに寄せる強い思いもあるだろうし、出版社の要望に沿うためにも日本特有のきめこまやかな（というか、芸術的職人芸に基づく）組版を実現させる必要があって、代わるものがなかったということなのだろうと思う。むしろ、WebKitの現状を考えるに、それを調整する、つまりオープンソースコミュニティに関わっていく時間が、ビジネスの側面から考えると待てなかった側面はやむを得ないのだろう。SONY ReaderはAdobe Reader Mobileを採用しているということなので、競争上、プロプライエタリで、これを超えるものがあるなら搭載することは当然のことなのだろうと思う。
また、様々な使い勝手について、日本の消費者は完璧なものを望むので、もとのKobo Touchに対してソフトウェア的に対応できるものは何でもやっていかなければ今回以上に炎上したであろうことは想像できないことはない。
特に、画面上の操作が赤外線センサであることについて販売員が知らず、スリープ状態ですぐ電池がなくなることに疑問を持ったまま店頭に立っているというのは（いや、きょう某店頭で偶然販売員と会話して知っただけで、全国的にどうなのかは知らない）どうなのかと思ったりした。Appleやソニーのように直売店があるわけではないので、商品のなかみに詳しい必要はないのだろうが、これだけ炎上した以上、苦情の分析に専任を当てて得意のスピード経営で販売員への対応マニュアルを随時更新するとか楽天はしたほうがいいんじゃないかと懸念してみたり。ちなみに、「電源オフ」にすれば赤外線センサを見なくなるのでかばんに入れても電池は減りませんが、スリープ状態では画面上に障害物があるとLEDが点灯するのでぐんぐん電池が減ります。って書いてみたら、デフォルト設定が悪いんじゃないかという気がしてきたぞ。
デスクトップアプリにしても、おそらく出版社の要望にきめ細かく応えた日本語EPUB3の美しい組版を実現するには現状のWebKitはまだ実装が及ばないところがあるので、しばらくは出ないだろうし、出てもおそらくNetFrontのコードを持ち込むことになるだろうから、プロプライエタリなコードがまた増えることになるんだと思う。
そう考えると、Kindle日本語版の「出る出る詐欺」も、組版エンジンの実装とMOBIなりAZWなりのフォーマット改訂に手間がかかっているせいではないかという気がしてきた。その意味では、楽天は率先して前線に出て十字砲火を受けたわけで、あっぱれというほかないと思う。内部筋の情報では三木谷はかなりへこんでいるらしいが、お前が出ずに誰がこんな危険なギャンブル、もとい偉大なる勇み足ができるか、よく考えて、もっとましな開き直り会見したほうがいいのではないか。まぁ、ほとぼりが冷めた頃にAmazonが楽天の失敗の上に満を持して登場とかありうるわけだけれどもそこはそれ、先行者利益ということで（ほんまかいな）。
しかし、そうして重厚な品質の上に成り立つのはAppleしかり、大事なところはほとんど外から触れない製品にならざるを得ないわけで、もともとあったKoboのカジュアルなところとは対局になってしまうことを懸念せざるを得ない。例えばKobo書店サイトについて苦情を言う日本人は、従来のサイトを知らないから言えるのであって、あんなに買いにくいサイトはなかった。安いのは若者向けの恋愛小説とかホラーとかの軽いやつばかりで、欲しい本は検索に偶然引っかかっても他の書店のほうが安かったりと、売る気があるのかどうか、あんまり考えてなさそうなところが逆に好感を持ってしまったりするような作りだったのだが。
やはりここは、すでに出ているソースコードをもとに、オープンソースコミュニティのファームウェアをがんばらざるを得ないのではないか。すでに基本はできているので、nickelに相当する部分はWebKitの最新版にしっかり追随する形、もしQtの更新が遅ければOpenFrameworkに置き換えていくぐらいの勢いがあってもいいのではと思った。若者がんばれ。おじさんはもうだめだから。
まず、日本語EPUB対応はNetFront BookReader v1.0 EPUB Editionであるということ。これに関しては、下川さんのEPUBに寄せる強い思いもあるだろうし、出版社の要望に沿うためにも日本特有のきめこまやかな（というか、芸術的職人芸に基づく）組版を実現させる必要があって、代わるものがなかったということなのだろうと思う。むしろ、WebKitの現状を考えるに、それを調整する、つまりオープンソースコミュニティに関わっていく時間が、ビジネスの側面から考えると待てなかった側面はやむを得ないのだろう。SONY ReaderはAdobe Reader Mobileを採用しているということなので、競争上、プロプライエタリで、これを超えるものがあるなら搭載することは当然のことなのだろうと思う。
また、様々な使い勝手について、日本の消費者は完璧なものを望むので、もとのKobo Touchに対してソフトウェア的に対応できるものは何でもやっていかなければ今回以上に炎上したであろうことは想像できないことはない。
特に、画面上の操作が赤外線センサであることについて販売員が知らず、スリープ状態ですぐ電池がなくなることに疑問を持ったまま店頭に立っているというのは（いや、きょう某店頭で偶然販売員と会話して知っただけで、全国的にどうなのかは知らない）どうなのかと思ったりした。Appleやソニーのように直売店があるわけではないので、商品のなかみに詳しい必要はないのだろうが、これだけ炎上した以上、苦情の分析に専任を当てて得意のスピード経営で販売員への対応マニュアルを随時更新するとか楽天はしたほうがいいんじゃないかと懸念してみたり。ちなみに、「電源オフ」にすれば赤外線センサを見なくなるのでかばんに入れても電池は減りませんが、スリープ状態では画面上に障害物があるとLEDが点灯するのでぐんぐん電池が減ります。って書いてみたら、デフォルト設定が悪いんじゃないかという気がしてきたぞ。
デスクトップアプリにしても、おそらく出版社の要望にきめ細かく応えた日本語EPUB3の美しい組版を実現するには現状のWebKitはまだ実装が及ばないところがあるので、しばらくは出ないだろうし、出てもおそらくNetFrontのコードを持ち込むことになるだろうから、プロプライエタリなコードがまた増えることになるんだと思う。
そう考えると、Kindle日本語版の「出る出る詐欺」も、組版エンジンの実装とMOBIなりAZWなりのフォーマット改訂に手間がかかっているせいではないかという気がしてきた。その意味では、楽天は率先して前線に出て十字砲火を受けたわけで、あっぱれというほかないと思う。内部筋の情報では三木谷はかなりへこんでいるらしいが、お前が出ずに誰がこんな危険なギャンブル、もとい偉大なる勇み足ができるか、よく考えて、もっとましな開き直り会見したほうがいいのではないか。まぁ、ほとぼりが冷めた頃にAmazonが楽天の失敗の上に満を持して登場とかありうるわけだけれどもそこはそれ、先行者利益ということで（ほんまかいな）。
しかし、そうして重厚な品質の上に成り立つのはAppleしかり、大事なところはほとんど外から触れない製品にならざるを得ないわけで、もともとあったKoboのカジュアルなところとは対局になってしまうことを懸念せざるを得ない。例えばKobo書店サイトについて苦情を言う日本人は、従来のサイトを知らないから言えるのであって、あんなに買いにくいサイトはなかった。安いのは若者向けの恋愛小説とかホラーとかの軽いやつばかりで、欲しい本は検索に偶然引っかかっても他の書店のほうが安かったりと、売る気があるのかどうか、あんまり考えてなさそうなところが逆に好感を持ってしまったりするような作りだったのだが。
やはりここは、すでに出ているソースコードをもとに、オープンソースコミュニティのファームウェアをがんばらざるを得ないのではないか。すでに基本はできているので、nickelに相当する部分はWebKitの最新版にしっかり追随する形、もしQtの更新が遅ければOpenFrameworkに置き換えていくぐらいの勢いがあってもいいのではと思った。若者がんばれ。おじさんはもうだめだから。
2012年8月2日木曜日
Kobo Touchをhackする日本人たちに敬意
2ch有志カスタムファームウェアがあるというので、いろいろ探してみたら、Kobo Touch のソースツリー（及びパッチ）が出ているのね。
Linuxについては詳しくないので、daemon関係については正直さっぱりなのですが、アプリケーションがQt Embeddedというのもびっくり。電子書籍端末なのでなんかWebKitを使うプログラムが動いているんだろうと思ったら、Qtに含まれるWebKitを使っているというわけですね。ということは、日本語対応はQtを新しくするだけでそれなりに、ということですか。アプリ名はどうやらnickelらしい。
（2012年8月7日追記：日本語EPUBは、イースト社のNetFront BookReader v1.0 EPUB Editionを使っていると、ろす氏のブログに書かれておりまして、氏の立ち位置からして間違いない情報と思いますので訂正いたします。ちなみにNetFrontはACCESSがガラケーや組み込み向けに出してきた、別の意味で歴史のあるWebブラウザですな。イーストは電子書籍業界の有名人、下川さんの会社ですから、かなりEPUB3に思い入れの入った作りであろうかとは想像できます。それから、某有料メルマガ方面から、コストの問題で搭載すべきソフトウェアコンポーネントが別のものになっているという話がきこえてきて、それがもとからあったものなのか、楽天の要望を解決するために購入すべきものが代替物になったのか、そのへんは不明です。ただ、楽天なり日本の消費者の要望で、カラッとオープンだったKoboが囲い込まれた商品になっていくならそれは残念なことだと思います。）
（2012年8月13日追記：NetFront Book Reader v1.0 EPUB EditionのレンダリングエンジンはWebKitだということが、村上真雄氏のブログに書かれていた。氏はEPUB3の縦組みに必須のCSS3 Writing-Modeの規格に深く関わっていた方。他にも、いかにもWebKit的な特徴的なレンダリングが観察されるという言及は複数あり、ACCESSまったくオリジナルのレンダリングエンジンというわけではないようだ。この記事によれば、ACCESSはIDPFメンバーとして、WebKitベースのEPUB3組版リファレンス実装Readiumにコードを貢献し、それが反映されたものがMac OS X用カスタムバイナリとして現在提供されているようだ。つまり、一般的なChomeやChromiumブラウザにChrome Web StoreのReadiumを追加しただけでは、少なくとも日本語組版については不完全だということなのだろう。）
EInkディスプレイのドライバソースも出ているし、指の検知は縦横にずらりと並んだ赤外線LEDとフォトトランジスタだけなので、そりゃNetBSDの移植も即座に出てくるわなぁ、と思った次第。@h_kenkenさんがんばれ。ああ、なんと動機はMikutterの組み込みですか...なるほど。
と、どうやらTogetterに着々と解析結果が集積されているようで、僕がぐだぐだ書く必要性が感じられなくなってきたので、以下リンクのみ。
https://github.com/kobolabs/Kobo-Reader2年前の最終更新だけれども、製品が出た当時のことを考えれば、まぁカーネルを置き換えるようなことは特にしていないのかもしれないなどと思いつつ。それにしても、Linuxで動いているからにはGPLに従ってソースを出さなければならないわけで、GPL強力と驚きました。いやまじで。
Linuxについては詳しくないので、daemon関係については正直さっぱりなのですが、アプリケーションがQt Embeddedというのもびっくり。電子書籍端末なのでなんかWebKitを使うプログラムが動いているんだろうと思ったら、Qtに含まれるWebKitを使っているというわけですね。ということは、日本語対応はQtを新しくするだけでそれなりに、ということですか。アプリ名はどうやらnickelらしい。
（2012年8月7日追記：日本語EPUBは、イースト社のNetFront BookReader v1.0 EPUB Editionを使っていると、ろす氏のブログに書かれておりまして、氏の立ち位置からして間違いない情報と思いますので訂正いたします。ちなみにNetFrontはACCESSがガラケーや組み込み向けに出してきた、別の意味で歴史のあるWebブラウザですな。イーストは電子書籍業界の有名人、下川さんの会社ですから、かなりEPUB3に思い入れの入った作りであろうかとは想像できます。それから、某有料メルマガ方面から、コストの問題で搭載すべきソフトウェアコンポーネントが別のものになっているという話がきこえてきて、それがもとからあったものなのか、楽天の要望を解決するために購入すべきものが代替物になったのか、そのへんは不明です。ただ、楽天なり日本の消費者の要望で、カラッとオープンだったKoboが囲い込まれた商品になっていくならそれは残念なことだと思います。）
（2012年8月13日追記：NetFront Book Reader v1.0 EPUB EditionのレンダリングエンジンはWebKitだということが、村上真雄氏のブログに書かれていた。氏はEPUB3の縦組みに必須のCSS3 Writing-Modeの規格に深く関わっていた方。他にも、いかにもWebKit的な特徴的なレンダリングが観察されるという言及は複数あり、ACCESSまったくオリジナルのレンダリングエンジンというわけではないようだ。この記事によれば、ACCESSはIDPFメンバーとして、WebKitベースのEPUB3組版リファレンス実装Readiumにコードを貢献し、それが反映されたものがMac OS X用カスタムバイナリとして現在提供されているようだ。つまり、一般的なChomeやChromiumブラウザにChrome Web StoreのReadiumを追加しただけでは、少なくとも日本語組版については不完全だということなのだろう。）
EInkディスプレイのドライバソースも出ているし、指の検知は縦横にずらりと並んだ赤外線LEDとフォトトランジスタだけなので、そりゃNetBSDの移植も即座に出てくるわなぁ、と思った次第。@h_kenkenさんがんばれ。ああ、なんと動機はMikutterの組み込みですか...なるほど。
と、どうやらTogetterに着々と解析結果が集積されているようで、僕がぐだぐだ書く必要性が感じられなくなってきたので、以下リンクのみ。
登録:
投稿 (Atom)