昨晩までのノドの違和感もようやく消え、やっと完治したと言えそうなところまで来ました。まるまる一週間ひいてました。風邪を引きやすい上になかなか治らないとは、ダメダメだなホントに…。なんども書いたり言ったりしてるけど、やはり基礎体力の低下が主因だろうな。あー、生活変えたい。
↑サッカー日本代表、おめでとうございます。オージーにはやられちゃうかと思いましたが、やってくれましたねー。 🙂
リアルタイムで見ようか迷ったんですが、自重しました。それでやっと風邪が治ったのかもしれません。
風邪、進行中…
喉の痛みは治まってきてそろそろ完治も近いかと思われた本日、突如として鼻水が溢れ出すという意外な方向へ。鼻の奥はじんわりとしびれるような感覚もあり、完全にぶり返した状態です。やっぱりちゃんと治るまでは油断しちゃいけません。 😕
↑これは夕方のテレビに写っていた「ヨーロッパクサリヘビ」
「ブラウザをメモリディスクを使って高速化する方法」が10.6+Safariではうまくいかない件
先日マイコミジャーナルに掲載された記事【レビュー】ブラウザをメモリディスクを使って高速化する方法には各種プラットフォームのブラウザの高速化が駆け足で紹介されていますが、ちょっと問題があります。書かれた手順ではMacOS X 10.6 + Safari 5では高速化されません。
掲載されているEsperance DV for MacはSnow Leopardでも動きますが、「Move Safari Web Cache disk on RamDisk.」も「Move Safari Icons Cache disk on RamDisk.」も機能していないからです。Esperance DV for Macは2006年のソフトで、対応OSとして10.3/10.3.9/10.4 PPC/Intel
と書かれているほど古いものです。当時はSafariのキャッシュは「~/Libray/Caches/Safari」にあったのだろうと思われますが、現在の5.xでは「~/Library/Caches/com.apple.Safari/Cache.db」がキャッシュデータベースファイルです。Iconsは今はどこにあるかわかりませんでしたが、もしかしたら同じ「Cache.db」に格納されているのかもしれません。
実はわたし、この記事を見てすぐにやってみたんです。おぉ、速くなった！とか思ってましたが、ふとどのぐらいのキャッシュを使っているのかRamDisk内をチェックしたところ全くファイルが生成されてなくて、設定しなおしたり再起動したり、いろいろやっちゃったんですよね…。で、どうもおかしいと詳しく調べてやっと記事が間違ってると気づいた次第です。速くなったと思ったのも完全なプラセボだったというね…。 🙁
たしかにRamDiskはちゃんとできているので「~/Library/Caches/com.apple.Safari/Cache.db」をRamDisk上に移せば速くなるかもしれませんが、単純なフォルダ内ファイルでなくてDBファイルですからちょっと怖くて試してません。
RamDiskのデータがちゃんと保存されるかも少し不安だったのでこれらの高速化はあきらめて、ノーマル状態に戻しました。
以上ですッ。
昨今の紙のマニュアル
トビフシコ氏によるMacBook Air 11インチのマニュアルレビュー。
これはヒドイなぁ…。らしくない。
「置換スクリプト」を走らせるのをミスったんでしょうか。
風邪？
またも風邪をひいてしまった模様。はげしくのどが痛いです。
いったい何回風邪をひけば気が済むというのか、嘆かわしい。この週末はコンビニ以外に外出していないのに、そこで拾ってきたんだろうか。とほほ。 😕
↑ これはTDRのおみやげで貰ったnano block。ニモです。
ePub縦書きをWebkitで表示する実装が進んでいる！
先日のエントリで5月ごろにePubの日本語対応の新しい規格（ePub 3.0）が決定するとのことで、そこから始まるのかもしれません
などと書いたのですが、実装が進んでいることをコトハノオトの記事で知りました。
EPUB日本語拡張仕様策定により、ブラウザーでの縦書きが進行中
Webkit、Chrome 日本語縦書き表示
スクリーンショットを見ると、縦書きやルビなど各種実装状況にクラクラするほどの興奮を覚えます。「圏点」がうれしい。
期待してます。楽しみですねー。
# とか書いてますが、実は「圏点」って呼び方を初めて知りました…。「傍点」とは違うのかな？
昼休みに飲んだ缶コーヒーです
iText ExpressはePubを表示できます
先日書いた「MacにおけるePubビューワ・リーダー」ですが、エディタのiText Express（iTextではなくてiText Express）が対応しているのに気づいたので追記しました。
縦書き表示できるのがすごくいいです。ルビの表示が崩れるのが残念。
WordPressプラグイン「W3 Total Cache」を導入したら…
昨晩のこと。
ふと、「WordPressでキャッシュを効かせたら表示が速くなるんじゃないか？」と思いつく
↓
W3 Total Cacheを導入してみた
↓
有効にするにはサイトのURL表記を変更しないといけないことに気付く
↓
変更してみた
↓
キャッシュは有効になった！ 速くなったような気もする！ 😀
↓
アンテナで更新時刻が取得できなくなってた… 😕
自分でやってるアンテナで自分のサイトの更新時間が拾えてないって、マヌケすぎます。
WordPressの場合はサイトのURLをなつみかん（アンテナのソフト）で見に行っても正しい更新時刻を返してくれないのでFeedをチェックしてたんですが、それがキャッシュのものだったため本来の時刻が取得できなくなってたのです。
あれこれ調べたけどわからず、結局Feedのキャッシュをあきらめることで何とか拾えるようになりました。
で、W3 Total Cacheですが、設定がかなりたくさんありローカライズもされてないのでどこか間違ってる可能性もあります。一通り見直さないといけないかも。
PDFよりePubがいいところ
昨日のePubの話の続き。
↑ 画面ははめ込み合成（iPhone ScreenTaker使用）です。
電子書籍でなぜePubの方に興味が傾いているのかというと、ページが固定されているPDFは表示面積の小さいデバイス上では窮屈に感じるからです。ePubはhtmlベースだけあってテキスト主体の書類ではページが流動的で、それには「テキストの特定の位置をページ数で示せない」というデメリットもあるけれども、iPhoneでも無理なく読めます。文字を大きくして1ページ当たりの文章量を少なくすればいいからです。画像の場合は縮小されるので表示においてはPDFとの違いはありませんが、文章中心の書類では、ePubとPDFで体感はかなり異なると思います。
多分これが、mutaさんが問いつめられたとき↓の答えでいいんだと思います。ケースバイケースで使い分け、と。
電子書籍はもはやAppleの「黒船的外圧」で出版業界を再編の嵐に巻き込もうとしている。
それでもこんな時期になっても「電子書籍イコールPDF化した紙媒体」という思い込みが広く浸透していて、過日も私が
「電子書籍は単に紙をキャプチャーしたPDFやjpegではなくもっと違うものに、進んでいく筈」
といったところ
「なんでそんなムダなことをするの？紙なんだからPDFで充分じゃない？xmlにするんだったらホームページとどう違うの？」
と問いつめられて絶句してしまった。
ところで、昨日PDFはほぼ固まっている
と書いたのは「仕様が固まっている」という意味と「ページに対して固定されている」のダブルミーニングだったんだな…（と後で自分で気付いた）。どうでもいいことだな…。 😀