Re: Server-side data conversion and Internet bandwidth (was: Re: Multi column

Walter Ian Kaye ([email protected])
Sat, 24 Jun 1995 19:23:28 -0700


At 02:29a 06/25/95, Philippe-Andre Prindeville wrote:

>Just here: image scaling (ie. fitting an image into a
>640x400 rectangle), depth reduction (taking a 24bit GIF file
>and rendering it in 1bit deep B&W on a notebook), etc. should
>be done *SERVER-SIDE*.

What we really need are guidelines, and for HTML authors to follow them.
For example, I propose the following for _inline_ images:

* 8-bit (256 color) images (can link to 24-bit if desired)
* 72-dpi resolution (can link to high-res if desired)
* Reasonable image sizes, like max 470 pixels wide for
title graphics and navbars (again, can link if desired)
This also ensures that images will fit without scrolling
within default window sizes of Mosaic and Netscape browsers
on typical 13-15" monitors (it defaults to same width on my
17" monitor, as a matter of fact)

BTW, there's no such thing as a 24bit GIF file... ;)

RE scaling: For JPEG images of 1200dpi resolution this works fine, but for
images of 72dpi resolution, scaling up by a non-integral factor or scaling
down will result in a badly-distorted image. I'd hate to see what scaling
would do to my 72dpi images...

Or should I convert all my 72dpi inline GIFs into 288dpi JPEGs? Do JPEGs
support transparency like GIF89a? I'd also hate to spend time making all
those edits simply to support people who configure their monitors and video
drivers for extra-condensed pixels -- these people should be used to
condensed images and text!

-Walter

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Walter Ian Kaye: (602) 942-6390 FoxPro/Excel Programmer; Guitarist #
# Correspond to: [email protected], [email protected] #
# BinHex files: [email protected] WWW: http://www.primenet.com/~boo/ #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #