Re: GNOMEPrint, Icons, and shades of InSight..

[Bowie Poag <bjp primenet com>]

> > This is precisely what we were doing in InSight. We were going to have a
> > scaling engine and icon cache that would have used 64x64 base tiles, and
> > converted them on the fly up to as high as 80x80, and as low as 8x8 for
> > usage on the destop.  
> 
> That's not what I'm talking about here.  I'm talking about a way to avoid
> automatic resizing, since automatic resizing will often give mediocre
> results.  This is a format to ensure that a manually designed icon
> would exist for a variety of sizes.  That being said, I could see a
> utility to convert a standard square PNG into an array as above for manual
> retouching.

I disagree. The quality of a resulting image that goes through resizing
depends largely upon the quality of the algorithm, and the quality of the
input sample. Trust me on this one. :) Basically, it works out like this:
The mathematics involved have alot to do with it. If you take an icon size
who's dimensions are a square number like 64x64, the icon will look its
best when scaled down to one of its factors; In this case, 32x32, 16x16,
etc. Median scaling also looks acceptable in 24x24, 48x48, etc.. But there
will be noticable degradation when using NON-square numbers.. Like going
from 64x64 to 19x19. Even the best algorithms have to settle for some
quality loss.

In InSight, we were using 64x64 base tiles, with an algorithm designed to
handle upscale to 80x80, and downscale to 8x8. The user's choice of
desired icon sizes was limited to every 8 pixels.. Meaning, they COULDNT
choose a "19x19" size. They had 8x8, 16x16, 24x24, 32x32, 40x40, 48x48,
56x56, 64x64, 72x72, and an 80x80 -- With no arbitrary numbers inbetween.
This prevented the user from seeing badly scaled images.

If an icon were to have been scaled to some value outside of its original
(64x64), the resulting image would have been cached as part of the IML. No
resizing of THAT specific icon, to THAT specific size would have ever been
needed to be done again.

> 
> This is in response not only to the GNOMEprint issue, but to all the
> points where people have said "can't we make that user cusomizable to be
> larger or smaller".

Right. But you cant tie the scaling og the GNOMEprint to the size of the
font. This open the door for a crappy looking GNOMEprint icon, as
described above.. And you cant very well restrict users to choosing font
sizes in 8 point increments. :)

This is why i'm not against having the gnomeprint on the menu bar. It
breaks consistancy in a big, big way. Yes, it would be neet, and it is
technically feasable, but the results would be ugly, and kludgy at best.
Branding is nice, just not done in this way.

> Also note that the trivial case of the above icon format is a single
> square PNG of whatever size you want the icon.  I.e, there is no general
> requirement for an icon to be resizable, just the standard ability for it
> to be.  It would also clearly define the file format that we want GNOME
> icons to be, so people will keep away from using GIFs (strongly
> discouraged in GNU projects).

Yup.
 
> On the other hand, certain locations might have a few sizes required for
> resizing.  In particular, the Panel has been the most requested to be made
> smaller, and occasionally larger, and any changes to the size of the panel
> should be user customizable.

Yup. The UISG will likely mandate this.. Because the Panel in its current
form wont cut it.
 
> > After conversion, they would be cached, in the hope
> > that they would later be used by the system. Theres alot I could talk
> > about here, but I'll stop for now.
> 
> These would not be cached in memory, or on disk.  The standard icon format
> will contain all the sizes that the font has.

Im worried about bloat here. If a user wants an icon, they should have an
icon.. Not the icon, and a dozen of its siblings. :)


> > I *dont* propose we do the same thing with GNOME, however.
> 
> I don't see how it hurts.  I still don't know about the feasability of
> embedding PNGs in executable code.  That's pretty much the only benefit of
> XPMs, they are easy to use as standalone or within a program.

We're talking about stuff which is really, really, really along the lines
of what we were up to at InSight. The best arrangement we decided in the
end, was a separate, static archive of icons, which sat around like books
in a library. This is what the IML was. It eventually turned out that
doing it any other way (as per what you've described) would have been
disasterous.


My .02,
Bowie