On 10/16/12 7:40 PM, Ken Thomases wrote:
On Oct 16, 2012, at 2:15 PM, Aric Stewart wrote:
@@ -1052,6 +1079,7 @@ static inline int size_to_slot(int size) case 16: return 0; case 32: return 1; case 48: return 2;
case 64: return 2; /* Classic Mode */ case 128: return 3; case 256: return 4; case 512: return 5;If an ICO has both a 48x48 and a 64x64 entry (improbable, I know), then the 48x48 should be preferred. So, you need additional logic to pick the best index for a slot in platform_write_icon(). Track the best-so-far's width and prefer the smaller.
I thought about that case and decided not to worry about it, however I will work out some logic to cover it.
Beyond that, perhaps the scaling should be put into the ICNS encoder rather than convert_to_native_icon(). That is, if it's handed a size that doesn't fit properly into one of the predefined slots, it would scale down to the next lower size.
I thought about this also and was not sure if the ICNS encoder in windowscodecs was following some spec or understood behavior on rejecting the size. I know that winemenubuilder is wine specific and so doing the scaling there would not have to be windows compliant. A quick google search seems to indicate that CLSID_WICIcnsEncoder is not a windows feature either.
Although it might be better to synthesize a 32x32 rather than a 48x48 from a 64x64. *shrug*
Just because 32 is half of 64? I will admit my understanding of image scaling is poor enough that i just assumed the closer the size the better the scale would turn out.
-aric