Polite and Considerate
Still most of
the private users are connected to Internet through a dial up line, generally using
modems. I have no figures on which speed is mainly used, but I think quite a few
still use a 28.8 kilobit modem and that is slow when
surfing non-polite modern sites. Every single item that is added to a page forces
the browser to make another connection and download that item. The time to connect
is something between a tenth of a second to ... you name it, the server may be heavy
trafficked or the cable shared by too many users, and you do pay the tele cost.
To that we add the download time. Pretty much here we see that being polite and
considerate is to reduce the number of items added to a page and reduce the file
size of each item.
The number of images may be resolved
by this simple question: "Does this image bring value to the text (or page)
and is it then essential?" If "No", then drop it.
Further we do not know much about
the readers' screens, do we? There are still an amazing numbers of 14" screens
around, and a lot of users with 640 x 480 screen resolution. But most
of the web designers are playing with 21" and 1280 x 1024 or better.
What a conflict indeed! But being polite and considerate is to care about the common
user, isn't it? Hence no image will be wider than it can be viewed by any reader.
What sizes are we talking about then? Do not be misled by the 640 x 480
figures since first the web browser will take a number of pixels away, let us say
about 30 pixels, and then the page may be styled using tables and thus it is only
the width of the table cell left, minus cell padding if used.
For example, this page is constructed
using a table (that topic will be discussed in the next article) and the "page
header" containing 1/ the logo, 2/ the vertical colored bar and 3) the navigation
links (which themselves are put in another small table) above the article headline.
These three items are put in separate cells. If I would like to use an image immediately
beneath the head line, how much is left to the rightmost cell ?
The logo is 240 pixels wide, the vertical bar (an image resized to 2 x 400)
are padded with a horizontal space of 10 pixels each side summing up to 2 + (2 * 10) = 22
pixels, that is 240 + 22 = 262 pixels only for the first two
cells, and to that we add 30 pixels for the browser, ending up with almost 300 pixels.
If then the reader use a 640 x 480 screen resolution there is only an
image width of 340 left in our example.
If we, on the other hand, are placing
the images in the big cell containing this text we can use up to a width of 600
pixels but no more. As you have seen there are two page styles used in OS/2 e-Zine,
the common style and the style of my articles used so that code lines may be of
a usable length. The common style does not offer space for images wider than 340
pixels, else some users will run into trouble.
Reduce the number of items
Reduce the file sizes
Use no images wider than 600 pixels
or computed from the available space
You can not do much about the bottlenecks
on the Internet, but you can help not to overload it. You can not give greater screens
to everyone, but you can help not to overfill older screens. The next part will
guide us into the technical part of our qualities.
GIF or JPG
The two most used image formats on the
web are GIF and JPG. GIF (Graphics Interchange Format) was designed in 1987 and
was added some features in 1989. Since GIF uses a file compression algorithm patented
by Unisys, some application makers have chosen not to support GIF, but it is still
the most widely used image format on the web. GIF gives you a maximum of 256 colors,
though the palette may be chosen anyway you like. That is all of the 256 colors
may be shades of red if you like. Further GIF is a lossless format and hence preserves
images with a limited numbers of colors very well.
JPG, or JPEG as it is actually named,
is on the contrary a "lossy" image format, and thus destroys the image
upon compression. On the other hand it reproduces photographs very well with plenty
of colors. That this format is "lossy" excludes it from some uses, it
really destroys the image that the decompressed image is not the same that you saved.
The eye will not easily see the loss but it is still there, the eye is "fooled"
to think that the image looks perfect but it does not. Images may be more or less
compressed, thus providing a minimal to maximal loss. For more details I recommend
the exhaustive Help of PMView.
When to use GIF or JPG?
The common answer is, use GIF to screen
captures and plain images, and photographs and alike are saved using JPG. If the
images uses 256 colors or less you may always use GIF and then try to convert them
to JPG using different compression degrees and compare the file sizes. Can photographs
be converted to GIF? Sometimes, sometimes not. You have to try and see. Many times
the file size will increase and thus there is no benefit to it. But you can not
convert a JPG image to GIF and get a good result, since the JPG format is "lossy".
Screen captures & plain images => GIF
Photo quality => JPG
What is web safe (or Netscape) colors?
the time when colors were limited in numbers but the web was evolving fast there
was a scheme introduced that used only 216 colors, only 6 shades of red, 6 of green
and 6 of blue. These shades were fixed to certain values that the older browsers
supported, and until this day some still can not render more than these, believe
me. So if you really like to be safe then you save your images using GIF and 6-6-6
palette type. Another benefit is that the file size may be drastically reduced without
that much quality loss, hence I recommend you to always give it a try.
The Java installment of September,
the ColorBox article, used a screen capture
that originally looked as the upper image. It used 24-bit color depth and had a
file size of 7,966 bytes using the GIF format. Trying to use JPG with 75% quality
gave me 13,856 bytes in spite of using "Optimize entropy encoding" that
further reduced the JPG file size about 3 kB (without this latter encoding the file
size was about 15 kB, more than double compared to GIF).
next image is saved using the 6-6-6 color color palette. That image have a file
size of 4,402 and is only using 14 colors. As you see there is no important difference
in the image quality. The difference is mainly seen in the shading of the buttons
of the upper right corner that are more brutally shaded. But since the essential
part of the image did not get lost I was pleased with the result and used it.
Hence we find that by using the 6-6-6
palette we almost halve the image file size. That is not the case every time but
in most cases we will benefit from using that color palette. Not only the file sizes
decreases, black will indeed be black and white will be white, as red, green or
blue will be clear and crisp. But more on that later on.
How to be provident?
We will start from the end, the image
size, since it is the best thing to start with. As stated the image size is set
by the available width, maybe set by the screen, or maybe by how the table of the
page is created. First you have to figure out the worst case and that will give
you the maximum image width. The height is not that important, but do not be too
optimistic. Once you have computed a usable image width you can get such an image.
There are two file formats to use,
photo quality images and simpler images such as screen captures. If the image you
want to use is of photo quality let us hope that it is of high quality from the
beginning, else it may not be possible to transform the image size. You have
to try and see how the result looks like. It does not matter the quality of your
image editor, if the file you have to work with is too heavily compressed you are
in trouble. Then try to get the original file and work with a copy of that one.
Or maybe drop the use of it.
If you get a good image to start
with, first transform it to the image size you will use, then you can start
experiment with it (please save a backup copy first) to see how hard you may compress
it and if it is as good looking when using GIF. As long as the image quality is
okay to you it is only thing that matters is the file size. This part is a mere
time consuming experiment, but soon you can see such things by a short look at it.
When you are planning for a screen capture
(a dump) there are some steps to take. First the image size, then the file size.
You will get the best result if you
can take the snap shot at the size you will later use. For example, you like to
get an image 260 x 200 and it will be a complete application frame, like
the one above. Then try to resize the application that it is 260 x 200
from the very beginning, hence you will get no loss as when you later try to resize
it by the image editor. Transforming the image size later on will indeed give you
a quality loss.
Sizing an window to the wished width
and height is not always as easy as it looks like. Some frames, or perhaps most
often dialog boxes, do not allow resizing. How do you do then? First try to capture
the item and transform the size using your favorite editor (Note, the application
I used for this article is PMView. But most image editors have features that work
more or less the same way), but if the quality loss is too heavy, lessen the resolution
of your own screen (perhaps you then have to reboot) and take the snap shot from
there. Then return to your usual resolution. Cumbersome, yes indeed, but considerate.
the preliminary steps the snapshot is very simple. Under "File" you find
"Capture" that gives you some options and a necessary "Setup".
The setup may be "Instant" , "Delayed by ... seconds"
or "Activated by ..." and some options more, pretty self explanatory.
After accepting your choice you have to choose between the options viewed at the
image. A suggestion may be to get the "Window" and later make a selection
of the captured image using your mouse button number one.
Having the capture at hand, do
not save the screen dump as JPG or some other "lossy" file format
that destroys the snap shot. If the number of colors are more than 256 you perhaps
can not use GIF either since that file format will drop colors. Then you are to
use PNG or TIF file formats that are fully lossless. But since TIF are not always
fully supported by other applications, maybe PNG is a somewhat better choice (PNG
is in fact supported by Netscape/2).
A last word on image sizes, it is
not always essential to get the whole of an application, maybe it is only one item
of an application you are interested in, then limit yourself to that part. Every
extra stuff included only mess things up. And the image size increases.
What do I do if my image really is too big
Then you create a "thumb nail",
use your image editor to transform to a smaller picture and save that as a originalImage_small image,
that you use at the web page but that also works as a link to the full sized image.
Or, capture an interesting part of the image to use as that link. This technique
may be used in two circumstances, when the image size is big, or when the file size
is big and cannot get reduced. Then it is always better having a link to the bigger
image and let the reader do the decision if to download that image or not. Do not
forget to tell the reader the image and file sizes.
If the image
is of photo quality, please see above under "How to be provident?"
and then try "Save as" and choose the JPG file format, go to "Options"
and you will see the dialog box shown here. PMView recommend a "Quality"
of 75% and I recommend you to use the "Optimize entropy encoding" that
further reduces the file size. The "Smoothing" can help both to give you
better results, filtering away noises, and lessen the file size.
Then it is safe to "Save"
from the "File save" dialog box. Under "View" => "Show"
you check the "Image Info" option and then you may see the actual file
size. Keep this box open when you experiment with different "Quality"
and "Smoothing". Unfortunately you can not see the file size until you
actually saved the file, and that way destroyed the one you had before. Fortunately
the "Undo (Ctrl+Z)" works (PMView folks, a suggestion is an option to
compute the future file size in advance).
Some applications support the "Progressive
JPEG" that when used over a network sends the image in scans that the image
will be sharper as the times goes. If you do not know if this feature is supported
or not, leave it unchecked.
Once you have found the most optimal
mix of settings, combined with the file size, you are done.
the image is a screen capture of an application, a terminal, a dialog box
or similar, I am certain you can save the copy as a GIF. Then you choose "Color" => "Convert to" => "Indexed
256-Color (8-bit) ..." and another dialog will show up. I will discuss
the options to some extent.
To the left you see "Palette
type" and five options. Talking screen captures of applications I recommend
"6-6-6 levels" that will give you a good file size without too much quality
loss (see discussion above). And best, you do not have to do so much tinkering yourself
later on, but still it is you that have to try and see.
The "Adaptive" may be combined
with "Number of colors" and will try to adapt to some average values,
depending on the image colors. Experiment with it and see if you like the result
better than the "6-6-6 levels" option. If you then choose the "Dither
type" "None" the adaption will go on a best match basis. The other
two will try to compensate for color errors that the adaption introduces. I have
experimented a lot with different settings of ditherings and color of numbers but
ended up mostly using the "6-6-6 levels".
the "6-6-6 levels" you most seldom have to edit the color palette manually,
maybe only look at it to see if every color is essential, else change it to a nearby
shade. But if you used some other option you really have to edit the color palette.
The color palette is found by "Color" => "Edit Palette".
You simply choose your color and
then adjust the sliders to the value you wish. When using the "Adaptive"
option you will find white not being white (255, 255, 255) and black not black,
and lots of colors to edit. Many shades are really close to each other and may be
joined to one shade. This tinkering is hardly fun, but if you really like to get
the minimum file size it may be essential. Now you might understand why I
recommend the "6-6-6 levels" option that practically takes that work away,
and you get "web safe colors" into the bargain.
Reduce the numbers of images, only use
them that are essential to the web page
Reduce the file size of the image by
Finding the proper file format
Screen captures are saved as GIF
Photo quality images are saved as JPG
or GIF, whichever has the lesser foot print
GIF file format:
Reduce the numbers of colors as far
as possible with reasonable quality loss
JPG file format:
Find a good combination of "Quality"
Save using "Optimize entropy encoding"
Adding images to your page
Adding images is as simple as to add
a tag to the html code. The image tag looks like:
The result will look like this. That is, the default
is to put the following text at the bottom line of the image and the image will
be placed to your left.
Adding an extension to the tag - ALIGN=MIDDLE -
will give this result. But interestingly the text will not continue were we would
like it to continue, and hence this extension to the tag is seldom used. If this
is not properly shown here your window is too wide, please resize it for a while.
And the extension
ALIGN=TOP will not too surprisingly
give this result. But interestingly the text will not continue were we would like
it to continue, and hence this extension to the tag is seldom used. If this is not
properly shown here your window is too wide, please resize it for a while.
<IMG SRC="howtohtml-color2.gif" WIDTH=270 HEIGHT=235
BORDER=5 ALIGN=LEFT ALT="Image text" HSPACE=25 VSPACE=1>
tag is more of what we use, but some values are exaggerated to illustrate the effect
they have. The order of the extensions is not at all important.
One of the most important extensions
are the WIDTH and HEIGHT that
tell the browser the dimension of the image. With that information the browser may
allocate space on the page for not yet downloaded images and thus show the text
much faster. If not, the browser has to wait until the download is initiated and
that much of the file is read that the image's header can tell the browser these
values. You simply have to wait until that information is available.
How can you tell these values if
you have no image editor open to see? Open only the image in Netscape and
it is told in the browser's title bar.
normally set to zero, or omitted since default is zero. But if you would like to
use the image as a link to another resource, then a border is appropriate since
else the link is almost invisible. I suggest a size of 2, but anything works.
extension may also be set
to LEFT or RIGHT, and
then the text flows at the free side of the image as we normally would like it to.
you an opportunity to introduce an alternative text that is visible when the image
did not load, the reader turned image downloading off or, in Netscape/2, when you
move your mouse pointer over the image. Note that the text is enclosed by quote
The two extensions
VSPACE add extra pixels
at the Horizontal and the Vertical directions of the image, both sides.
Else the text will flow as close as possible to the image as is seen in the first
three basic examples.
Whenever your site grows it is a good
idea to store your images in a separate directory or folder. The principle to point
to such a stock-room is as simple as to point to nearby web pages. Here comes some
The topmost is the previous example
and points to an image residing in the same directory as the page is (the working
directory). Next line is first directing the browser to a directory in the working
directory named "images" and then to the file in that directory. Then
a line were the browser has to climb upwards one level closer to the root and there
find the directory to dive into. Fourth line is simply to climb two levels closer
to the root before diving into the directory of your choice. It is also possible
to climb downwards as in the next line, first up one level and then into "images"
only to dive into "articles" to find the image there. All these examples
are relative paths.
The last example is a direct path
or full path. It is simply the full URL to an image that do not have to reside
on the same site as your web page is. You are free to point to any image you like
to, but you are not free to use the image as if it is your own. Hence you have to
tell the reader who the owner is, thus not violating any copyrights (that is you
act as a private person, and the mileage of your country may vary).
How to make my image a link?
Last month we learned how to add links
to a page and this is as simple. This code will give us the image-link seen below:
<A HREF="../20000916/java9.htm"><IMG SRC="../20000916/java9.gif"
BORDER=2 ALIGN=LEFT HSPACE=5 VSPACE=1></A>
simply encompass the image tag, that is one tag but rather lengthy, with the normal <A HREF=" ... "> and </A> tags. The URL may be relative or a full URL,
that is no problem.
I will not go into how to make image
maps, how to add several links to one sole image. If you do not know what it is,
think of a map of Europe and as you move the mouse pointer over different countries
the links change dynamically. (Anyone around to write about that and about OS/2
image-map tools? Then write to Wright!)
This time we have only dealt with images,
and still there is more to say about them. There are, as said, image maps, animated
GIFs, resized images on the client side, transparency, interlaced images and much
more. Please start with the tags we have discussed this month and then the best
way to learn more is to use the "View" => "Page Source"
to see how nice pages are set up.
Next month we will finish these three
articles with a look on how to do the layout on web pages, "how do they do
that with basic html code?" Stay tuned.
speed on cables we are not talking bytes but bits. Consider a byte being
set up by 8 bits, in fact that is not all of the truth but not to confuse the laymen
we will say a byte sent through the line is 8 bits. Adding some headers to each
data packet sent and the hand shaking procedure each new item wanted, there is a
not negligible overhead added to the traffic. That is, 28.8 kbit is less than 3,300
bytes (3.3 kB) a second, 56 kbit is less than 7 kB/s, handshaking time excluded.
-- Go back