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

[Gleef <gleef capital net>]

On Sat, 8 Aug 1998, Bowie Poag wrote:
> Gleef Wrote:
> > 
> > Someone else had pointed out that we need to have an effective way of
> > having scalable icons, possibly a new file format.  This discussion of the
> > GNOMEprint reminded me that this is important, and here's my proposal.
>   (....stuff about PNG deleted for space..)
> > First, we define a set of allowable icon sizes (in pixels).  A particular 
> > icon need not support all of the list, but it must supply a contiguous
> > block (eg. all the lines between 48x48 and 8x8), even if some of the
> > sizes are left blank (here's where PNG would come in handy). I propose the
> > following list:
> > 512x512
> > 384x384
> > 256x256
> > 192x192 (From here up will probably be rare, but it hurts nothing to
> > 128x128  support it)
> > 96x96
> > 64x64
> > 48x48
> > 32x32
> > 24x24
> > 16x16
> > 12x12
> > 8x8
> > 
> > An argument could be made for adding 20x20, 40x40, 80x80, 160x160 and
> > 320x320 sizes, adding them would just play with the equations a bit.
> > However, I don't think those sizes are critical, the list I gave would be
> > a good enough array of pictures.
> 
> 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.

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".

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).

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.


> 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.

 
> 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.

Does anyone know of a program that does this, so I can look at the code?

-Gleef