Cursor / Icon Susie Plug-in 1.2 を公開しました。

アニメーションカーソルの他に、通常のカーソルやアイコンも展開できる
ように拡張しました。

どうもお世話になってます
.aniと.curが画像ビューアLeeyesで表示出来ないです
axanicur.spi v1.1＆iftwic.spiでは表示出来てます


アニメーションカーソルは
raw\raw001.cur
raw\raw002.cur
の様に展開までは行ってます
前に掲示板に投稿されてた
axanicur.spi v1.0の時と同じ様な感じです
よろしくお願いします

確認してみましたが、Leeyes固有の問題のようです。

今回のバージョンは、.cur内に入っているカーソルが１つのときは
書庫扱いしない仕様なのですが、Leeyesは書庫の判定を拡張子で
決め打ちしているようで、書庫でないのに書庫扱いしてエラーが
発生しているようです。

どう対応するかすぐには決められないので、しばらく検討します。
それまでは旧版を使用してください。

確認ありがとうございます
手持ちの書庫用Susie Plug-inを使う他のソフトも確認しましたが
NeeView(NeeViewS.exe)
BonsFM
などどれもダメでした
よろしくお願いします

とりあえず、前回挙げた理由を無くした（cur内に入っているカーソルが
１つのときも書庫にする）Pluginを用意しました。
http://toro.d.dooo.jp/axcuri12a.zip

しかし、これを使うと次のような状態になります。
・Leeyes
　エラー表示が無くなり、表示されるようになります。
　しかし、書庫内のカーソルにも階層表示がついて、いくらでも
　下の階層にいけるようになり、そのうち異常終了するように
　なります。
・NeeViewS
　読み込み中表示のまま反応しなくなります。
　多分、Leeyesと同じように階層の展開が終わらなくなっています。

BonsFMは、Pluginの設定方法が分からなかったので確認していません。


挙げていただいたソフトは、いずれもカーソルを書庫扱いにすると
問題が出るため、axcurico.spi は使用できなさそうです。また、
各ソフトの設計の問題のため、こちらでは対応できなさそうです。

旧版のaxanicur.spiを使い、アニメーションカーソルのみ書庫扱いに
するようにしてください。

axcuri12a.zipありがとうございます
残念ながらこちらの環境では
1.2a＆1.2どちらも.ani/.cur/.icoの画像表示出来ませんでした
.aniは展開されraw001.curが開けませんでしたの表示
.cur/.icoはそのまま開けませんでしたの表示
念の為axcurico.spiとiftwic.spiのみ入れてテストしてもダメでした
axanicur.spi v1.1を使わせていただくことにします
ありがとうございました

すみません。axcuri12a.zip の中身が間違っていました。
再作成したものに入れ替えておきましたので、必要に応じて
再ダウンロードしてください。

http://toro.d.dooo.jp/axcuri12a.zip

ありがとうございます
今回は
Leeyes
NeeViewS
で無事、.ani/.cur/.icoの画像表示出来ました

一部のソフトは、カーソルを書庫扱いにすると問題が発生するため、
旧版を配布ページから入手できるようにしました。
旧版を使用するようにしてください。

横から失礼します。

提案があるのですが、単一のアイコンを格納する独自のバイナリフォーマットを定義するというのはどうでしょうか。

すなわち、.icoや.curフォーマットに独自ヘッダーを付けるなどした「.toroico」あるいは「.torocur」なる独自フォーマットを定義しておきます。

まず、axcurico.spi側の処理ですが、アイコンやカーソルが1つだけのときも.icoや.curを書庫扱いします。書庫の中身のアイコンやカーソルは、元の.icoや.curではなくこれを変換した.toroicoや.torocurとなるようにします。つまり、axcurico.spi側で一旦独自フォーマットに変更します。

次に、iftwic.spiまたはiftgdip.spi側の処理ですが、.toroicoや.torocurを画像ファイルとして扱うようにした上で、これを内部で.icoや.curに戻してからOSのWICまたはGDI+に渡します。当然、このオプションを使うときは.icoや.curを無視するようにします。

こうすることで.icoや.curは完全に書庫扱いとなり、その中身は画像としての.toroicoや.torocurになり、NeeViewなどの一部のアプリでもちゃんと表示できるようになります。

まとめると、axcurico.spiは.icoや.cur書庫を.toroicoや.torocurに解凍するプラグインとして、またiftwic.spiまたはiftgdip.spiは.toroicoや.torocur画像を表示するプラグインとして機能させることになります。

もちろん、過去バージョンとの互換性のためこの機能は設定でオプション扱いとなるようにします。

画像の表示という目的であれば、確かにそれで対応できますね。

Cursor / Icon Susie Plug-in を作った目的が、各ファイルからの
アイコン抽出だったので、そのような考えには至りませんでした。

ただ、独自のファイル形式にするよりは、bmpファイルにしてしまった
ほうがよさそうです。
少し検討させてもらいます。

> ただ、独自のファイル形式にするよりは、bmpファイルにしてしまった
> ほうがよさそうです。

.icoや.curの中身を.bmpにデコードするということは、axcurico.spiに
自前でデコーダーを内蔵することになるか、WICまたはGDI+のAPIを
axcurico.spi側からも呼び出すかのどちらかになります。

