http://kobo.rakuten.co.jp/
■専用wiki
http://www49.atwiki.jp/kobotouch/
※前スレ
Kobo Touch/Glo/Mini hacking スレ Part.4
http://uni.2ch.net/test/read.cgi/ebooks/1360673958/
ttp://wiki.mobileread.com/wiki/Kobo_Touch_Hacking
海外情報源
ttp://www.mobileread.com/forums/forumdisplay.php?f=223
Kobo Touchで英和辞書
ttp://petit-noise.net/blog/20120808/kobo-touch%E3%81%A7%E8%8B%B1%E5%92%8C%E8%BE%9E%E6%9B%B8
Kobo用高速化Jpegライブラリ
ttp://ux.getuploader.com/KOBO/download/1/Kobo_libjpeg-turbo_updater_20120824.zip
Kobo Touch専用ホームボタンにページ送りを割り当てるデーモン（常駐アプリ）
http://ux.getuploader.com/kobo/download/5/kobo_fwbtd_20120912.zip
※注意
全て自己責任でおながいします
http://ux.getuploader.com/KOBO_HACK/download/68/Kobo_CFW_Ver0.95.zip
■主な機能
１ 不具合修正
① 外部SDカードに保存されたファイルの名前に２バイト文字が使用されている場合
Kobo本体に差し込むとKobo上で文字化けが発生してしまう
② 内蔵ストレージに置いたファイル名、フォルダ名に特定の文字が含まれていると
”FSCKxxx"といったファイルになり、ファイルやフォルダが削除されてしまい、使用できない。
③ CBRファイルの中に、上記②のような名前を持つファイルが格納されている場合に
正常に使用できない。
④ Wifi設定が壊れてしまうと、以後何度設定を変更しても保存されなくなる。
⑤ 外部SDカードを使っていると、色々なタイミングで高確率でフリーズする。
⑥ 青キン明朝などのユーザーフォントを利用していると、電源ON時に開いた本でその設定が壊れ
デフォルトの設定に戻ってしまう
２ 追加機能
① 外部SDカード、内蔵ストレージに保存されたzipファイルをcbzファイルにリネーム
② 外部SDカード、内蔵ストレージに保存されたrarファイルをcbrファイルにリネーム
③ 外部SDカード、内蔵ストレージに保存されたTextファイルをHTMLに変換
④ PDF,CBZ,CBRファイルのページ送りをkepub.epubと同じ左→右スワイプ、または
スクリーン左部タッチにより「次ページ」になるように変更する機能
⑤ CBZ、CBRファイルのファイル名が [著作者名] 書籍名.cbz(またはcbr)というフォーマットに
準拠している場合、Kobo上の著者名、書籍名を自動で正しく更新する機能
⑥ 書籍の登録後に、ユーザー本、ストア本ごとに著者名・格納しているフォルダ名・出版社名
などから自動で本棚を作成して書籍をその中に格納する機能
⑦ 壊れたり、消せなくなった本棚を全て削除し、⑥の自動本棚作成機能を使って本棚を
再構築する機能
⑧ 内蔵ストレージ領域に、Linuxのswapパーティションが存在した場合、起動時に自動で
スワップ領域としてKoboが利用できるようにする機能
⑨ データベースが肥大化してしまい、動作が重くなった場合にデータベースの最適化を
実施する機能
⑩ データ補完をKoboのコンテンツ処理に連動して実行。また、起動時に再補正を実行する機能
⑪ データの高速Commitモードを使う機能
⑫ 起動中やサスペンド画面に表示されるアニメーション・静止画を自由にカスタマイズできる
テーマ機能
⑬ (kepub.epubのみ）使用するフォント、フォントサイズの設定をテンプレート書籍の設定に
従って全書籍共通化するフォント設定共通化機能
⑭ 最後に読んだ本が格納されている本棚にある本を「最近読んでいる本棚」に自動登録する機能
⑮ データベースのキャッシュサイズを任意に拡張するDBキャッシュサイズ拡張機能
⑯ Koboがフリーズした際に、電源LEDを赤点灯し「フリーズしたこと」を通知する機能
⑰ よりKoboで読書を快適にするための独自フォント「KB Mincho」「KB MinchoM」の実装
http://ux.getuploader.com/KOBO_HACK/download/103/shelveicon-130327.zip
kobo glo, mini の場合、検索アイコンが追加されます。
kobo touch にはもともと検索アイコンがあるので変化ありません。
また、今回はソースも同梱してます。
QtCreator にカスタムウィジェットを追加するプラグインができました。
https://github.com/t-bucchi/NickelWidgetForQtCreator/archive/130406.tar.gz
これは github で公開することにしました。
TouchDropDown のリストアイテムが GUI 上から追加できないなど、
まだ色々いまいちなところがあるのですが、とりあえずデザインはできるように
なりました。
# こんな程度じゃ Promotion で作ってもあまり変わらないかも・・・
また、上記プラグインを追加した QtCreator で前回作った CFWSettings をデザインした
サンプルも用意しました。
http://ux.getuploader.com/KOBO_HACK/download/109/CFWSettings130406.zip
今回は、CFWSettings のプロジェクト自体を QtCreator で開けるような形に
なってます。
ツールチェーンなどのビルドの設定さえすれば、QtCreator 上でビルドも可能です。
なかなか時間が取れなくて、遅くなってしまった。
もっと早く出したかったんだけど。
設定メニューに "CFW Settings" を追加して、タッチすると Widget のサンプル画面が表示されます。
ソース:
http://ux.getuploader.com/KOBO_HACK/download/105/CFWSettings-130330.tar.bz2
バイナリ:
http://ux.getuploader.com/KOBO_HACK/download/106/libcfwsettings.so
画面イメージ
http://ux.getuploader.com/KOBO_HACK/download/108/kobo-cfwsettings-1.jpg
http://ux.getuploader.com/KOBO_HACK/download/107/kobo-cfwsettings-2.jpg
TouchLabel など、tweaks で解析済みのカスタムウィジェットに加えて、ドロップダウンリストや、
ラジオボタン、画面下部のページ切り替えウィジェットのクラス定義も調べて追加しました。
- TouchLabel (タッチ可能ラベル)
- TouchCheckBox (チェックボックス)
- TouchDropDown (ドロップダウンリスト)
- RadioButton (ラジオボタン)
- N3ButtonLabel (通常のボタン)
- TouchSlider (スライドバー)
- WirelessPaginationWidget (ページ切り替え)
ひとまずこれだけあれば設定画面を構成するのに充分かなと思います。
まだ、QtDesigner での構成でなく、直接コードに書いています。
Kobo用フォント第3弾「KB丸ゴシック」初リリースです。
KB明朝と同じく、Kobo端末上でキレイに縦書き/横書き表示されるように、
調整を行いました。
英数字がプロポーショナルになっています。
その他の文字は等幅です。
★ダウンロードは以下からどうぞ。
(バージョンがBeta6となってますが、初リリースです)
http://ux.getuploader.com/KOBO_HACK/download/100/KBMaruGothicBeta6.zip
★このフォントはまだベータ版です。
なので、フォント名は「KBMaruGothicBeta6」となっています。
バグ等を潰したのち、近いうちに「KBMaruGothic」になる予定です。
Kobo上で、書籍へのフォント設定を行う際は、この事をご留意下さい。
「お試し」でご使用されることをおすすめします。
★Readmeを読んだ上でご使用下さい。
このファイルを使用したことで何か問題が発生しても責任は負いかねます。
★不具合のご報告や、ご意見・ご質問・ご要望等あればご遠慮なくどうぞ！
内蔵64GBへの換装、成功しました。
作業手順は通常の換装とまったく同じです。
http://s1.gazo.cc/up/51203.jpg
http://s1.gazo.cc/up/51204.jpg
http://s1.gazo.cc/up/51205.jpg
CFW0.95と検索アイコンをインストール後、
いま読み途中の自炊cbzを20冊ほどコピーしましたが、
表示、検索ともに問題なし。作者名の本棚も自動作成OKでした。
耐久性うんぬんはしばらく使ってから、ということで。
明日は6時出勤なので、今日はこのへんで失礼します。
おやすみなさい。
耐久性より32GBを超えた書込みの方が気になる。
64GBのSD使えたんですね。
一通り調べた際、殆どのサイトで32GBが使われていて64GBの話題は無かったので、
勝手に32GBまでしか使えないと思い込んでました。
前スレのcbzの人、xpの圧縮フォルダでzip作ってないよな？
あれ2GB制限あるんだよねw
http://support.microsoft.com/kb/301325/ja
乙
スゲーなあ。まともに動くなら追加投資5000円の価値はあるな。
しかし、高速MicroSDを内蔵した結果、超低速ストレージに化けそうで勿体無いなw
30mb/秒が3mb/秒ぐらいにはなりそうな悪寒。
使えるなら外部SD運用の方が幸せだったり。
7+Lhaplusで作成しましたが、
そういえばその際に何かダイアログがでていたのを思い出しました。
なるほど、改めて思い返すとzipの作成ミスだったのかもしれません。
別のソフトでzip作り直してみることにします。
え？てことは最適化していないのかな？
ChainLPで最適化した巻別のcbzを作った後に全て解凍しタイトル別に圧縮。
という、手順を踏んだため最後にLhaplusを使う事になったのです。
エラー出まくるから
それでlhazに乗り換えた
一気読みには良いかも知れないが、koboでのページ扱いとか考えると無茶な気がする。
>>3使わなくても外部SDは認識できるはず。
フリーズしちゃうんだけど
すでに2月に出ていたとは知らなかった
失礼しました
ちなみに、今のところcbzもcontentにフルページ情報が必要っぽいので、ダイエットしても半分くらいです。
帰宅電車であれこれいじりましたが、レスポンスは32GBのときと体感差は無しです。相変わらず本棚は遅くて使い物になりませんが。
32GBはclass4、64GBのほうはclass6相当のはずなので、体感できるほどのパフォーマンス差はないかもしれません。
たぶん外付けでも64GBいけるはずですが、未確認です。
その千数百個のデータで32GB以上入ってるんですか？
元々巻別で管理してたのですが、ファイル数が多く本棚を開くのに何秒もかかりあまりに不便だったためタイトル別にまとめたのです。
> 一気読みには良いかも知れないが、koboでのページ扱いとか考えると無茶な気がする。
ページの扱いが無茶、とはどういった意味でしょうか。
以前と比べ不便に感じるのは、本を開く際に少し時間がかかるくらいだと思っているのですが。
ご存じだと思いますが、SD、SSD、HDDに限らず、フォーマットすると
おおよそ10％容量が減ります。
SDHCの32GBでは、だいたい29GBくらいが空き容量として残るでしょうか。
そこにkoboのシステムやらCFWのスワップ領域を確保するため、
最終的な空き領域は27GBくらいだったと思います。あくまでも私の場合です orz
要するに私の環境では27GB超えれば、32GBのSDカードを満杯にしたのと同じということです。
現在1177個のCBZファイルで26.5GB転送済みなので、あと500MB転送すれば、32GB分は消化した、ということです。
そんときにまた報告します。
実現方式の検討はできるものの今のところ実装の余裕がない…
*cbzのメタデータ
tweaksのQtScript(JavaScript)pluginを改造してhook経由のshellから外部kickさせて、
scriptでzip内のepub準拠opfをparseしてdb登録させる、とかすれば
著者名やら諸々を綺麗な標準書式metadataで対応可能なのかもねえ。
無理にQtScriptをつかわなくても、Python(PyGameのやつ)だとか、
opfのxmlをparseして必要情報に変形できればOkだから
xsltprocモノ+shellでもいいんだろうけど。
(metadataを限定的にするなら正規表現で必要情報を抜き出すだけでもいいだろうし)
#libxslt(xsltproc)とかlua(standalone)とかsquirrel(standalone)とか、
#使えそうなものは一応昨年末に途中までportしてあったりする。
#(バイナリだけは作って未テスト)
#standaloneでのlua,squirrelあたりはpythonよりはfootprintが小さいからportしようとしたんだが、
#xml,sqliteに対するbindとかその辺を調査しないと実際に使えるのかわからん。
これだけだと、libcbの構造上、zip内1ファイル=1recordなのは解消できないけど…
あ、gotoPage等その辺をいじって論理pagenoと実pagenoの変換すれば
1話(実1章)=Koboの認識する1章にできるのかもしれない…
実pageno=章top + 章内offset
goto系のページ移動は章内offsetのinc/decと範囲外への移動で章も移動になるようhack
これだけだとjump移動が破綻するから、libnickel側のReadingViewのMenuViewとかも
章対応にしないといけないか…ここはちょい調査がいるので厄介そう
DB側に記録されるdogearとかその辺も合わせて辻褄合わせないといけないだろうし、
生png/jpeg,metadata対応cbz(cbr),metadata未対応cbz(cbr)の3つを少なくとも
libcbで扱わないといけないからかなり大変だなあ。
*サムネJump
menuの項目追加して、複数ページ(WirelessPaginationWidgetを置いた)dialog上に
dialogの1ページ＝Nサムネに分割して複数ページに貼り付けていって、
indexからのページ移動みたいな操作でjump pageさせるようにすればできる？
オンデマンドでサムネ生成していくのはさすがに操作性に劣るだろうから
事前生成だとして、登録時に負荷がかかりすぎるのが難点。
i各ページのサムネ生成と保存をしないといけないから
全コンテンツの読み込み＆(サムネ生成に必要な分の)decodeがいる。
まあpcで事前生成させるとか端末外に回せる作業ではあるが。
生成したサムネはまとめて(zip2cbzにかからない拡張子ordirで)zipにするとか、
コンテンツ個別dbを作ってそこにぶち込むとかすえばOk。
nickelが想定しないサブファイルができているので、nickelのコンテンツ削除をhookして
コンテンツ本体のcbzが削除されたときに、サブファイルも消すようにしないといけない。
サブファイル削除にリアルタイム同期は必要ないから
・Linuxのdir監視の仕組みを使ったイベント処理
・既存のhookの枠内でのcleanup処理
とかでもいいか。
サブファイル生成はキャッシュ的な位置づけで
・事前生成済ならそれを使う
・なければオンデマンドでサムネを生成した段階でサブファイル生成
でいいかな。
キャッシュ的な観点だと常にバカ正直に残してもメディア容量食うだけだし、
基本ReadOnlyな外部sdの扱いが面倒になるから、
完全にキャッシュとして、limit sizeまでのサムネを残す、
としたほうがシステムとしては正しいのかもしれず。
ごめん、何を聞きたいのかちょっと分からないんですけど
割れR
良くある画像kepubは1つのxhtmlで1つの画像を表示しているだけだから
画像が200枚あればxhtmlも200個になるんだけど、うちのは目次項目の数しかない。
つまり1つのxhtmlに複数の画像が入っている訳ね。
1つのkepubあたりの画像は平均200枚前後で、xhtmlはだいたい10～20個です。
こんな話でいいのかしら？
ああ、なるほど。ChainLPだけではないか、別の方法で作っているということですか。
どっちにしろcbzの場合には使えない方法ですね。
では半分程度の削減で我慢することにします。
ありがとうございました。
私は、cbzを悪く言うつもりはないけど、何一つカスタマイズできないので
独自のkepubに完全移行しました。
まだまだ作成は面倒だけど、ページめくりも基本cbz同等だし満足している。
いや、残念ながらcbzとkepubで決定的に違いがあります。
cbzだと1頁毎に反転しないのです。設定によりますが。
ですからサクサク読み込め頁めくりも速く眼も疲れません。
360MBのdbでもとりたてて遅いと感じませんでした。
600冊ほど、実際には複数巻をまとめたので800冊以上でその程度です。
半分にする方法はvolume_shortcoversテーブルの内容を削る方法ですが、これだとしおりを書き込みで呼び出すことができなくなります。
今実験的に半分にしてあり、それでしばらく運用してみます。
いや、うちのはcbzと同様にMAX6ページ毎のリフレッシュになりますけど…。
ただ、公式ファームのバグで、2.4.0からは一度アイコンメニューを出さないといけなくなってるけど。
あと、ページめくり自体は本当にcbz同等です。
なるほど。
頁移動はどうなりますか？cbzだとスライダーで１頁めから最後まで移動できます。
ChainLPで作ったものだとスライダーが使えないから不便でした。
上でも書いたけど、全体をいくつかのブロックに分けていて、
それぞれxhtmlに複数枚の画像が入っています。
そのxhtmlの中の画像群ごとにスライダーで移動できます。
ただ、cbzでは有効な移動手段がそれしかないのかもしれませんが、
kepubだと、xhtmlごとに目次に名前を付けてジャンプさせる事ができるので
通常はそちらを使用し、移動でスライダーを使う事はまずありません。
目的の画像へ飛んで、そこから普通にめくるだけです。
ChainLP作成のkepubでスライダーが使えないのは、
使えるべき範囲に画像が１枚しかないためです。
何度も回答ありがとうございます。
やはりそうなるのですね。
一気にジャンプが欲しいので私としてはcbzのスライダーがありがたいです。
kepubも良さそうですが、ChainLPが自動でそういうxhtmlを作ってくれるのでなければ手間が掛かって大変そうです。
今でさえ、同じタイトルの本を読んでいる最中に気に入らないからとしばしばChainLPにかけ直して調整していますから。
色々試行錯誤されていますね。貴重な情報ありがとうございました。参考にさせていただきます。
別に仕様上は全画像ひとまとめにする事は可能なんですが、
epubのがっかりな仕様により、大量の画像には向いていません。
この仕様のkepubに変換する簡単ツールは公開済みなんですが
未だ誰にも認めてもらえず残念至極ｗ
どこに公開してあるの？
試してみたい
ごめん みつけたw
すぐにみつかってビビった。
試してみるね。ありがとう。
ときに、分割上限が22なのには訳があるの？
この分割仕様なら全30巻とかのコンテンツもまとめられそうな気がしたんで。
分割の項目数は、最初に窓の大きさを決めた時に入ったのが20項目だったのと
koboの目次項目数が１ページ11だったため22になっています。
上限撤廃は考えていますが、画像を直接いじる機能を積んだ後の予定です。
あと、画像入力は9999枚まで通ると思いますが、
1ファイルの想定はコミックス1冊程度で、1分割30枚程度です。
分割しなくても直接特定の画像までとばす方法はあるのですが
わざわざ分割させているのは、epubの残念仕様を緩和するための苦肉の策なのです。
よって、内容は不明ですが30冊もひとまとめにすると、きっと残念な結果が待っています。
（分割上限がなければ実用性はあるかもしれないが）
今のCFWの本棚を使えば、なにも30冊をまとめる必要はないと思いますけどね。
沢山のファイルを入れると重くて本棚が役に立たなくなるんよねw
あっ！
もしかして、cbzをこのePubに変更すれば、本棚も実用的な速度になったりして？
たくさんとはどれくらい？
500冊くらいでは速度は落ちないよ。CFWだと。
一冊あたり35MBぐらいだとして、千冊分ぐらいのcbzを運用してる。実際はまとめてるので、ファイル数としては300ぐらい。プラス、テキストベースのePubが百冊ぐらいかな。
要するに32GB満タンです。本棚はアクセス時に10秒～20秒待たされます。
DBサイズは600MB程の大所帯です。
ちなみに500冊のその状態でDBのサイズはいかほど？
1日1冊でも3年くらいかかるね
320MB。
本棚の数が多いんじゃない？
1000冊、cbz : DB318MB
なんか辻褄が合わなくておかしくね？
謎は深まルネ～w
でも、確かに本棚の量は多い方かも。
今、あらためて数えてみたら、250件程ありました。原因はコッチなのかも。
辻褄は合うでしょ。ひとつのcbzファイルに何冊分を入れてあるかとか、1冊でも普通のラノベはページ数が少ないけど、例えばカズムシティなんか入れればページ数は多い。
ラノベでも分厚いのを見かけたことがある。なんとかのホライズンとかだったような。紙の本の限界に挑戦みたいなの。
いや、勿論そういう運用誤差はあるだろうけどね。ただ、確実に一冊単位で作ってるePubと沢山放り込めるcbzでは後者の方がDB大きくなりそうだなあーとイメージしてた。
さらに言えば、サンプル情報の本の冊数はcbzの方が倍多い訳でw
なんか訳わからん感じの仕上がりじゃね？
まずはdbの中身を覗いてみよう。
そうすれば理解できるはず。
んんーじゃあ同じコンテンツ(200ページ分)をcbzとePub(内部分割10)で作った場合は、どうなる筈なの？
予想では、劇的にePubの方が軽いと認識してたんだけど。違うのかなあ。
そうでなきゃ意味なくね？
ってのは誤情報ってことでええの？
仕事しろヲタカス
ので、CFWに初めて手を出してみることにした。
しかし、 >>3 がダウンロードできないので 0.95β5でとりあえず運用中。
ダウンロードのコツとかあるのかな?
つーわけで、再Up
0.95
http://ux.getuploader.com/KOBO_HACK/download/111/Kobo_CFW_Ver0.95.zip
0.95Plus
http://ux.getuploader.com/KOBO_HACK/download/110/Kobo_CFW_Ver0.95_Plus.zip
パスワードロックやセンターズーム使いたい人はPlusを、それ以外は0.95でどぞ
しかし、1ファイル3Gってｽｹﾞｪなあｗ
スワップ無かったら絶対に開けないんじゃなかろうかｗ
どういう比較検討からそんな結論付けになるのか一度きっちり説明して欲しいわ～
流れだけ見ていたら、誰もまともに検証してないでしょうに。
憶測だけで結論を出していたら、またいつか同じような話題になった時に
「誰かが意味無いって言っていたよ」 という無責任な一言で片づいちゃう。
他力本願はいいけど、根拠のない無責任な発言はイカンと思うんだよね。
別にcbzと画像epubとどっちが有利だろうと、かまいはしないけど
何か決定的な比較要素が欲しいんだけど、何か無いですか。
DBのサイズを比較検討するのに、下記のコンテンツサンプルがいるね。
コレは簡単に作れる。
1. cbz
2. ChainLPで作成した画像ePub
3. ReconstructionKepubで作成した画像ePub
勿論、同じ元データで作成。
んで、コレを検証するために、ファクトリーリセットしたkoboで(ry
ファクトリーリセットまんどくせー
ってことなんでね？
DBの中身を見れてる人が恩恵無しと言ってるんだから、俺は検証する労力が惜しい。
あとは、気になる人に任すわ。
TNX
例：100ページの漫画をepubとcbzにした場合
keypub：毎ページが「挿絵」と同様に処理されるため、100レコード最低限できる。
cbz：最初っから１ページ1レコード。つまり100レコードであることには変わらない。
なので、DB上は「どっちも変わらない」。
だけど、epubはメタ情報を読みながらの展開になるので、jpgやらpngをレコード情報から
単に読み出して表示するだけのcbzよりびみょーにウェイトが入る。
こんなとこかの
詳しい事は分かりませんが、3GBのファイルが開けるのはCFWのおかげなんですね。
改めて各開発者を始めkoboayaさん、
ありがとう！！
＞keypub：毎ページが「挿絵」と同様に処理されるため、100レコード最低限できる。
↑これが100レコードでなければ同じではないということ？
さらに、テキストepubでも100個のxhtmlに分かれていたら、画像100枚のcbzとDB上の重さは同じという事ですか？
・DBのファイルサイズ
基本的に大きくなることはありますけど、普通に使ってるとサイズが小さくなることは
無いと思ったほうがいいです。
例えば、本を消してその本に関するデータが全て消えたとしてもサイズは変わらないと。
これはSQLってデータベースの仕組みだから仕方無いわけです。
ファイルサイズだけでかいまま、中に保持しているデータ量だけ減っている、そんな状態。
なので、データの保持状態如何によっちゃ遅くなったりするわけでござる。
CFWの「データベース最適化」機能ってのは、この肥大化したデータをスリム化する
機能なわけです。ハイ。
逆を言えば「めったに本を消さない人」は、最適化機能はあまり恩恵は無いのです。
・本棚が開く速度
本棚は、本棚の数というより本の数に関係すると思ったほうがいいです。
本棚が１つ２つでも、中に数百といった本が入っていれば遅くなります。
逆に言えば本の数が少ないと、本棚が幾ら増えてもあまり速度低下はありません。
・内蔵SDの64G化
できるもんなんだなあ・・凄い。
でも、多分64Gをパンパンにしちゃうと、nickelの構造上かなり遅くなるのでは・・・
これは是非動作速度の報告が欲しいですねえ。
ちょっと前に、VolumeIndexテーブルの中身を消して運用している人がいたみたいだけど
特に大きな問題は無いのかな？ DBのスリム化という意味じゃ大いに意味があるとは
思う＞VolumeIndexの削除
ではでは
テキストベースのepubはレコード数は劇的に少ないですよ。
まぁ、中身をどう作るかにもよるとは思うのですが。
（xhtmlをどう分割するかってコトやあね）
漫画ってのは、ページの連続性を保証するために1ページ1レコードにせざるを
得ないわけだけど、テキストベースだとフォントサイズや
行間設定によって1ページに表示できる文字数が変化するわけだから
何を持って「1ページ」とするか、決められない。
なので、そういうレベルでデータを保持できない。
漫画はそんなことないでしょ？ 文字の設定がどうだろうがなんだろうが1ページは1ページ。
epubファイルの細かいフォーマットとかはよくわからないけれど
漫画をepub化したときに、例えば１０ページを一つのxhtmlに記載すればDB上は
1レコードになったりするのかもしれないけれどねえ。
えええー！ずっとその話してるですけどw
効果ありそうじゃんw なんやねん
200ページの漫画を10個のxhtmlに分割してePub作ると200レコードが10レコードになるかもってことですか？
でも、挿絵とかの情報を保持しているvolumeなにがしってテーブルは、
200レコードになるんじゃなかったっけか。
（流石にそんな検証はしたことはないｗ）
メインの情報を読み込み→挿絵情報を読み込み→データを展開って流れだから
DB的に考えれば、メイン：挿絵情報が１：１のほうがロスは少ない。
けど、nickelの内部での処理は遅いかもしれない
（漫画のepubが”もっさりする”という原因はおそらくこれじゃないのかな）
この比率が１：１０になったら、漫画のepubのもっさり感が減るかも。
でも、それはDB云々じゃなくnickelの問題かと思われ
なんとなく、ｃｂｚでも画像epubでも、「理論的には」出来上がったDBの大きさが同じだから
どちらで登録しても動作に変化は無いだろう、という理屈で >>72の結論に至った事は分かりました。
でも、前スレで自分のDBの容量が他の1/10程度だと判明した事から
画像epub内のxhtmlの数を減らしている事が直接DBの容量に関わっている事がうっすら分かった気がします。
かといって、動作が軽いのか普通なのかは全く分かりませんけど。
それでも気になるならChainLPを使っているcbzの場合、以下のようにすればdbサイズが半分になる。ただし、しおりをはさめるけど呼び出せない。
今のところこれ以外の不具合なし。自己責任で。これでわかる人でなければやっちゃだめ。
delete from volume_shortcovers where shortcoverID like '%.cbz/P0____.%';
vacuum;
しおりの問題はcbzだけ。同じdbにあるkepubには影響なし。
xhtmlを作るのはChainLPだけですまないし、スライダーでのジャンプができなくなるから私は使わないことにしました。
地道にスライダージャンプは便利。
32GBのSDHCが記録できる実容量は約29GBですから、64GBのSDXCの有効性は確認できました。
この状態で本棚を開くと、おおよそ90秒近くかかります。
本棚（作者名）が483個もあるので、やむをえないところでしょう。
一方で「ライブラリ」→「本」の表示はそこそこ速いです。
およそ2秒程度で縦5個の表紙サムネイルが表示されます。
まぁ、1画面分を送る、または戻るごとに2秒程度かかりますから、多少のストレスは感じます。
検索も実用的な速度で、ほぼインクリメンタルサーチと言っても過言ではないです。
現状では本棚の利用はあきらめました。
その分、大量の自炊本を持ち歩けるほうが私的にはうれしいです。
＞koboayaさん
CFW便利に使わせてもらってます。
64GBいっぱいになるにはまだしばらくかかりそうですが、上記のとおり、検索が圧倒的に高速なので
私としてはストレスフリーで使えると期待しています。
強く連携を求む。
まあ当面は私もcbzかな。
容量削って速度が上がるならともかく、現状では変わらないからね。
ページジャンプが快適な方が良いよなあ。
割れR
宇宙人さんお疲れ！
本棚483個・・・。
初期のkoboからすると想像を絶する運用だなあ・・・。
それを利用すると具体的にどんな事ができる様になるのでしょうか。
そう言った事は詳しくないので、よければ詳しい人がいれば教えていただけませんでしょうか。
電源OFFできないし、リセットホールのリセットもできません。
どうすればいいですか？
充電は切れてませんか?
それも考えられないようであれば、koboサポートへGO!
お騒がせしました。
復活おめですw
内部に３０G、外付けにもcbzいれており、ファイルは1500ほどです
ホームから本棚に移動は15秒で、読むのも問題ないのですが、
最近よんでいる本棚を編集しようとすると3分弱またされます。
こんなものでしょうか？
それともswapがまちがってるのでしょうか？
swapとはよくわからないのですが、partion wizardで90MBほどにしてMAX設定したのですがやり方あってますか？
初心者のためすいませんが教えてください。
本棚の数は６０です
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
【ソニー】Sony Reader■47冊目【リーダー】 (259)
【ソニー】Sony Reader■47冊目【リーダー】 (259)
【電子書籍新時代】ブクログのパブー2【超簡単】 (586)
au biblio Leaf SP02 part2 (810)
【電子書籍新時代】ブクログのパブー2【超簡単】 (586)
Amazon Kindle 洋書スレ (208)
--log9.info------------------
【美人】大島ミチル【天才】 (561)
三枝成章 (479)
報道番組等でｱﾆﾒ･ｹﾞｰﾑ系等のｻﾝﾄﾗ音楽が流れるｽﾚ (395)
【悪霊退散】レッツゴー！陰陽師【ﾄﾞｰﾏﾝｾｰﾏﾝ】 (749)
【マエストロ】エンニオ・モリコーネ【巨匠】 (636)
サントラ盤に肝心の曲はいってねえ (367)
【ﾚｱ？】こんなサントラGETしました【掘出し物？】 (263)
加古隆スレッド (346)
俺様のお気に入りサントラを教えてやるスレ (300)
Vガンダムのサントラ (226)
坂本龍一 (690)
■映画・ドラマ音楽(仮)＠2ch掲示板 (297)
NHK大河ドラマのテーマ曲 (582)
† ホラー映画のサントラについて語る † (555)
本当に泣ける映画 (309)
松本晃彦 (512)
--log55.com------------------
ＡＩファースト、文系学歴の終焉 ５。 人工知能/スパコン/量子コンピュータ
【覚醒剤】平塚ノンキャリア組、ヤクザと組んで私大２番手慶應持ち上げんな【麻薬】
【立命館＞同志社】関西の私大は、立命館大学が別格。
ゲーム批評ブログ「腐れゲー道」総合スレ
ゴジラ強さランクスレ11
(´◎ω◎`)けんか腰で馴れ合うスレ第七百五十一駅目inシベリア！
恵比寿マスカッツ総合スレ Part 5
シベリアイベント広場16