表題のとおりですが、CotEditor 1.1が公開されました。
すばらしい! > CotEditor 1.1 をリリースしました
いちユーザとして素直に喜びたいです。 🙂
usami-k さん、お疲れ様でした。今後とも宜しくお願いします。
# 画像を貼ろうと思ったのですが、フォト蔵で障害が起きてるんですね…。
表題のとおりですが、CotEditor 1.1が公開されました。
すばらしい! > CotEditor 1.1 をリリースしました
いちユーザとして素直に喜びたいです。 🙂
usami-k さん、お疲れ様でした。今後とも宜しくお願いします。
# 画像を貼ろうと思ったのですが、フォト蔵で障害が起きてるんですね…。
わたしがやってるMac系のアンテナは30分毎にデータを更新してますが、下の方にスクロールしていると最終更新時刻が見えなくていちいち上まで戻って時刻表示を確認してからリロードするのが面倒でした。
何年か前からずっとその対策をしようと思っていて、やっと今日「リロード兼更新時刻表示ボタン」を付けました。Awesome CSS3 & jQuery Slide Out Button を参考に…というか、ほぼそのまま使わせていただきました。JavaScriptがオンなら左下に見えます↓。
soundscape outさん経由で「YouTubeを貼りつけるためのタグを生成するブックマークレット、YouTube2HTMLを修正しました。」との記事を拝見してスクリーンショットを見て、初めて、Safariのブックマークバーにフォルダを登録できることを知りました…。
今までは一つずつ登録してて項目が多いので横にはみ出してプルダウンしたりして、やりにくいなぁと思っていたんですよね。Firefoxではフォルダを登録してたのにSafariで同じことができると知らなかったのが、あまりに間抜けすぎます…。これって昔はできなかったですよね? もしかしてできてた?
で、気をとりなおして、上記のブックマークレットを使わせていただきました ↓。話題になってた動画です。
この動画のおかげで頭の中で「Change」がヘビロテ状態になってしまい、先日、iTunes Storeで購入してしまいました。 😀
先日マイコミジャーナルに掲載された記事【レビュー】ブラウザをメモリディスクを使って高速化する方法には各種プラットフォームのブラウザの高速化が駆け足で紹介されていますが、ちょっと問題があります。書かれた手順では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インチのマニュアルレビュー。
これはヒドイなぁ…。らしくない。
「置換スクリプト」を走らせるのをミスったんでしょうか。
先日のエントリで5月ごろにePubの日本語対応の新しい規格(ePub 3.0)が決定するとのことで、そこから始まるのかもしれません
などと書いたのですが、実装が進んでいることをコトハノオトの記事で知りました。
EPUB日本語拡張仕様策定により、ブラウザーでの縦書きが進行中
Webkit、Chrome 日本語縦書き表示
スクリーンショットを見ると、縦書きやルビなど各種実装状況にクラクラするほどの興奮を覚えます。「圏点」がうれしい。
期待してます。楽しみですねー。
# とか書いてますが、実は「圏点」って呼び方を初めて知りました…。「傍点」とは違うのかな?
先日書いた「MacにおけるePubビューワ・リーダー」ですが、エディタのiText Express(iTextではなくてiText Express)が対応しているのに気づいたので追記しました。
縦書き表示できるのがすごくいいです。ルビの表示が崩れるのが残念。
昨日のePubの話の続き。
↑ 画面ははめ込み合成(iPhone ScreenTaker使用)です。
電子書籍でなぜePubの方に興味が傾いているのかというと、ページが固定されているPDFは表示面積の小さいデバイス上では窮屈に感じるからです。ePubはhtmlベースだけあってテキスト主体の書類ではページが流動的で、それには「テキストの特定の位置をページ数で示せない」というデメリットもあるけれども、iPhoneでも無理なく読めます。文字を大きくして1ページ当たりの文章量を少なくすればいいからです。画像の場合は縮小されるので表示においてはPDFとの違いはありませんが、文章中心の書類では、ePubとPDFで体感はかなり異なると思います。
多分これが、mutaさんが問いつめられたとき↓の答えでいいんだと思います。ケースバイケースで使い分け、と。
電子書籍はもはやAppleの「黒船的外圧」で出版業界を再編の嵐に巻き込もうとしている。
それでもこんな時期になっても「電子書籍イコールPDF化した紙媒体」という思い込みが広く浸透していて、過日も私が
「電子書籍は単に紙をキャプチャーしたPDFやjpegではなくもっと違うものに、進んでいく筈」
といったところ
「なんでそんなムダなことをするの?紙なんだからPDFで充分じゃない?xmlにするんだったらホームページとどう違うの?」
と問いつめられて絶句してしまった。
ところで、昨日PDFはほぼ固まっている
と書いたのは「仕様が固まっている」という意味と「ページに対して固定されている」のダブルミーニングだったんだな…(と後で自分で気付いた)。どうでもいいことだな…。 😀
このところ急に電子書籍のePub形式に興味が湧いてきていろいろ調べてます。
そもそも表記が「EPUB」なのか「ePub」なのかよくわかりませんが、EPUB – Wikipediaだと項目としては「EPUB」で「epub」「ePub」などと表記される場合もある
とのこと。字面としては「ePub」がいいと思うので、そう書きます。
電子書籍の主な形式はPDFとePubで、それぞれ主にテキストが主体になるものと画像がメインになるものとに大別されるかと思います。わたしが気になってるのはePubのそれもテキストが主体となるものです。
PDFはほぼ固まっているし画像を表示する限りにおいてはあまり差異がないのに比べ、テキスト主体のePubはまだまだこれからです。
表示ソフトについてはMacでのePubリーダーが参考になりました。そうか、ePubは「ビューワ」というよりも「リーダー」がふさわしいのかもしれないですね。
見つかったのはこのようなところです。番外編でJavaScriptでEPUBビューアーを自作してみたという記事もありました。
現状ではどれも微妙な印象ですが、MacのePubリーダーとしてはSigilが(エディタであることを除けば)ベストでした。
MacでのePub閲覧は需要があまりないのかもしれないませんが、5月ごろにePubの日本語対応の新しい規格(ePub 3.0)が決定するとのことで、そこから始まるのかもしれません。 😀
# iPhoneではiBookや上記のSanzaということになるかと思います。