[oclug]for the mac / linux fans

[Strosberg, Bill]

<snippage of lots of rhetoric>

> This is one of my pet peeves.  My reasons for disliking it 
> are different
> than yours Robert.  By the way, I have no idea whether or not 
> the GIMP can
> do this, but I find the use of the above to be just silly. 
> 
> [endbit.jpg][endbit.jpg][endbit.jpg]  
> [endbit.jpg][endbit.jpg][endbit.jpg]
> [endbit.jpg][endbit.jpg][endbit.jpg] <bigmiddlepart> 
> <clone_of_left_side>
> [endbit.jpg][endbit.jpg][endbit.jpg]
> [endbit.jpg][endbit.jpg][endbit.jpg]
> [endbit.jpg][endbit.jpg][endbit.jpg]

Brad:

I'm no graphics expert, but your ideas seem a little unclear.

Using a tiny image file to replace large areas of static color image makes a
lot of sense, and I've found a single pixel image of the color gets the job
done, as long as the browser/http version support sized images. One (1)
pixel contains  perfectly accurate color data, depending on file type and
color required.  PNG/8 and GIF support the @200 web-safe colors, and PNG/24
and JPG support everything else.  A single pixel PNG gets the job done of a
larger fully sized GIF/PNG without all the pipeline abuse.  A single pixel
image sized to 200x350 looks identical to a full sized graphic of a static
color in most browsers.

With single pixel images, the file size transferred is the minimum supported
by the web server's file system.

Image sizing seems to me to be better focused on:

	- number of colors used (defining image type)
	- keeping palettes used to a minimum, best one per page
	- making intelligent compromises to image quality where possible
	- http connections required and total number of distinct page
elements
	- sharing common page elements over multiple pages, so that web
caches and proxies can cache individual elements that are common, while only
retrieving those unique to pages.

Quality web pages typically download very fast, as higher quality images
types are used ONLY where necessary, and broad swatches of static color are
handled with very simple, small images (single pixel if you are willing to
live with the failure to reach all possible viewer) or by HTML background
attributes.

Intelligent use of image dimensioning works on other circumstances as well.
Background images with a repeating horizontal pattern can be handled via a
single pixel high image that is 1280 pixels wide, and likewise for those
that are vertical pattern.

Web graphics is a numbers game, where you have to balance the percentage of
target audience failures (browser types, HTML levels supported etc.) versus
speed.  If you are willing to accept some failures, while reaching 95% of
all possible clients, you can do amazing things combining HTML page & table
cell background attributes with higher quality image components (PNG, GIF,
JPG) where needed.

Good page rendering requires detailed attention to sizing attributes for all
tables, cells, image components and spacing elements. Failing to clearly
handle all sizing issues up front results in slow and inconsistent pages as
you are depnding on the browser to calculate and size image areas on the
client side.

You do make a good point about http connection overhead, you have to balance
number of page components versus image size.

More annoying than all this image stuff is people who refuse to put in ALT
text - I still do a lot of browsing using w3m and lynx remotely.

--
Bill Strosberg