前者の自前のデコーダーを用意する場合では、Windows Vista以降で採用された
「PNG圧縮された.icoフォーマット」に対応するため自前でPNGデコーダーを
組み込む必要があります。よって、後者のWICまたはGDI+を呼び出す方法が
現実的かと思われます。

マスク画像があるのを忘れていました。bmp形式で出そうとすると、
マスク画像の取り扱いに困りますね。それさえなければファイル
ヘッダの用意だけでbmpファイルの出力が可能なのですが。

png形式は、一覧取得の段階で認識してますし、png ファイルが
そのまま入っているので、それを出力すれば問題ありません。


とりあえず、独自ファイル形式の使用は避ける方向で考えています。
自分で使用していない拡張子決め打ちソフトのために、専用の
ファイル形式を用意し、その形式を維持していく余裕がないためです。

独自拡張子も本当は使いたくありませんが、現状だと使った方が
良さそうな感じですね。

ただ、iftwic は、拡張子を無視して ico/cur を認識できますので、
jxr とかの iftwic の対応拡張子に書き換えれば、iftwic に専用
処理を追加しなくても対応できるため、その方向にするかもしれません。
※バイナリエディタで、axcurico.spi 中の %03d(%dx%d-%d).ico 、
%03d(%dx%d-%d).cur の拡張子を jxr に書き換えて確認しています。

> マスク画像があるのを忘れていました。bmp形式で出そうとすると、
> マスク画像の取り扱いに困りますね。それさえなければファイル
> ヘッダの用意だけでbmpファイルの出力が可能なのですが。
>
> png形式は、一覧取得の段階で認識してますし、png ファイルが
> そのまま入っているので、それを出力すれば問題ありません。

.ico/.curを.bmpにデコードする処理は、無理にaxcurico.spi内で
自前で行う必要はないかもしれません。つまり、axcurico.spiは
展開して取得した.ico/.curのデータを一旦WindowsのWICまたは
GDI+のAPIを使って.bmpにデコードして出力するというやり方です。

すなわち、iftwic.spiおよびiftgdip.spiに搭載されているWICおよび
GDI+を呼び出す機能をaxcurico.spiにも搭載するということです。
ただし、axcurico.spiとiftwic.spiおよびiftgdip.spiとに同じ機能を
搭載することになるため、容量などの無駄が生じたりメンテナンスの
際に両方同時に行う手間がかかったりします。このため、WICまたは
GDI+を呼び出して画像データをデコードするルーチンだけを「別のDLL」
として作成し、axcurico.spiとiftwic.spiおよびiftgdip.spiとの両方から
このDLLを呼び出すという方法をとったほうが良いかもしれません。



> ただ、iftwic は、拡張子を無視して ico/cur を認識できますので、
> jxr とかの iftwic の対応拡張子に書き換えれば、iftwic に専用
> 処理を追加しなくても対応できるため、その方向にするかもしれません。
> ※バイナリエディタで、axcurico.spi 中の %03d(%dx%d-%d).ico 、
> %03d(%dx%d-%d).cur の拡張子を jxr に書き換えて確認しています。

この方法だと、ファイルの中身は.ico/.curなのに拡張子だけがJPEG XRの
物という「偽装ファイル」状態となり、アプリによっては新たな問題を
引き起こしそうです。ユーザーから見ても、しかるべきバイナリ構造の
ファイルにはしかるべき拡張子が付いていたほうが扱いが楽になります。

デコーダを分離しても専用のDLLという点で分ける必要はありません。
現状のittwicは、ani/curの独自処理が入っている点で専用のDLLと
いえるかもしれませんが、メジャーなani/curをico扱いにするための
細工をしているだけで、独自形式の追加は考えていません。

WIC/GDI+を使ったデコーダの内蔵についても、一部のソフトの問題
対応のためだけに、本来の機能と同等以上の分量を実装することに
なりますので、行いたくありません。


>ファイルにはしかるべき拡張子が付いていたほうが扱いが楽になります。
元の話が本来の拡張子では動作しないソフトのために、一時的に別の
拡張子を付けて偽装し、問題を回避しようということなので、
たいした違いではないと思います。それにこちらはこの程度の規模の
対応で済ませる余裕しかありません。
それでも問題ということでしたら、元ソフトの方を修正すべきです。

> WIC/GDI+を使ったデコーダの内蔵についても、一部のソフトの問題
> 対応のためだけに、本来の機能と同等以上の分量を実装することに
> なりますので、行いたくありません。

確かに、axcurico.spiは32,900byteなのに対してiftwic.spiは74,240byteと
2倍以上の容量がありました。WICの呼び出しは思った以上にボリュームの
ある処理だったのですね。大変失礼しました。

ということは対応の選択肢は、マスク画像の処理を行って.bmpで出力するか、
WIC対応拡張子に偽装するかの2つということとなるわけですね。

でも、マスク画像の処理って聞いただけでかなりボリュームのある処理を
強いられそうな気がするのですが ...
ということは少々気持ち悪くても拡張子の偽装が現実的な対処かもしれません。