最終更新: 2012-06-05T20:30+0900
Readerに接続したメモリーカードのルートにこのスクリプトをコピーして実行するとそのメモリーカード内で最後に開いた 3冊の本がホーム画面に並ぶという、以前書いてたあれをすることに。並べ替えが PC接続時に限られるのがいまいちでその気はなかったのだけど。
方法は、ファイルの最終更新年を未来のものに書き換えてる。本来の更新年月日を最終アクセス年月日として保存してるのでアクセス日の記録は失われる。
今使ってる版はこれ($3-touch_last3_opened_books.20120101.rb)。MemoryStickと SDカードの二枚差しになったのでメモリーカードドライブのルートで実行する代わりにドライブ文字をハードコーディングしてる。ところで、Rubyの 2038年問題って何?初耳。このスクリプトの「MAGIC_YEAR = 2035..2037」って部分と明らかに関係があるんだけど。
Bing検索でトップのスライドを読んだら Ruby 1.9.2で Timeが大幅にパワーアップしてるらしい。2038年以降だけでなく以前に書いた(組み込みの Timeが UTCと localtimeしか扱わないのがもったいない。任意のオフセットに基づいた日時を出力したいだけだから、DateTimeは牛刀な印象がある)、任意の時差も扱えそう。そもそも Timeの制約って OSの制約がそのまま見えてたってわけだったのか。
今使ってる版はこれ。
$3-touch_last3_opened_books.20120605.rb (2.1KiB)
オプションを新設。--set
オプションで最近読んだ三冊の更新日時を未来のものにセット。--reset
オプションで本来の更新日時を復元。オプションなしで従来通り reset&set。
分離できるようにした理由は、更新日時の復元と更新の間に、robocopyで Readerと自炊ファイルの同期を行いたかったから。2035(,2036,2037)年のタイムスタンプがセットされたままだと Readerにある方が新しいと誤認されて転送されなかったりする。
それと、連続して --setを行うと本来の更新日時が失われる不具合を修正。何度 --resetして --setして --setしても同じ結果になるように。
* 作業した順番が悪かったせいで『4871826090』だとか『4871826198』だとかが。
最終更新: 2012-11-03T16:19+0900
主観的な評価なのでどうでもいいと無視したもの、(PRS-650にて)未使用の機能につき評価不可能なものは含まれておりません。
関係ないけど、Calibreが取得したニュースを転送する前に「デバイスから本の情報リストを取得」するんだけど、それが完了するまでに充電が終わってしまった。約一時間。今度は忘れずに接続前にメモリーカードを抜いておこう。問題ないかな?
Calibreは空のコレクションを勝手に削除する。
最終更新: 2011-10-29T21:40+0900
何時間もかかるこれがどうやったら速くなるでしょうか?
いまは可能な組み合わせを全て試してみて、できあがった数字をカウントしてる。その後で素数を順番に辿って生成カウントが 1のものを足し合わせたものが答え。上限が 10倍になるごとにどえらく計算量が増える。かけ算ならまだしも足し算の組み合わせに有効な考え方を自分が全く持ち合わせていないことがこれまでの問題からも何となくわかってる。どうすんの?
# PE333 require 'mathn' # Primeが使いたいだけなのに。グローバルフラグは悪。 UPPERBOUND = 100_0000 EXP3_UPPERBOUND = (Math.log(UPPERBOUND)/Math.log(3)).floor+1 EXP2_UPPERBOUND = (Math.log(UPPERBOUND)/Math.log(2)).floor+1 # × 2^0 2^1 2^2 2^3 2^4 2^5 2^19 # 3^0 1 2 4 8 16 32 524288 # 3^1 3 6 12 24 48 96 # 3^2 9 18 36 72 # 3^3 27 54 # 3^4 81 # 3^5 # 3^12 531441 primes = Hash.new(0) q = [] sum_of_q = lambda{ sum = 0 last_exp3 = EXP3_UPPERBOUND q.each_with_index{|exp3,exp2| next if exp3 == last_exp3 sum += (1<<exp2) * 3**exp3 last_exp3 = exp3 } return sum } fill_q = lambda{ q.fill(q.last||EXP3_UPPERBOUND, q.length, EXP2_UPPERBOUND-q.length); } fill_q.call until q.empty? exp2, pow2 = q.length-1, 1<<(q.length-1) next q.pop if q[exp2] == 0 q[exp2], pow3 = q[exp2]-1, 3**(q[exp2]-1) sum = sum_of_q.call q[exp2], pow3, sum = q[exp2]-1, pow3/3, sum-(2*pow2*pow3/3) while 0 <= q[exp2] and UPPERBOUND <= sum next q.pop if q[exp2] < 0 primes[sum_of_q.call] += 1 fill_q.call end sum = 0 Prime.new.each{|pr| break if UPPERBOUND <= pr sum += pr if primes[pr] == 1 } p sum p Process.times #=> <struct Struct::Tms utime=25990.64, stime=150.806, cutime=0.0, cstime=0.0>
最終更新: 2011-10-27T13:34+0900
本機は省電力機能により以下のように動作します。
- 約10分間操作がないと自動的にスリープモードに入ります。
さらに3日間*操作がない場合には、電源が完全に切れます(シャットダウン)。
*バッテリーの残量がほとんどない場合、3日以内に電源が切れることがあります。
ご注意
省電力機能はオフにできません。音楽の再生中や、写真をスライドショーで表示しているときは、省電力機能は効きません。
文書番号:038034更新日:2011/10/19
新型の省電力機能はシャットダウンまでの待ちが 2日から 3日に伸びて(※スリープまでは 10分でそのまま)、そして馬鹿げたことにオフにすることができなくなってる。>「ふとした拍子に届いてしまいそうな近くにタイムアウトが存在していることが俺には耐えられない。そういうときっていうのは集中してるとき(あるいは寝てるとき……)なんだから邪魔されたくない。(20111013p01)」
スクリーンセーバーだとかを設定する機能が旧型からあるが、PRS-650のそれを何にするか迷ったりはしなかった。読みかけのページが表示されていればいいからだ。ブックカバーを開けば続きが読める、それがいいのじゃないか。なんであれや(SS)これや(Sleep)で遠ざけることに熱心なんだ。
スリープモードの時の表示が、kindleのようなランダムな画像ではなくそのとき読んでいる(最後に読んだ)本の表紙になっています。
これは評価する。それでもスリープにはしない(=最後に表示したページが表示されたまま。タッチセンサーがオンなのに注意)けど。
最終更新: 2011-12-03T00:05+0900
重い*。本体も重いがカバーも劣らず重い。グラフギア1000に似てる。質感はいいけど実用品としてアリかナシかを問えば、ぎりぎりナシだ。はみ出した部分は見栄でカバーしましょう。グラフギア1000はクリップと噛み合う内部の樹脂部品がバネと筆圧にさらされることでえぐれて短期間で使用不能になる代物だったが、Readerに同じような落とし穴(質感?このていたらくで?)がないことを祈る。
ソニー 電子書籍 Reader TouchEdition 6インチ(レッド) PRS-650-R
Sony
¥ 15,000
カバー。PRSA-SC65/BC(WW). 素材は持っていて楽しいものではない。安くなっても 15000円するものを 2か所のプラスチックの爪で宙づりにする構造も不安になっていけない。綴じた本と同じ部分を固定する造りだから、Readerが右回転するような、不均等な力が爪にかかるのも気持ち悪い。そういう電卓があったんだけど、角を引っかけて支えるような仕組みが欲しかった。ストラップホールがあればスキーのストックのような落下防止策を講じることもできた。Readerに内蔵された磁石で閉じた状態を保とうとするが、表面の方がより強力に引き合ってるために裏面の方が開きやすい。開いたカバーを裏側に折り返すとふくらみができて、これによる右下がりの傾斜が読むのに邪魔で狭いスペースに置けない。アイロンでもかけたらどうなるだろう。これが縦開きだったらふくらみが読むのに都合のいい傾斜を作ってたろうに。
いざ試さん、と電源スイッチをスライドしても反応がない。長押しでもタッチだったわけでもなく、充電切れだった。eneloopじゃないし簡単に自己放電しちゃうんだろうけど、ピクリとも反応しないとは思わなかった。3時間も充電中とだけ表示される Readerを眺めさせられるというのはおあずけが過ぎるワン。充電中でも操作ができるという充電器は別売だし、PCに接続したときにマスストレージモードと充電モードを切り替える器用さは Readerにはない(Rio SU30は持っていた)。
LRF. マニュアルには対応フォーマットとして載ってないけど起動画面には Adobeと並んでしっかり BBeBのロゴが出る。当てにできるかわからん保証の類よりは読めてることが大事。
内蔵メモリ 2GB. テストデータのひとつとしてマンガ29冊を結合した PDF(1GB)を用意していた。他のと合わせて転送しようとすると空きが 900MB足りないと出て、初めて法外なデータを扱っていたことに気付いた。実質容量 1.5GBなんて自炊派には論外な数字だ。同じヤマトなのに一日早く発送されたはずの microSDHC(32GB)がまだ届いていない。
見え方をテストしていた。
小さい。解像度はいくらあっても困らないからいちいち言わないけど、画面の大きさがやっぱり小さい。漫画文庫を読んでるような気分。あの、文庫サイズのうえにどのページにもページ番号と余白が確保されてる漫画文庫。文庫本(文字の方)を読むのには不自由しない。少し余裕があるので余白をカットしすぎないようにするつもり。上と下にはそれぞれ 2文字分。左と右にはそれぞれ行間 1つと一行の半分くらいの余白があれば、裁ち切られた紙(じゃないけど)の上にあったかもしれない文字を探してしまうこともないだろう。筐体が白だったらそのフレーム部分を余白とみなせたかもしれない。持ってないのでわからんけど。
500MB、3500ページ超の PDFも 50MBの PDFと変わらない待ち時間で開けた。「フリーズしやすくなる」というのはどういう場面だろう。検索とかページ移動? 1GB、6000ページの PDFも試してみた。開くのは少し遅くなって丸々 2秒くらい。シークは軽快(たぶん「Web表示用に最適化して保存」の効果)。わりといけるんじゃないか。ちなみにこの巨大 PDFは ChainLPが出力した PDFを Adobe Acrobat 9で結合してる。結合したときに自動的に作成されるしおりは結合を繰り返すと階層化されるけど、それも有効。
目次(PDFでいう「しおり」。タイトルの次くらいにある目次ページとは異なる)を開くのに 3ステップ必要なのは大いに不満。本を読むあいだ俺が何度目次を見返すか知らんのか?ページ番号をタップしたときに表示されるメニューに目次へのボタンが欲しい。しおりの存在を知らせるためにタップする前からステータス領域に目次アイコンを表示しておいてくれてもいいくらいだ。無効なページ番号へのジャンプは末尾のページへ移動するという。ページ 0は先頭のページでなく目次を意味するのでもよかったんじゃないか?先頭のページは 1ページに決まってるんだから。なんにせよ、目次へのショートカットが欲しい。
ページスライダーにブックマークや注釈の存在を示すアイコンが欲しい。
左上の戻るボタンは遠いし小さい。ハードウェアボタンで代替することもできず使いにくい。使用頻度の高いボタンがこれじゃあ。面倒くさいからいきおいホームボタンを押す回数が増える。ホーム画面で一番よく使うのは書籍一覧という横一線の小さいメニュー(書籍一覧の並び順は閲覧履歴順にした。ここの並び順は記憶してくれる。このビューがホームに欲しかった)。やれやれだぜ。使いにくいったらない。
PNG 4bit? 8bit? E-Inkの画面(Pearl)のスペックは 16階調グレイスケールなんだけど、4bit PNGと 8bit PNGの見分けはつく。ChainLPより Readerに任せた方がキレイだということ? ChainLPで変換した 4bit PNGは白黒二値画像に近い印象。線はシャープだし面はくっきりしてるが同時にざらついた感じがして奥行きに乏しい。8bit(実際の表示は 16階調になってる)はグレイスケールっぽく、色調が淡くなって少ししまりがなくなる。でもなめらか。ファイルのサイズが 40%くらいになるので 4bit PNGにする。
自炊書籍フォーマットは PDF? LRF? 左綴じ右綴じが影響しうるのは、1.スワイプの向き。2.ページ送り(戻し)ボタン。3.ページバーの始点と終点。の 3か所。表にする。
ページ送り(スワイプ) | ページ送り(ボタン) | ページバーの始点(1ページ目) | |
---|---|---|---|
横書き、全ての PDF | 設定により左か右向き | 左から二番目のボタン | 左端 |
縦書き | 設定により右か左向き | 左から二番目のボタン | 未確認 |
LRF(右綴じ)⁑ | 右向き | 左端のボタン | 右端 |
ケイオスである。どうしてこうなった。対応を表明していない LRFの挙動が一番もっともらしい。スワイプの向きとページの始点の位置は連動させてもらいたいものだが、それができてるのは LRFだけ。ハードウェアボタンに関してはヘルプに「ページをめくるときのスワイプの向きは、設定で変更できます(128ページ)。なお、< >(ページめくり)ボタンの動作は変更されません。」と書かれていて、これはこれで好ましいと思ってる。だからハードウェアボタンの挙動が変わって欲しくないという理由で、LRFでなく PDFを自炊本に全面的に採用することにした。Alt+→はいつでも進むで、Alt+←はいつでも戻る、というのと同じ感覚。1ページ目の表紙画像だけ見せられてもどっちむきにめくったらいいのかわかりませんから。ただし PDFと Readerによる読書体験が紙の本に近づいたら、ハードウェアボタンの挙動もスワイプと同じく切り替わるのが自然と感じるかもしれない。
スリープ運用が面倒。Kindleのように使用方法を表示したまま購入者に発送したりできないのはタッチセンサーがあるからではないのか。スリープはタッチセンサーを切るためにあるのではないか(嘘。Kindleにもスリープはある)。バッテリーの減りに大した影響がないのならスリープには一切しないつもり。
省エネ設定もオフだ。携帯電話のバックライトがすぐに暗くなるのって煩わしいし目障りでしょう。クラムシェル型のケータイは使わないときは閉じる、閉じてなければ使ってるというのが明確だから、バックライトができるだけ長いこと点いてるように設定してる(それでも一定時間で暗くなる!)。話が逸れた。10分でスリープに移行する(そして 2日でシャットダウンする)という、ふとした拍子に届いてしまいそうな近くにタイムアウトが存在していることが俺には耐えられない。そういうときっていうのは集中してるとき(あるいは寝てるとき……)なんだから邪魔されたくないし、そういう懸念を頭に置いて集中することもできない。
6月と 7月にあったアップデートは未適用だった。ファームウェア?なにそれ?って人は無視できないくらい存在してると思うけどな。気がきかない。
余白カットなんかのページモードを記憶しないのはひどいね。PDFビューアとして使えない。
スライドショー。画像のスライドショーはあるが、自動ページ送りはない。マンガだったらページあたりの時間はわりと均等で予想もつくし、少し待てばページが切り替わることがわかってるならいちいち手をのばす必要がない。トイレや食卓で Readerを握りしめる必要がなくなることの意味は大きいよ。
(内容にもかかわらず)今日のこの文章の長さで Sony Readerにわくわくしてることが伝わったでしょうか。