虚構人形廃棄場

現在MacBook Pro 15で使っているFirefoxのプロファイルはThinkPad X61 Tabletから持ってきたものです。

解像度が高すぎるX61tではよく拡大していたのですが、MBP15では拡大せずに済むところ、画像がぼやけていて「ああ、拡大されたままだった」となることがよくありました。倍率がサイト毎に保存されているようなのです。

この倍率はどこに保存されていたものか...。"Default FullZoom Level"というアドオンを使っていたのですが、削除後にも残存していますから、Firefox本体の機能です。

調べたところ、content-prefs.sqliteに入っているということなのですが、倍率だけリセットする方法が皆目見当が付かず、結局削除してしまいました(リネーム→正常動作確認→削除)。

他にはポップアップの許可だとか、ファイル保存先ディレクトリだとかが格納されていたようですが、まあ影響は軽微です。

ちなみに倍率の保存をサイト毎に保存するか否かは"browser.zoom.siteSpecific"という設定値だそうでして、現在はfalseにして、一件落着となっています。

表示倍率はディスプレイを変更したり、私のようにプロファイルをコピーした際などは一挙にリセットしたいこともあるでしょう。もうちょっと何とかしてほしいものです。

北浦和西口駅前のビル工事現場の脇から見えている、工事用の階段です。

ウィンドウの位置を1エントリで自然に記録しようと"%d %d %d %d"で書き込んだら、読み出す時に困りました。
もちろんsscanf系で取れるのですが、ワンクッション挟むにはvsscanf系が必要で、これがVisual C++にはありません。

有名どころでは、Cライブラリの内部関数_input_l及び_winput_lを使う方法がありますが、内部関数なので静的リンク必須ですし、互換性は保証されません。

簡易実装する方法はいくらでもあります。数値以外がなく区切り文字が決まっているなら、strtokで切り出しながらsscanfに渡す手があるでしょう。

でももっともっと汎用的に、と調べていたら、面白いものを発見しました。
flipcode - vsscanf for Win32

va_listの中身は大抵の実装では引数(格納する変数へのポインタ)の配列なので、sscanf用に並べ直せばいいじゃないか、というものです。引数の生成はスタックの操作ですから、インラインアセンブラが使われています。

これも有用だったのですが、x64非対応です。x64ではインラインアセンブラ自体が使えなくなっていますし、呼び出し規則も違います。

というわけで、アセンブラ部をasmファイルに分け、x86/x64両対応にしてみました。
vsscanf.zip

同梱プロジェクはVisual Studio 2008用で、カスタムビルド規則として"Microsoft Macro Assembler"を有効にしてありますが、このままではx64が通りません。

Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\x86_amd64

にあるml64.exeをml.exeにコピーする必要があります。

この辺はマイクロソフトの不備で、細工せずml64.exeを呼び出す方法がないのです。x86_amd64\ml.exeを用意するか、x64用カスタムビルド規則を作成するかしかありません。

flipcodeも私の移植版も、有効な%を数えてはva_listから取り出すので、%の方が多ければsscanf同様に即死するのでご注意。

ストアアプリにしたいネタが一つ発生し、¥3300終了間際にWindows 8を購入しました。メインで使う気はないのでThinkPad X61 Tabletの方です。

暫定的にATOK2008とDeltaEndを入れて、とりあえずデスクトップでは日本語が普通に使えるようになりました。

さらに引き続きTMPGEnc Authoring Works 4を入れ、ADVC-100が取り込めるか試したところ、問題ありませんでした。

ま、使いづらいですWindows 8。起動を速くできるのは古い機種には幸いですが、デスクトップが不完全なのに加え、モダンUIの作り込みも甘いので、ストレスが溜まります。

それでも、技術者として触れておきたいというのもありまして、こうして飼うことにしたわけです。

MP990所有中に買って使わずだった写真用紙がありました。100枚1500円という、なかなかの高級品です。フジフィルム写真仕上げPro。

MP990での印刷が、実家の父が使うMP950に遠く及ばないのがなぜかと試行錯誤していた最中に、用紙も影響しているはずと奮発して、それきりだったものです。

結論から言えば、印刷品質設定を最高にしておかなければならなかったのでしょうが、そうであれ日常のインク浪費は耐え難く、手放す結末は変わらなかったでしょう。

ちなみに昨年秋、そのMP950が壊れてMP990を譲ることも提案しましたが、MG8x30がモデルチェンジしなかったことから、確実に長く使うためとMG8230購入、そのままMP990売却、MP950の買い置きインクはMP500へ、ということがありました。

さて、正月に実家で撮影した写真を電気店で印刷しました。専用機なら綺麗だろうというわけで。ところが少し暗い。家具の色調が暗い上に、冬なので男性陣の衣服も暗い。

Optio555は古い世代のカメラなので、素直に面積に引きずられてしまいます。露出補正をかけておくべきでしたが、落ち着きのない幼児がいるので調整している余裕もありませんでした。

