On Oct 18, 2012, at 9:58 AM, Francois Gouget wrote:
> Even if you actually have other sizes in addition to 64x64 I think the
> upscaling option would actually work pretty well. So it may make sense
> to change the code to scale up to 128x128 unless there's already a
> 128x128 icon.
... or larg
On Wed, 17 Oct 2012, Aric Stewart wrote:
[...]
> The issue I am working on resolving here is that many older windows
> programs only provide a 64x64 icon. With the old code, because there
> is no 64x64 slot in icns files, these applications where loosing there
> icons.
If the Mac behaves sensib
On 10/17/12 3:11 AM, Per Johansson wrote:
> On Wed, Oct 17, 2012 at 6:08 AM, Vincent Povirk wrote:
>> I agree that scaling to 32x32 would probably work out better.
>> Personally, I probably would've chosen 128x128, since that would
>> involve no loss of information or distortion (but maybe we don'
On Wed, Oct 17, 2012 at 6:08 AM, Vincent Povirk wrote:
> I agree that scaling to 32x32 would probably work out better.
> Personally, I probably would've chosen 128x128, since that would
> involve no loss of information or distortion (but maybe we don't like
> the increased file size?).
It's howev
On Tue, Oct 16, 2012 at 7:40 PM, Ken Thomases wrote:
> 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 low
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; /* Class
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;
> ca
