2013/12/13(金)自炊を突き詰めてみた
2013/12/13 15:23
自分が妥協できるやり方で、どれだけ高速化・効率化できるかを突き詰めてみた。
所要時間
突き詰めた結果、こんな感じ。おおざっぱに、前処理 -> スキャン -> 後処理となり、
前処理: 人力
スキャン: 自動
後処理(操作・目視判定): 人力
後処理(自動): 自動
となる。
ページ数依存の時間
200ページ(背厚おおよそ10mm程度)ごとに、5分(スキャン:4分, 後処理(自動):1分)冊数依存の時間
1冊ごとに、3~4分(前処理(裁断・タイトル作成):2分, 後処理(操作・目視判定):1分)その他ミスによって生じるロス時間
ミス1回ごとに、だいたい10分。(ミスのほとんどは、スキャン時に発生。紙サイズ自動判定のミス、ノリ残りによる給紙ミス、紙質混在による給紙ミスがほとんど)
モデルケース
[a]週刊少年誌2冊 = 50mm = 1000ページ => 5分 * 5 + 3分 * 2 = 31分[b]薄い本15冊 = 50mm = 1000ページ => 5分 * 5 + 3分 * 15 = 70分
こんな感じ。正直集中力が続かないので(特に冊数が多い場合)、実作業時間はこれに1.2~1.5掛けになるが最大効率だとこの数字になる。
複数の本を対象にまとめて作業すれば、パイプライン化によって前処理とスキャンを同一時間に行うことは可能(ただし、本当にかかりっきりになる)。
方法
自分のやり方をざっと書いておく。機器構成的には以下のような感じ。
・中国製裁断機(XD-3203A)
・Fujitsu fi-6130
・PC(Core-i5 2500K, 16GB, HDD)
前処理
自炊する対象を決める
最終的にはこれが一番重要。とっとくか、捨てるか、自炊するか即断。裁断
使用している裁断機(XD-3203A)は精度が低いのでちょっとした工夫・コツがいる。突き当ての遊びが大きく垂直が出てないので、突き当てをちょっと刃側に寄せて位置合わせをする。
裁断面が斜めにならないように(特に厚い本で斜め切りになりやすい)、紙押さえ下部と紙押さえの接地部にゴムシートなどの滑り止めを貼っておく(参考: 漫画をスキャナで電子書籍化する初心者向け自炊解説サイト 裁断機で斜めに切断・切れないようにする解決方法)。紙押さえを強く押し下げたあと、ちょっと緩めて押し下げるを何度か繰り返す。さらに裁断時にも左手で紙押さえを押し下げながら裁断する。
ここまでやってもほどほどの精度なので、裁断機は良いもの(自炊裁断機200DXなど)を使った方がよい。
チェック
裁断した束を、スキャナまで移動する間に、以下のことをチェックする。[1]特殊サイズ・特殊紙がないか
[2]くっついているページがないか(特にカラーページ・表紙の周り)
[3]ノリが大きく残っていないか
[1]に該当する場合、スキャナに通るかどうか考える。通らないのであれば追加で裁断をするか、フラットベッドで取り込むか、スキャンを諦めるか決める。
[2][3]に該当する場合、剥がして手当てする。
タイトル作成
本タイトルor誌名、お好みで著者・サークル名・出版社・出版年・ジャンルなどをテキストエディタで作成する。出版された書籍のみを扱うのであれば、バーコード読み込みからタイトルを自動生成するスクリプトなどを生めば効率が上がるかも知れない。
ただし、amazon DBはかなりの表記揺れがあるため、シリーズでタイトル揃えるといった要望を満たせないかも。古い本ではバーコードがなかったり、JANコードがDBになかったりということもある。amazonを万能とは考えないこと。
私は秀丸で、項目(ジャンル, 著者, タイトル)をタブ区切りにしたファイルを作り、マクロでクリップボードへコピーまでやっている。
//一般的な書籍タイトル名を生成するマクロ movetolineno 1, 3; deleteline; movetolineno 1, 2; beginlinesel; copy; paste; //著者名有り replacedown "([^\\t]+)\\t([^\\t]+)\\t([^\\t]+)\\t([^\\t]+)", "(\\1) [\\2 (\\3)] \\4", regular; if(result == 0){ //著者名無し replacedown "([^\\t]+)\\t([^\\t]+)\\t\\t([^\\t]+)", "(\\1) [\\2] \\3", regular; } if(result == 0){ //団体名・著者名無し replacedown "([^\\t]+)\\t\\t\\t([^\\t]+)", "(\\1) \\2", regular; } movetolineno 1, 3; beginlinesel; copy;これを、以前のBTScanTool(AutoIt!でBTScanをちょっと改良 - 色々日記(ざ・めも))にCtrl+A, Ctrl+Vして、フォルダ名をBTScanにセットする。
BTScanの入力開始ボタンを押下して、フォルダを作成。
スキャン
fi-6130の給紙枚数はだいたい10mmくらいまでなのでそれくらいごとにスキャナに通す。このとき、摩擦が少ない紙(カラーページなど)はセット時の束中で一番最後に取り込むように区切るとミスが少ない。fi-6130の給紙能力は素晴らしく優秀だが、紙質混在原稿ではミスをすることがあり、摩擦が大きいページを先に吸ってしまうことがある。
原稿をさばいて、先に給紙するものほど奥に入るように若干斜めにセットする方がミスが少ないのはプリンタと同じ。
スキャナが止まってから束に割ると効率が落ちるため、作業スペースを確保して先に全部束に割ってしまう方がいい。少なくとも次にセットする束は準備しておくと効率がよい。
スキャンは、BTScan + fi-6130(TWAIN)で行う。
基本的に全て両面、300dpi, カラー, bmp, 自動用紙サイズ検出、4桁1始まり連番でスキャン。
特殊紙は都度単体でスキャン。
自動用紙サイズ検出に失敗したケースでは、黒背景でB5,A4等の規定サイズでスキャン。
コミック等表紙については、長尺で取り込めるものについては横向き長尺でスキャン。
現状、BTScan以上に優秀なソフトがないのだが、BTScanはプロファイルを自動更新してしまうなど使い勝手が悪い。スキャンパートは実時間依存大であり、手戻りが多大なロスになるため極力どんな本でも同じ設定で出来るようにすること。BTScanのプロファイルは信用しないこと。
なお、fi-6130含むfi系のTWAINドライバは1枚スキャンするごとにフォーカスを持って行く。これだとスキャン中は他の作業が出来ないため結構きつい。APIフックで何とかする方法はあるのでfi-6130のTWAINがフォーカスを取るのを抑止する - 色々日記(ざ・めも)を参照。
後処理
自作スクリプトとZoner Photo Studio 15, RalphaPlus, SpringM等を駆使する。サイズ取得
スキャンしたフォルダで自作Rubyスクリプトを実行し、最小サイズと全体のずれを取得する。$KCODE = "Shift-JIS" require "rubygems" require "image_size" require 'win32/clipboard' max_width = 0 min_width = 99999 max_height = 0 min_height = 99999 Dir.glob("*.bmp"){ |f| open(f, "rb"){ |fp| img = ImageSize.new(fp.read) if max_width < img.width then max_width = img.width end if max_height < img.height then max_height = img.height end if min_width > img.width then min_width = img.width end if min_height > img.height then min_height = img.height end } } width_diff = ((max_width.to_f-min_width)/max_width*10000).round.to_f/100 height_diff = ((max_height.to_f-min_height)/max_height*10000).round.to_f/100 param = "W/2-#min_width/2,H/2-#min_height/2,#min_width,#min_height\n" output = "" output += "w:#min_width-#max_width #width_diff%ずれ\n" output += "h:#min_height-#max_height #height_diff%ずれ\n" output += "\n" output += param open("c:\\**documents**\\ralpha_trimming_param\\ralpha_trimming_param.txt", "w"){ |wp| wp.write output } Win32::Clipboard.set_data(param) IO.popen "c:\\**program**\\hidemaru\\hidemaru.exe c:\\**document**\\ralpha_trimming_param\\ralpha_trimming_param.txt"適当に書いたのでメチャクチャ。実行すると、秀丸が立ち上がってこんなのが出る。
w:1642-1658 0.97%ずれ h:2041-2045 0.2%ずれ W/2-821,H/2-1020,1642,2041プロンプトでやると閉じ忘れたときに一手間増えるので敢えて秀丸に出力する(スキャンフォルダを削除するときに「使用しているアプリケーションがあるため~」となる)。
最後の1行はRalphaPlusに投げるためのパラメータ。自動的にクリップボードにコピーされている。
ずれが2%を超えているケースは、スキャン時に何かが起こっている可能性が高いので見直しをかける。
目視チェック
サイズ取得と並行して、Zoner Photo Studio 15を立ち上げる。Zoner Photo Studioは起動ディレクトリを指定できないので、AutoIt!で起動ディレクトリを渡してやる。$Title = "Zoner Photo Studio 15 FREE" Run("C:\\**program**\\Zoner\\Photo Studio 15\\Program64\\Zps.exe") WinWaitActive($Title) WinActivate ( $Title ) ControlClick ( $Title, "", 100 ) ClipPut($CmdLine[1]) Send("^VENTER")このAutoIt!のスクリプトにディレクトリ名を引数として渡してやると、Zonerを立ち上げたあとにそのディレクトリに移動してくれる。
ここで、カラーページを選択しRalphaPlusにD&D。Zoner上にいったん戻り、次の作業のためにCtrl+Iして選択を反転。
bmp->jpg(カラー)
ここから先はRalphaPlusでの処理。プロファイルをカラーに切り替え、トリミングのパラメータに"X座標、Y座標、幅、高さ(px)"指定でクリップボードのデータをCtrl+Vする。
カラープロファイルでやっているのは
・レベル補正
・トリミング
・リサイズ
・アンシャープマスク
・ノイズ除去
F5で実行。Ctrl+Delでクリア。
bmp->jpg(モノクロ)
再度、Zonerに戻って現在選択されているファイルをもう一度RalphaPlusにD&D。プロファイルをモノクロに切り替え、トリミングのパラメータに"X座標、Y座標、幅、高さ(px)"指定でクリップボードのデータをCtrl+Vする。
モノクロプロファイルでやっているのは
・グレースケール化
・レベル補正
・トリミング
・リサイズ
・アンシャープマスク
・ノイズ除去
適当なページを選んで、レベル補正のみ確認する。
裏移りが極端に酷い場合、若干白飛ばしを強めにする。
薄いグレースケール・トーン飛びが酷い場合、若干白飛ばしを弱めにする。
F5で実行。
bmp移動
現時点で、スキャンフォルダにbmpとjpgが混在しているため整理する。スキャンフォルダで、backフォルダを作成しbmpファイルをそこに移動するスクリプトを実行。
$BACKUP_DIRNAME = "back" if not File.exist?($BACKUP_DIRNAME) then Dir.mkdir($BACKUP_DIRNAME) end Dir.glob("*.bmp"){ |file| File.rename(file, "back/" + file) }
チェック
Mangameeya等のビューアでざっと後処理したjpgをチェックする。削除
チェックして問題無ければ、bmpの入ったbackフォルダを削除。圧縮
Zoner等がまだひらいていれば閉じるWinRARにスキャンフォルダをD&Dして無圧縮・リカバリレコード付きで圧縮する。
これにて完了。
今後の高速化
スキャンデータストレージとしてHDDをRAMディスク or SSDに変更
スキャン周り・後処理について高速化が期待できる。RAMディスクの場合、今のやり方ではまとめて作業すると簡単に使い切ってしまうのと後続作業を後日に回したいときがネックか。
SSDは効用次第だが、このためだけに導入するのは疑問。
BTScanの上位互換ツールの発見 or 開発
BTScanがもうちょっと使い勝手が良ければ、スキャン時に特殊紙・カラーを選り分ける、jpegでスキャンするなどをした方が効率が上がる可能性がある。現状のBTScanでこれをやると、プロファイル仕様の問題でどうしてもミスが増える。可読性を多少犠牲にする
モノクロとカラーで後処理を分けているが、これを一本化すればかなり人力判定・操作コストが減る。ただし、モノクロページはやはりグレスケ化した方が綺麗ではあるのでどこまで割り切るか。機器の更新
CPUについては、高速化すれば当然後処理が多少早くなる。とはいえ抜本的な改善はintel CPUでは2015年のSkylake待ちである。AMD GPGPUが進めば面白いが…?ドキュメントスキャナについては、fi-6130でも既に準業務機という位置づけなのでこれより早いスキャナはなかなか手に入るような価格では出てこないとは思うが、なにがしか技術革新があるかも知れない。
裁断機については、ダーレ200DX等に変えることで(裁断可能厚そのものは減少するが)、垂直性や斜め切りが改善できるならば結果的に効率化できる可能性がある。
総括
自炊は時間と空間のトレードである。使われる時間はなんら生産的でも文化的でもないため、とにかく辛い。人には絶対勧めない。入手性が高い本であれば手放してまた読みたいときに買い直すも良し、電子版があるならそれを買うも良し。
トレード対象になる時間を鑑みて、本当にその価値があるか考えるようにしたい。特にコミックには手を出さない方が無難。20分で読める本の自炊に最速8分かかるということを肝に銘じる必要がある。解像度が低かろうが、カバー裏が収録されて無かろうが、Kindleがあればもうそれでいいじゃない。amazon万歳。
赤松先生が以前提唱していた、電子化されてない本をアップしたら、版権取りと電子書籍販売まで代行してくれるサービスがあったらいいのに……
2013/11/27(水)電子書籍雑感
2013/11/27 11:08
一応一通りショップ調べたけど、汎用性のKindleと画質のebookJapanという構図でよさそう。
[参考]
週刊少年ジャンプデジタル版の画質をKindle版とeBookJapan版で比較してみた : 見て歩く者 by 鷹野凌
電子書籍の情報をまとめてみる
以下、個人的な使い方とあれこれ考えたことを書き連ねる。
私個人としては、マンガと小説を徐々に電子書籍にシフトしたいという感じ。重くてかさばる技術書や技法書を移行するのが一番いいのだが、課題が結構ある。
・現在の電子書籍(和書)はほぼ全てがDRMあり
・DRMありである以上、読書アプリは固定
・ほとんどの読書アプリがサムネイル表示機能を有しない。ページ移動や動作が重いものも多い。
好きなところから読んだり、ぱらぱらめくって興味を探す的な用途には酷く向かない。他方、先頭から連続的にしか読まないようなデータ、特に小説類では現在の電子書籍でもそこそこの満足が得られそうだ。
将来的に、DRMが無くなってepubやpdfでの提供になればユーザは好きに高機能な読書アプリを選択できる。
DRMが無くなってもフォーマットコンバート手段が出てこない可能性はあるが…… ま、メジャーなものについては誰かが何とかするだろう。たいていのものはepubをDRMの皮でラップしたものだろうし。
DRMフリーのものについては好きにフォーマット変換するのは当たり前のようだ。下のアプリケーションなどが有名どころ。
calibre - E-book management
さて、私が毎号買っている月刊アフタヌーンが電子書籍化した。
1000ページ級の巨人漫画誌アフタヌーンがスマホ&PCで毎月読める「アフタヌーン電子版」配信開始! - アフタヌーン公式サイト - モアイ
大手のコミック誌が継続的に電子書籍を発行するようになったのは一つのマイルストーンと言えるだろう。
アフタヌーンはかさばるわ重いわで電子書籍化のメリットが大きい。電子書籍という物を理解するにもいい素材と判断して移行を決断。なにも考えずに、メジャーどころのKindleで買ってみた。
Kindle版はぶっちゃけ解像度が低い。フキダシは読めるが、ルビやマンガ以外の記事はかなり苦しい。Kindleアプリの最大拡大率が低いこともあって今私が使用しているデバイスではマンガ以外の記事はちょっと読めない。
参考サイトにもあったがebookJapanの方が画質はずっと良さそう。
アフタヌーンではKindle版181.0MBに対して、ebookJapanは238.4MBである。この容量差がそのまま解像度に換算されていれば、縦横それぞれ1.15倍程度の差がありそうだ。
Android Kindleアプリは使い勝手が悪い。
最大拡大率が小さい、サムネイル表示が出来ない、ページジャンプまわりのI/Fが奇っ怪。
良いところもある。複数の端末で最終ページを同期できるのは実本よりも便利だろう。
トータルでは、最初から最後へ読み進めるタイプの本(小説とか)で、文字データならかなり良さそうではあるが、画像タイプの本では不満の方が多い。
一方ebookJapanはというと、使い勝手が聞くだに厳しい。電子書籍を保持できるのは常に1端末。別の端末に移すにはいちいちebookJapan経由で書籍を"トランクルーム"に返す必要がある。とてもやってられそうにない。買って比較するのが正しいのだが、ちょっと意欲が湧かなかった。
どちらを軸にするかを考えると、まあ使い勝手でKindleかなと。
将来的にDRMが無くなるか緩くなってくれば、解像度が高い側で買い直すということは考えられる。
あるいは解像度アップや複数データサイズからの選択制に踏み切る電子書籍書店が出て来るかもしれない(一応amazonに解像度アップの要望は出した)。
どうせ数年内にKindle for PC(日本版)が出て来ると思うので、そこら辺で状況が変化してくると思う。
どこをどう考えても、amazonやAppleが先行してDRMを取っ払い、日本企業が置いてかれて、海外商店の大勝利という構図は見えている。なんだか悲しい。
ま、状況が変わるまではとりあえずアフタヌーンを軸に少量Kindleで買っておきアンテナを張るくらいでいいかな。
2013/11/09(土)HL-5450DNの印刷設定メモ
2013/11/09 4:44
メモしておかないと毎回間違えそうなので残しておく。
最近、BrotherのモノクロレーザープリンタHL-5450DNを導入した。
この機種、True 1200dpi出てグラデーションもかなりよいとの評判。
主にマンガ原稿を印刷する用途としても期待していた。
が、どうも期待した結果通りにならない。
あれこれ試した結果、どうも印刷結果に対して設定項目を誤認しやすい(あるいは自分がレーザプリンタの慣習を知らないだけ)名前になっているようだ。
[Brother HL-5450DN seriesのプロパティ->基本設定->印刷設定]
ここの項目が一番印刷結果に影響を与える。
3種類。
"グラフィックス":
プリンタ側でPhotoShopでの誤差拡散に近い二値化処理を行っている。元画像が二値画像なら(おそらく)これで問題無いが、グレースケールではディザ処理がかかる分汚くなる。
"テキスト":
"グラフィックス"のように二値化をかけずに(そのまま?)出力している。元画像のグレスケ部はインクジェットでのグレスケに近いし、二値・トーン部もしっかり出る。
"手動設定"->"システムのハーフトーンを使う":
一定の閾値を境に二値化がかかる。色々設定を弄ってみたのだが、想定と違ってハーフトーンにならなかった。グレスケを出力する場合白に飛ぶか黒につぶれるかどちらかになりそう。
それ以外に、"手動設定"内部に3種類の改善チェックボックスがある。これらについては確認した限りでON/OFFによる大きな差異は見えなかった。基本外す方向で良いような気がする。
ということで、"テキスト"がすさまじく優秀。マンガ原稿の場合、二値化にしろなんにしろ原稿側で処理してしまうのが基本だろう。"グラフィックス"を意図して選ぶ必要はないと思われる。
"グラフィックス"はお手軽にプリンタ機能だけでハーフトーンかけたいときに使うのが良いんだろうねえ。
最後にオマケで5450DNの雑感を書いておく。これまで使っていたのがMultiWriter 2350Nなので、それと比べてっていうところ。
印刷速度や綺麗さは大変優秀。特に1200dpiはすごい。グレースケールがこんなに綺麗に出て、この印刷速度。サイズも、ギリ卓上と名乗れるくらいでコンパクト。
動作音はかなり五月蠅い。静音モードにしないとちょっと夜間は無理。静音モードにした上でなお壁が薄くなければ使えるか。
心配していたオゾン臭や発熱も、2350Nに比べればずっとマシだった。あとは不満になりやすそうな用紙カールとか印刷の濃さがどうなるか。これらもドライバから制御できるようなので、そこは今後といったところ。
本体にパネルがないのでトラブったときが心配だけれども、とりあえず生きてさえいればブラウザからIPアドレス直打ちで設定・確認できるようなので大丈夫だろうか。
2013/10/17(木)機器入れ替え
2013/10/17 10:43
メモだけ。
■カラーインクジェットプリンタ
HP DJ-955C → Brother DCP-J552N
基本年賀状+イラスト・原稿の出力確認。ほぼ普通紙専用。
DJ-955Cはメカニックは未だにしっかりしているのだが、さすがに古くなってきたし、フチなし印刷がないのが不満だった。
出来るだけ長期間使用しなくてもインク詰まりのない、使いたいときにすぐ使えて、普通紙にそこそこ印刷品質が出るものを調査。
店頭確認したらBrotherの印刷結果が比較的良好だったので、同等程度以上の使い勝手を確保できるだろうと見込んでこれに入れ替えた。
・Epson機はインクの容量・クリーニング時の消費がすごいらしいのでパス。
・(最近の)Canon機は印刷実行から待ちが長い(しょっちゅうクリーニングする?)らしいのでパス。
・HPはあまりに印刷品質が進化してなかった感じだったのでパス。(業務機はそうでもないかも?)
業務機とか色々選択肢あって難しいね。
■モノクロレーザープリンタ
NEC MultiWriter 2350N → Brother HL-5450DN
元々6k位で買ったものだし、ピックアップが怪しくトナーも切れてきたので入れ替えを決断。
A3はほとんど使わなかったので除外。コンパクト・高速かつ、可能ならモノクロでグレースケールが綺麗に出せるものものがほしい。A4両面は必須。
Brotherのグレースケールが良好とのことで、店頭調査。対抗機種のHL-2270DWはコンパクトかつ無線LANがついて値段も安いのだが、印刷品質、特にグレースケールの表現は1200dpi時の5450DNが優る感じだった。消費電力がちと心配だが5450DNに決定。
■サブモニタ
Dell 2001FP → Dell P1914S
2001FPの焼き付き問題が酷くなってきたので入れ替え。
2001FPの焼き付き問題は、複数台で経験したので少なくともロットレベルでこの機種に共通っぽい。それこそ半日~1日レベルでかなりはっきりと見える焼き付きのような輝度差が残る。しばらくすると戻ることもあるのだが、なかなかに不快だった。
このモニタは資料やBGV表示用途なのでピボットは欲しく画面サイズは小さくて良い。
軽量で取り回しがしやすく狭額で、入力端子種類が多く、画角が広く確保できる(IPS/VA系)ものが欲しい。非光沢であるのは大前提。極力低消費電力であると良い。
探したらほとんど選択肢がなかった。正直あんまりDellから買いたくないのだが、消去法でP1914Sに決定。
モニタは今過渡期で、タブレット用などとPC用での乖離が大きくなってしまっている。多分2~3年内に落ち着いてきそうではあるので、それまでのつなぎ。
■サーバ
Compaq nx6110 → Panasonic Let's Note CF-T8(EC6AAS)
サーバにガタが来はじめていたので、入れ替え。
低価格、速度UP、メモリ容量UP、良保守性、コンパクトなものないかなーと思って探していたらCF-T8という選択肢があった。Intel Gigabit EthernetもOK。中古だと激安。うはー。
これはピタリとした一手だったと思う。ノイズ・発熱も今のところは減ったかな。
2013/10/09(水)Windows時刻同期メモ
2013/10/09 17:49
Windows7/XPで、NTPサーバと時刻同期させている(つもり)がずれていることが頻繁にある。
Windowsの標準時刻同期サービスは設定がGUI、サービス、レジストリに分散してしまっていて大変に分かりづらい。機能実装時にActive Directoryが前提だった節もある。しばらく観察して、ずれが解消しないようならpycronやフリーウェアでの調整を考えたい。
要求1: 最低1日1回NTPサーバと同期すること
要求2: 常時、NTPサーバとの時刻ズレが5.0sec以内であること
とりあえず、設定にミスがないか確認する。
・タスクバーの時刻プロパティで"インターネット時刻サーバーと同期する"にチェックされていることを確認。
・管理ツール->サービス->Windows Timeが"開始"かつ"スタートアップの種類"が"自動(遅延実行)"になっていることを確認。
以上の状態でこれから1週間ほど調査する。調査はとりあえず、以下のコマンドで実施。
>w32tm /stripchart /computer:ntp.nict.jp /period:120
>w32tm /monitor /computers:ntp.nict.jp要求としては5.0sec以内であるが、観察期間が短いので3.0secずれたらアウトということにする。
[追記]
上記の設定だけだと、Windows7ではデフォルトの1週間同期になってしまうようだ。参考サイト等を踏まえて考えると、
・ntp.nict.jpはデフォルトサーバ設定0x9(0x1+0x8)なのでSpecialPollIntervalの等間隔同期に従う
・デフォルトのSpecialPollIntervalは604800(604800秒=1週間)
結局やりたくなかったけど、レジストリ弄るのが簡単。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient
のSpecialPollIntervalを43200(43200秒=半日)にする。これでとりあえず様子見。
ローカルポリシーでも設定できるようなので、直接レジストリ弄るのとどちらがまともなのかは今後検討することにする。
[参考]
Windowsネットワーク時刻同期の基礎とノウハウ:第1回 Windows OSにおける時刻同期サービスとNTP (3/4) - @IT
2012/07/17(火)Thunderbirdの文字化け対処法
2012/07/17 10:24
前提として、ThunderbirdではOutlook Expressよりもcharset申告を厳密解釈する。
なので、申告がおかしいメールを判定失敗するのは仕様。これはRight Encodingなどのアドオンで快適に対処、のはずだった。
しかし、charset=UTF-8のメールがISO-2022-JP判定されて文字化けしている。これはちょっと困る。
2カ所チェックすること。
・該当メールのフォルダのプロパティ
一般情報タブ->規定の文字エンコーディング→"この設定をフォルダ内の全てのメッセージに適用する(各メッセージの文字エンコーディング指定や自動判別結果を無視する)"
のチェックを外す。
・ツール->オプション->詳細->設定エディタ
mailnews.force_charset_override
をfalseに設定
自分の場合は以上2カ所で直った。
参考)UTF-8のメールが文字化けする【備忘録】 - Bacchus.gif
2012/07/10(火)春M(SpringM)の関連づけ周り
2012/07/10 11:05
春MはeXecuteで外部アプリケーションを起動できる。この時に「システムの関連づけ」を参照して起動アプリケーションを決める場合、オプションを引き渡さない。
たとえば、eXecuteで
massigra.exe a.bmp /blankは"/blank"オプションが反映されるが、massigra.exeがシステムで.bmpに関連づけられているときに、
a.bmp /blankは"/blnak"オプションが反映されない。コマンドプロンプトの仕様とずれているので、春M側のバグと見ていいように思う。
回避方法は一応ある。とりあえずこの例で言えば、春M自体で.bmpにmassigra.exeを関連づけした後、eXecuteで
\"massigra.exe a.bmp /blank\"とすれば回避可能ではある。けど、拡張子ごとにやるのはちょっと不毛。
そして\"戦法はシステム関連づけには通用しない。
ということで、当座の手立てとしては「オプション指定したい場合は起動exeから書く」以外に無さそうである。
2012/06/16(土)XP+IE6環境にIE Collectionをインストールすると
2012/06/16 13:50
まず前提として、
・IE Collectionはインストール時にレジストリを大量にいじる(梱包している各IEインストーラの挙動次第)。
・アンインストールしてもそれを完全に元に戻さない。
・IE自体が複数バージョン同時実行することを全くケアしていない。
これだけ見ても、デフォルトで入っているIEを動かし続けたい場合、その環境に対して「導入すべきではない」。
以下のように、仮想環境にIE Collectionを導入するのが良いだろう。
Reliable Cross-Browser Testing, Part 1: Internet Explorer | Smashing Coding
しかし、導入してしまった場合どうなるか。
[発生条件]
・OS: Windows XP (SP2, SP3で確認)
・IEバージョン: IE6(IE6の複数バージョンで確認)
・Utilu IE Collection 1.7.2.1をインストール
(インストール時、オプションでIE7かIE8をチェック)
[現象]
元々入っていたIE6で、JavaScriptのwindow.open呼び出し時に、Windowが2画面開く。1枚は表示が空かつSHDocViewが無い状態で正常に動かない。アイコンも正常なIE6と異なる。その他、JS多用画面で頻繁にフリーズ・ブラクラ状態になる。
手元の環境ではIE Collectionで7or8を入れた場合に100%再現した。IE Collectionをアンインストールしても改善しない。
対処方法はかなり対処療法的手法になる。IE Collectionをアンインストールした後、レジストリエディタで以下のキーを削除。
HKEY_CLASSES_ROOT\CLSID\{C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6} (既定) (値の設定なし) HKEY_CLASSES_ROOT\CLSID\{C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}\InProcServer32 (既定) C:\\Program Files\\Internet Explorer\\ieproxy.dll HKEY_CLASSES_ROOT\CLSID\{C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}\InProcServer32 ThreadingModel Both要は"C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6"キーごと消す。
キーの意味は各自で調べて欲しい(ごめんなさい、調べきれませんでした)。
これでIE6のwindow.open周りの挙動は本来の動きに戻る。他におかしいところがあるかもしれないが、一度入れてしまったら後の祭り。IEのIE6より新しいバージョンを入れるか、復元するか、OSの再インストールをするか…… 綺麗にする方法はそこらしかなさそうである。IEのアップデートに失敗して旧IEが動かなくなってしまったときと同じ感じである。
あ、でも綺麗なOSにIE Collection入れてレジストリパッチを作る方法はあるかな……
なお、レジストリの修正は当然自己責任で。バックアップを取ってからの実施をお勧めする(ERUNTとか、この部分だけエクスポートするとか)。
2012/01/05(木)tvrock起動時にwarning
2012/01/05 23:57
「チャンネル"****"の設定がされていません。設定・チューナー欄でチャンネルを設定して下さい。」
が出る問題。
地上波チューナーに衛星の番組が割りあたっていたり、設定→チューナー→チャンネル設定が出来ていない場合などに出る。
新規にチューナーを追加した際などにチャンネル設定が半端になっていたりすると出るので注意。
2011/12/16(金)F904iの電話帳移行メモ
2011/12/16 15:00
故障状況はこの記事と直接関係ないのだが一応書いておこう。どうもアンテナ周りに問題が発生したらしく、屋外なら良いのだが屋内に入るとまず圏外になる。softbank,WiMAX,e-mobileが問題なく通信できる場所でもあっさり圏外になるのでdocomoと契約している意味がない。電池の消耗も異常に早い(電波を必死につかもうとするから?)。
同様の不具合は「F904i 圏外」で検索すればいくらでも出てくる。要は設計として部品耐久性に問題があったということのようだが、docomo側では使用3年超は無償での交換・修理は不可ということだった。
閑話休題。
今はdocomoガラケーとsoftbank iPhoneの2台持ち。状況を見極めつつ契約をスマートフォン1つに一本化したいのだが今は高速回線黎明期だったりしてタイミングが悪い。しゃーないので、確保してあった0円ガラケーことL-03Bに移行することにする。
前置きが長かったが、このとき電話帳を移行するのにちょっと手間だったのでメモ。
何が手間だったかというと、docomoの汎用Datalinkソフト(ドコモケータイdatalink(データリンク) | NTTドコモ)がF904iを認識してくれない。対応機種表にはあるのにだ。メーカのdatalinkソフト(携帯電話(データリンクソフト) ダウンロード - FMWORLD.NET(個人) : 富士通)からは認識できるし、こっちのページにはF905i以降は~docomoのでと書かれているから汎用datalink側の対応機種表が間違っているのだろう。L-03Bは汎用datalinkソフトで認識した。
ということで、メーカのdatalinkソフトで電話帳を抽出することにした。この時フォーマットの選択肢がcsvとvcf(vCard)とあるのだが、csvで吸うとグループが取得できない。グループが維持されないと大変困るのでvcfで吸ったのだが、今度は汎用datalinkでL-03Bに転送する際にこのvcfを取り込む方法がない。
ということで、自前スクリプトでvcf→csvに変換し、これを汎用datalinkソフトに取り込んでL-03Bに転送した。
iPhoneだとvcfをメールに添付→端末側で開く、でも移送可能(グループは消えるし、変なメモが作られるけど)なので、もっと簡単な方法もあるに違いない。まあ、とりあえずこれでできたということだけメモ。
素直にdocomoショップ行くのとどっちが早かったか…