Re: RGSG - GNOMEprint and Icons




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.

First, a question.  Is there any easy way (using imlib or something) do
have an inline PNG file?  By inline, I mean contained within the
executable code in a way that can be accessed, like you can with XPM
files.  In many cases, icons should not be kept as a separate file (eg,
lightweight programs where you want as few files as possible to worry
about distributing), so whatever format gets specified should be able to
be enveloped by the program, and PNG files are vastly superior to XPM
files, so I would prefer them.

The icon file format I have is based on the fact that it is far easier to
clip an image according to predefined methods than to scale an
existing picture, much less to up with a new format.  The underlying
format would be PNG, if possible, or if PNG fails the question above, XPM.
Either way, the image can be developed easily using existing tools.

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.

These images would be combined into one image file, vertically, from
largest to smallest, left justified.  For example, the block reffered to
above would be a 48x120 file, the 48x48 icon would be from (0,0) to
(47,47), the 12x12 icon would be from (0,100) to (11,111).  The clipping
borders of these icons would be quick to calculate no matter what the
largest icon in the block is.

To make it easy to edit, yet still compressable, the portion of the block
that is not covered by the actual icons should be white (RGB 255.255.255).
Presumably, the edges of the icon will be transparent, so this will make
the working area more visible, easier to identify.

Non square icons will be represented by the exact same array.  Icons
taller than they are wide will be left justified in the square, icons
wider than tall will be top justified.  The unused space within the icon
square would be transparent (just in case the application's clipping
doesn't work right).  Yes, this would have a lot of waste unless we have
PNG files.

-Gleef



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]