PAINT SHOP PRO
Page 1
There are a number of ways to put little buttons, as it were, or
multiple changing images
in the middle of a larger image.
And more ways are being promoted, every week, for the world wide web,
and graphical displays/browsers - using assorted plug-ins or new features.
But the old reliable throwback is still the use of
tables - first introduced by Netscape, when it was an independent company,
in the early 1990s.
The larger image is 'sliced up', into little blocks.
And then each block is treated as an image that can
change without having to reload the window.
Each little block is placed in a cell, within an HTML table,
and so the larger image is pieced back together.
[Take a look at the
W3C reference on tables, for the commands/tags and parameters/attributes
used to create HTML tables.
Another page, as well, covers this at a
basic level.]
When using PSP 7 to slice up an image for such independent little cells,
I discovered that the programmer's had decided to
avoid nested tables - which are fairly intuitive.
They used, instead, another method, which is really
what this, following, is all about.
Consider a specific example.
The table was used for many years on the home page for this very site.
First, some explanation about what you're seeing, and why it was sliced up this way:
- There are 13 different cells visible
- Run the mouse over the image to see how PSP 7,
File, Export, Image Slicer, can be used to slice it up.
The 'background' colors in each cell, obviously, are also used to help
emphsize those same slices.
- The table can be thought of as having two lines, or rows,
with the top cell taking up the entire top row.
That's sort of how it appears on first glance.
But it's better to look at the whole table, with row 1 at the top, and
a number of rows below that, which aren't as tall, or as high.
Turns out, there are actually seven rows, in all - which will be explained later.
- About the bottom fifth of that large, elliptical logo hangs
over the bottom of the top row, and into a lower row which contains the E and the R
(since they 'ride up' so high on the side).
That bottom center bit of the logo is broken up into three smaller pieces, for
each column for the three letters in the middle. Not that's not necessary,
since the entire bottom bit could be placed in a single cell, above those
three letters. And, in addition, bringing down the center cell (lime green) so that is was
not even with the two on either side, and so you couldn't
put the bottom center in just one cell, was also unnecessary.
- And similarly, the bottom part, below all the letters except for, T,
were cut out separately - but it's also unnecessary.
- That's 6 unnecessary cells - why? For the same reason.
The rollovers on those letters work only when you run the mouse over that
cell. And keeping the cell border close to the edges of the letter means
that the animation stops and starts pretty much only if you are over the letter, itself,
not merely somewhere off nearby, or below it. That's the only reason.
Appearance.
[Some might suggest that an image map could be used on the letters,
with polygons precisely surrounding them. That approach would void the
need for any table at all, however - and with that, this tutorial.]
- You still might wonder why the space under the R is down so far.
If it were taller, the left bit would pick up some of the bottom of the E
(
).
As it is, the R cell includes just a fraction of the E.
So it was either that, or put the bit of the E in the cell below R.
Put it in R, for purposes of this example, to add even more rows to the table.
Okay.
Now, just as in a spreadsheet, or any chart or table, the cells
are defined by straight rows and columns.
But below the first row, here, the cells are offset at different heights,
and don't match up, side to side.
One solution - place inside of tables.
It's called, nesting, of tables.
Each letter would be part of its own separate table.
Call the big table, table #1.
Top row has one cell.
Bottom row has five adjacent cells.
Each of those cells has a table.
So there's a table for each separate column in the second row.
Problem solved.
You wouldn't have to worry about uneven adjacent cells, as seen here:
And this is clean, intuitive.
It makes sense.
12 cells in 5 nested tables.
But it is five nested tables.
And some might be concerned that this puts too much overhead
on browsers to display things correctly.
What's the alternative?