そこで多少の編集ができる専用機がある写真屋で明るく補正してみると...白飛び発生。印刷中に神経衰弱ができる機械ですが、色も妙に濃すぎて好みではありません。

簡易なUIではガンマ補正とかコントラストとか細かい調整は無理でしょうが、明るさだけ上げたら白飛びするでしょう。Photoshop Elementsの「自動スマート補正」みたいな機能があればいいのですが。

店頭での試行錯誤は長時間の占有になり迷惑なので、自分で補正したデータをSDカードに突っ込んで、仕上がり自体は好みだった、補正できない方の専用機で印刷するしかなかろうか、と諦めて帰宅。

そして加工中に確認ぐらいのつもりで、MP500を最高品質設定で冒頭の用紙に印刷したところ、これが思ったより遙かに綺麗に仕上がって驚いてしまいました。

清掃してインク汚れの心配がなくなった記念の、ちょっとした出来心でしたが、年甲斐もなく「マジか」「すっげぇ」なんぞと呟く始末。本当に感動しまして、結局自宅で済ませてしまいました。

MP500は5色インクの中級機でFINE搭載ですから、元々ある程度綺麗ではあったはずなのです。今までPPC用紙と標準設定でしか使っていませんでしたから、全く能力を活かしていませんでしたが。

フォトインクではないので褪色は早めかもしれませんが、光沢紙と最高品質設定の組み合わせは、かなりのものだと実感した次第です。この点に関しては古希を超えた父の方が先んじていたわけですね(汗)。

USBのポートリセットに使われていたIOCTL_USB_HUB_CYCLE_PORTがWindows 8で復活したようです。

IOCTL_USB_HUB_CYCLE_PORT control code (Windows Drivers)

Vistaで削除され、一部では困っていた人もいるのですが、XP終了間際で救済措置ということでしょうか。

いつの間にかやけに汚れていて、運搬中に壊してしまったかと思いきや、思い切って清掃してみたところ長年の蓄積によるものと判明しました。

最初はメーカー整備を考え、期間や費用を聞いてみようと電話したところ、2011年で受け付け終了したとの告知。でも取説にある範囲でですが手入れ方法を教わったりして、好感度が少し上がったりしました。

実家で亡くなったMP950の形見インクがまだまだあるので、買い換えは待ちたいところです。背面給紙がないキヤノン冬の時代ですし、そこで自力整備を決行した次第。

どうも廃インクを吸収体に誘導する部分が元々あまり良くないらしく、途中にこびり付きタール状になったものが筐体内側に沿って石筍のように積み上がり、ついに周りに飛び散るようになっていた、という状態です(写真は除去途中のもの)。

英語版サービスマニュアルがネット上に落ちているので、それに従って分解しましたが、本体メカを下筐体から取り外す記述がないような。ネジ4本だけなのですが、左奥側は電源ケーブルに隠れるような場所にあるので、長めの磁化ドライバー必須です。

組み立て時はスキャナ部を左右カバーで挟む部分で苦労しました。恐らくアームがある右側を先にすれば良いのでしょう。試行錯誤している間にフレキシブルケーブルを切断しかねないので、弱い方を先に仮固定すべきと考えます。

これで少しは寿命が延びたか、或いは生兵法整備で縮まったか。教訓としては、修理受付終了の頃にメーカー整備をすべき、ということでしょうか。BCI-7e/9e世代最後のMP970/610等は今年までですから、持っている人は今すぐ整備してもらいましょう。

明けましておめでとうございます。2013年最初のハンダごてはAH-J3003Sのバッテリーでした。

とりあえずDB-L80の互換バッテリーに元々のリード線をハンダ付けして、フタが閉まらないのでボール紙で代用して、という感じです。

使ったのはMyBattery HQで、動作、充電、および残量は不明ですが充電が完了するところまで確認しています。充電器側のアソビがあまりないので、カバーはボール紙でギリギリです。

リチウムイオンは本質的におっかないものですが、保護回路内蔵でさえあれば、電圧が同じで容量が大差なければ大体使えることになるのだそうな。ちなみにコネクタはSMKのHPのようなのですが、小売りでは手に入らないので、リード線を切断して流用するほかありません。

カメラのバッテリーはあまり薄いものがなく、フタが閉まることは期待できません。ヒロセテクニカルの店頭でリチウムイオンのモジュールを売っていますが、保護回路は付いていたでしょうか、あれなら大丈夫そうですが少し割高です。

何か変だと思ったら、条件は完全にはわかりませんが、SendMessageTimeout失敗時のGetLastErrorの戻り値が内部で更新されていない場合があるようです。

オンラインのMSDNライブラリ当該頁にもツッコミがありますが、少なくともVistaと7で、ハングしている可能性があるウィンドウに対し、SMTO_ABORTIFHUNGを指定して制御が即時に戻った場合に発生しています。

戻り値が0(ERROR_SUCCESS)だったり5(ERROR_ACCESS_DENIED)だったり、平たく言えば1460(ERROR_TIMEOUT)以外が入らない?