Open Packaging Format (OPF) 2.0.1 v1.0(http://www.idpf.org/epub/20/spec/OPF_2.0.1_draft.htm#Section2.4) の
The spine element must include the toc attribute, whose value is the the id attribute value of the required NCX document declared in manifest (see Section 2.4.1.)
あたりが問題のようです。 以下のように単純に書き換えるだけで、Kindle PaperwhiteやKobo Touchなどで目次が使えるようになります。
初期不良のKindleを新品交換すると、延長保証に入れなくなる
というのが今回のお話でして、実際に僕が体験したことを書こうと思います。
Paperwhite届いた URL
いろいろ触っていると、画面に輝点というか、ディスプレイ内に金属片のようなものがあり、バックライトが反射して常に眩しく光っている感じだったのです。電話をし、返品をお願いしました。そして交換品が届き…
Kindle Paperwhiteを良品と交換してもらったせいか、延長保証に入れないっぽい表示になっている。休み明けに問い合わせよう
Paperwhiteの延長保証に入れない件、Amazonに電話しておいた
2013-05-09 10:16:34 via web
再び電話で問い合わせ。調査後、メールで結果を報告してもらうことに。
電話をした次の日にメールが届きました。
Kindle Paperwhiteを新品交換すると延長保証を追加できない件 "交換させていただきました端末には新たに購入した延長保証を紐付けることができないとの回答がございました。お客様のご期待に沿う返答とならず、誠に恐れ入りますが、ご容赦いただきますようお願いいたします。"
以下、メールを抜粋したもの
XXXX様
Amazon.co.jpにご連絡いただき、ありがとうございます。
このたびは、当サイトのご利用に際し、ご不便をおかけいたしましたことをお詫び申し上げます。
今回の延長保証を購入できない件につきまして確認させていただきましたところ、交換させていただきました端末には新たに購入した延長保証を紐付けることができないとの回答がございました。
そのため、お客様にご注文を進めていただきました際にエラーの表示がされたかと存じます。
お客様のご期待に沿う返答とならず、誠に恐れ入りますが、ご容赦いただきますようお願いいたします。
Amazon.co.jpのまたのご利用を心よりお待ちしております。
素早いレスポンスと正直な回答はGoodなのですが、改善策などは提示されず。ええーと思いつつ、仕方なく新しいものを注文しました。
新しく買い直したKindle Paperwhiteも延長保証の対象にならない感じなのかな。表示が変わらないんだが…
どうやら一度でも新品交換しちゃうと、その後購入したぶんにも延長保証を追加したりできないみたい…？
普段から語学やプログラミングに関するわりと分厚い本を読まねばならないことが多く、なんとかソファーや机で読んでいたんですが、どうもムリがあると感じていました。というのもアイツらは平気な顔して馬鹿でかい空間を専有するんですよね。 ブックスタンド
を使っても数冊広げれば机の上はそれでもういっぱいなわけです。紙と鉛筆を広げるスペースと食い合うんですよ。ブックスタンドを使うと多少はマシですが、今度はディスプレイを見る邪魔をする。机の上に置いてあるディスプレイの下の方が見えなくて、椅子から腰をあげて紙の上にキーボードを置いて作業をするとか…。何かが根本的に間違っている気がしました。
また、ソファーでの読書も限界が迫っていました。ふとした拍子に手首を痛めてしまい、弱ったところに数百グラムの荷重がかかるわけです。iPhoneですら持ちたくないのに、数百グラム。さすがに耐えられませんでした。結果としてこれが最後の一押しになり、自炊に挑戦して見ることにしました。
紙の本をバラバラにしてデータ化するにはちょっと躊躇いがありました。別に作者様に申し訳ないとか、本を焼くとは何事だとか、そういった理由ではなく、単に読み終わった後に古本屋さんに売りに行くことができなくなるからです。物の価値というのは買値と売値の差額です。売れなくなるというのは、買値がそのままトータルコストになるわけで、僕のような貧乏暮らしをしている人にとってかなりの痛手になります。そこで、とりあえず手元に置いておくことが決まっている本
を自炊してみることにしました。 もちろん高級な自炊対応スキャナやカッターを僕は持っていませんので、自炊代行サービスに依頼しました。辞書タイプの本なのでジェットスキャンがベストなようでした。申し込み後、本を発送して、届いた本見積もりが以下のようなものです。
■お申込み内容
『 スタンダードスキャニングプラン 』
[オーダー内容] カット＋スキャン＋ＯＣＲ
[納期プラン] かっとびプラン
[解像度] 600dpiグレー
[圧縮率] 低圧縮
[カバースキャニング] 有り
[ファイル名書換え] 有り
[書籍の処分] ジェットスキャンで処分
[納品プラン] データ送信
[グレー割引] 希望 ［１０％値引き］
◆=====================================◆
[最終お見積金額] 2,394円です。
◆=====================================◆
■内訳
[８５１Ｐ～１０５０Ｐ] 1冊 @630円 小計 630円
[ご依頼冊数合計] 1冊
■追加オプション
[内：OCR加工冊数] 1冊 追加@105円 小計 105円
[内： 辞 書 ] 1冊 追加@1,050円 小計 1,050円
[ 解像度追加料金 ] 1冊 追加@315円 小計 315円
[ 圧縮率追加料金 ] 1冊 追加@105円 小計 105円
[作業料金] 2,205円
■納品方法
[かっとび追加料金] 315円
[データ送信料金] 105円
[合計金額] 2,625円
[割引料金] -231円 [割引率10％ ]
[最終お見積金額] 2,394円です。
これに加えて送料はこちら持ちですので、おおよそ3000円ほどかかったことになります。出来上がったものはデータで納品されます。僕の本は一日かけて運ばれ、バラバラになり、一枚ずつ丁寧に白い光で焼かれ、
現代英文法講義＿安藤貞雄.zip
になりました。解凍すると中に700MBぐらいのPDFファイルが入っています。
結論から述べますと、600dpiはかなりオーバークオリティです。しかし一生使うことを考えると、あるいは丁度よいぐらいなのかもしれません。OCRオプションは完璧ではありませんが、まずまずの精度です。現時点では完璧な結果を追求することは難しく、将来的に自炊代行サービスでのOCR精度を超えるものが、家庭で簡単に付加できるようになる時代を待たなければならないでしょう。
英文混じりの日本語なので難易度が高いです。ぼちぼちな精度ですが、AcrobatでOCRをかけるのと大差はありません。手元にAcrobatがあるならあえてOCRオプションを選択する必要はないかもしれません。
及第点でしょう。英文の中のスペースが認識されていないのが難点です。
えっ これさいしんばんあくろばっとですよね えっ
PDF化した結果、PC、iPhone、タブレット、E-INK端末など、様々なデバイスから本にアクセスできるようになりました。特にKobo Touchは専用端末として活躍しています。軽く、バッテリーも長持ち、さらに紙のような視認性で、ソファーで読むための最高の選択肢です。PDFからEPUBに変換し、見出しを詳細に打つことで、目的のページを探す速度も十分に高速です。外出中にふと文法について疑問を感じても、手元のiPhoneでサクッと調べることができます。PCで英文を書いているときも、PDFを隣に開いておけます。僕のお気に入りのこの本は、紙の本というハードウェアから開放されたことで、より深く僕と繋がったと感じます。どこにいても、どんな姿勢でも、さっと手に取れるこの感覚は新しくて、すごく安心するものです。未来人はきっと、紙の本に対して不安を覚えるに違いありません。
今回の試みは大成功といえると思います。しかし、まだ一冊です。僕の机にはまだまだ山のような本があり…。これらが全て天国へ旅立つとき、僕の机は（そして僕の財布も！）新しい時代を迎えるのかもしれません。
の評判がよいらしく、ボキャビルに使ってみようかなぁと考えたが、紙の本をボキャビル教材にするのはすごく敷居が高い。自炊代行に頼んで、Acrobatからコピペして…とそれを数万回も繰り返す頃にはきっと世紀が変わっている気がする。よし、僕は何も見なかった。といったん忘れていたところにこんなものを発見した。
なんと第2版から「動詞を使いこなすための英和活用辞典」を収録しているらしい。発売されてからずいぶん経つのにEpwingなどへ変換したという報告が皆無（第1版用のスクリプトでは失敗するという報告は見た）なのが怖かったが、とりあえずポチって解析をしてみることにした。
さて、それが数週間前のこと。届いてからしばらくしてようやく時間ができたので、さくっとインストールを済ませ、それらしいファイルを開いて…いや、僕の目grepスキルは小学生よりやや高いぐらいのレベルなんだけれど…う～ん、これは…
というわけで完成したのでここにおいておきます。
https://bitbucket.org/rubyu/edic2conv
僕以外にも泣いてる人多数。
http://synergy-foss.org/spit/issues/details/3338/
ソフトウェア的に下のウインドウに切り替えようとしてみたり、
https://gist.github.com/3992720
Bluetooth経由でなんとかしようかと思ってみたりしたけど、
http://www.mulliner.org/bluetooth/xkbdbthid.php
よく考えたらAlt+Esc（下のウィンドウへ切り替え）とAlt+Shift+Esc（上のウィンドウへ切り替え）という手段があって、これをマウスのボタンにそれぞれ割り当てたら効いた。
Win9でこれも無効化されてたらディスプレイに右手ぶち込んで切り替えてやる
思ったほど（あと体感ほど）スコアに差はなかったが、XPくんは放っておくとどんどん重くなっていって再起動が一定間隔で必要だったりアカン子。余っているライセンスはこの際ぜんぶWindows8にアップグレードしてしまうのがいいのかも…？
| Model | CPU | Memory | HDD | OS |
|---|---|---|---|---|
| HP ML110 G7 | Celeron G530 | ECC 2GB x 2 | WD30EZRX x 6 | Scientific Linux 6.3 x86_64 |
virtioは不安定なため使用しない
# virt-install \ --name xp \ --ram 2048 \ --vcpus 1 \ --os-type windows \ --os-variant winxp \ --hvm \ --virt-type kvm \ --disk vol=images/xp,cache=writeback \ --disk /path/to/WindowsXP-SP3.iso,device=cdrom \ --vnc \ --vncport 5900 \ --vnclisten 0.0.0.0 \ --keymap ja \ --network bridge=br0
# virsh vcpupin winxp 0 0
# virt-install \ --name win8 \ --ram 2048 \ --vcpus 1 \ --os-type windows \ --os-variant win2k8 \ --hvm \ --virt-type kvm \ --disk vol=images/win8,bus=virtio,cache=writeback \ --disk /path/to/Windows8-ReleasePreview-64bit-Japanese.iso,device=cdrom \ --disk /path/to/virtio-win-0.1-30.iso,device=cdrom \ --vnc \ --vncport 5901 \ --vnclisten 0.0.0.0 \ --keymap ja \ --network bridge=br0,model=virtio
# virsh vcpupin win8 0 0
------------------------------------------------------------------------------
CrystalMark Result
------------------------------------------------------------------------------
Display Mode : 1024 x 768 32bit (ClearType)
CrystalMark : 103189
[ ALU ] 9989
Fibonacci : 3376
Napierian : 2181
Eratosthenes : 1577
QuickSort : 2833
[ FPU ] 12840
MikoFPU : 1129
RandMeanSS : 7421
FFT : 2406
Mandelbrot : 1862
[ MEM ] 18172
Read : 5936.97 MB/s ( 5936)
Write : 5979.13 MB/s ( 5979)
Read/Write : 3741.58 MB/s ( 3741)
Cache : 24941.83 MB/s ( 2494)
[ HDD ] 33377
Read : 306.85 MB/s ( 7034)
Write : 234.13 MB/s ( 6341)
RandomRead512K : 544.13 MB/s ( 8220)
RandomWrite512K : 89.49 MB/s ( 3579)
RandomRead 64K : 243.45 MB/s ( 6434)
RandomWrite 64K : 44.23 MB/s ( 1769)
[ GDI ] 9340
Text : 2526
Square : 1963
Circle : 3661
BitBlt : 1190
[ D2D ] 17948
Sprite 10 : 692.92 FPS ( 69)
Sprite 100 : 627.67 FPS ( 627)
Sprite 500 : 457.10 FPS ( 2285)
Sprite 1000 : 334.26 FPS ( 3342)
Sprite 5000 : 111.48 FPS ( 5574)
Sprite 10000 : 60.51 FPS ( 6051)
[ OGL ] 1523
Scene 1 Score : 1456
Lines (x1000) : ( 183960)
Scene 1 CPUs : ( 32)
Scene 2 Score : 67
Polygons(x1000) : ( 477)
Scene 2 CPUs : ( 1)
------------------------------------------------------------------------------
CrystalMark Result
------------------------------------------------------------------------------
Display Mode : 1024 x 768 32bit (ClearType)
CrystalMark : 107585
[ ALU ] 12837
Fibonacci : 4639
Napierian : 2453
Eratosthenes : 2010
QuickSort : 3713
[ FPU ] 11527
MikoFPU : 1125
RandMeanSS : 6138
FFT : 2391
Mandelbrot : 1851
[ MEM ] 18250
Read : 6047.52 MB/s ( 6047)
Write : 6032.33 MB/s ( 6032)
Read/Write : 3686.27 MB/s ( 3686)
Cache : 24635.21 MB/s ( 2463)
[ HDD ] 50012
Read : 1648.89 MB/s ( 13744)
Write : 146.59 MB/s ( 4931)
RandomRead512K : 1758.64 MB/s ( 14293)
RandomWrite512K : 152.33 MB/s ( 5046)
RandomRead 64K : 561.39 MB/s ( 8306)
RandomWrite 64K : 92.31 MB/s ( 3692)
[ GDI ] 9995
Text : 3975
Square : 958
Circle : 2921
BitBlt : 2141
[ D2D ] 3580
Sprite 10 : 345.38 FPS ( 34)
Sprite 100 : 266.29 FPS ( 266)
Sprite 500 : 116.97 FPS ( 584)
Sprite 1000 : 68.31 FPS ( 683)
Sprite 5000 : 19.53 FPS ( 976)
Sprite 10000 : 10.37 FPS ( 1037)
[ OGL ] 1384
Scene 1 Score : 1323
Lines (x1000) : ( 168501)
Scene 1 CPUs : ( 32)
Scene 2 Score : 61
Polygons(x1000) : ( 431)
Scene 2 CPUs : ( 1)
以下のようなスペックのマシンをセットアップしたのでメモ。
| Model | CPU | Memory | HDD | OS |
|---|---|---|---|---|
| HP ML110 G7 | Celeron G530 | ECC 2GB x 2 | WD30EZRX x 6 | Scientific Linux 6.3 x86_64 |
最近の大容量ディスクはみんなAFT。うまくパーティションを切らないとパフォーマンスが低下しちゃいます。さらに今回はRAID6上のLVM上のExt4（！）であることも考慮しなければなりません。といってもそれほど複雑なことを考える必要はなく、新しめのOSであればもうほぼデフォルトの設定で問題ないはずです。
今回は/bootと/と、ここで使うRAIDアレイ用のパーティションを分けることにしました。 このような場合は、パーティションが正しく切られているかが重要です。 1.00 MiB = 1,048,576 byteで、これは4096 byteで割り切れます。つまりMiB, GiB単位で分けておけばよいことになります。partedで以下のように簡単にパーティションを作成できます。
# parted /dev/sdX (parted) mklabel gpt (parted) mkpart boot 1mib 300mib (parted) mkpart system 300mib 40gib (parted) mkpart storage 40gib -0gib (parted) quit
LiveCDなどで作業をしてもいいですが、OSのインストーラを立ち上げた後、Alt + F2で仮想コンソールに切り替え、Alt + F6でインストーラに戻るのが簡単です。
ここで考える必要があるのは、metadata version、およびchunk sizeです。 metadataは --metadata 1.0 を指定して、Arrayの後方に配置します。chunk sizeはAFTのセクタサイズ、4KBの倍数になるようにします。
# mdadm --create /dev/md2 --metadata 1.0 --raid-devices=6 --level=6 --chunk=128 /dev/sd[abcdef]3
mdadm: array /dev/md2 started.
LVMではヘッダサイズが重要ですが、新しいOSではデフォルトで問題ない値になるようです。
# vgcreate VolGroup01 /dev/md2
No physical volume label read from /dev/md2 Writing physical volume data to disk "/dev/md2" Physical volume "/dev/md2" successfully created Volume group "VolGroup01" successfully created
# lvcreate -l 100%VG -n LogVol00 VolGroup01
でPVとVGとLVを作成し、以下のコマンドでヘッダサイズが適切かどうか確かめます。
# pvs -o+pe_start
PV VG Fmt Attr PSize PFree 1st PE /dev/md1 VolGroup00 lvm2 a-- 39.70g 2.59g 1.00m /dev/md2 VolGroup01 lvm2 a-- 10.76t 0 1.00m
1st PEが1.00mになっています。これは適切な値です。
ヘッダサイズを手動で設定するならば --dataalignmentオプションをpvcreateに渡します。データの開始がこの値の倍数になるので、ここではRAIDアレイのchunk sizeにしておくのがいいでしょう。
# pvcreate -M2 --dataalignment 128K /dev/md2
ここで考えるべきはblock size、stride、およびstripe-widthです。 block sizeは4096の倍数であれば適切です。 stride, stripe-widthは次の式で求められます:
stride = RAIDアレイのchunk size / Ext4のblock size stripe-width = stride * (RAIDアレイを構成するディスク数 - 2)
block sizeは4096にすることとし、ディスク数は6、chunk sizeは128なので、stride=32, stripe-width=128となりました。
# mke2fs -t ext4 -v -m 1 -b 4096 -E stride=32,stripe-width=128 /dev/VolGroup01/LogVol00
mke2fs 1.41.12 (17-May-2010)
fs_types for mke2fs.conf resolution: 'ext4', 'default'
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=32 blocks, Stripe width=128 blocks
722083840 inodes, 2888322048 blocks
28883220 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
88145 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
2560000000
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
さて、ここまでで、恐らくRAID6上のLVM上のExt4が適切な設定で作成されたはずですが、確かめてみなければなんとも言えません。 バーンインも兼ねて、ちょっと時間のかかるベンチマークを取ってみます。
の全通りに対して、以下の2種類のテストを行いました。
シーケンシャルリード、シーケンシャルライトは最大それぞれ400MB/s、450MB/s程度。十分な性能が出ているようです。もちろんこの場合はパフォーマンス最優先なので、その点には注意が必要ですが。
