What does a non-nested, uneven celled table look like? Once again, from page 1:

 
 

Examine the table by moving the mouse over a cell. Info will appear in the area below. Each of the six 'ribbons' do not appear to be separately defined, here. But notice that the ROWSPAN for each cell matches the slices from the 'ribbon' view. The left E would have been split 3 ways, into 3 slices. Here, ROWSPAN for the left E is 3. The other four letters have a row span of 4. The area under the left E was three rows high. Here it has a row span of 3. Bottom of logo and area under the R - span two rows.
 
Now to lay the cells into the table. The left E is column 1, row 2, as you'd expect. It's the first cell in that row. Run the mouse, just below the top row, over the other four cells. It shows, row 2, for each and that the column and cell are equal. But . . . mouse over the N. Now the cell and column are not equal. The column is 2, as you see in the table. But it says it's the first cell in the row three. How's that?
 
The table is filled out left to right by default. Column 1, then to column 2 to the right, and so on. That is, until the next new row - the HTML for that being <TR>, the row tag. Consider this note, from W3C.

"the number of rows in a table is equal to the number of TR elements contained by the TABLE"
  [ W3C Recommendation, HTML 4.01 Specification: Tables ]

Let's say that this has been a pretty consistent 'recommendation', from back in the HTML 2 days. The number of rows is to be unambiguously determined by the number of <TR>'s use to create the HTML table. In the example, here, it's seven. A row is started for the top cell, another to start the second row. If five more row tags are used, then you get the six 'ribbons', even if unspecified. The left E is placed in row 2, spanning three rows. A cell wouldn't go below that E until the 5th row. The second column gets the lower left of the logo. Then over to the bottom logo, lower right logo, and the letter R. That establishes five columns. In order to put the N next to the E, and below the lower left logo, it would have to be one row down. It would take a new row tag.
 
With each new row tag, the browser is programmed to find the first 'empty' column down, in which to start - left to right. And since E is spanning rows 2-4, that column isn't empty, yet. So, because of spanning, the first cell of row 3 goes in, column two. Now the next established column to the right contains part of the bottom logo hanging down into where the third row cell would go. The column is not yet 'empty'. So move right to the next cell, and the right E is placed there. And so on. The browser or device should be able to calculate, as it were, each row, without any more information. It should calculate those six 'ribbons', basically, given just the row and column span information.
 
And that's good enough for Microsoft's Internet Explorer (IE), at least version 3, for Opera, at least the old beta 3, and for whatever else. But not for Netscape Navigator (NN) - not version 2 (which I still also have) - and not version 3, not 4.7, and not version 6. Surprizingly, it's not true for the 'latest' IE 5.5, either, which previous versions hadn't been 'broken'. So, for NN, and the latest IE . . . there's some extra bits that are needed. These are, perhaps, 'phantom' cells. And they are used to explicitly define the height of those rows otherwise implied.
 
PSP 7's image slicer, in fact, adds thin transparent cells, 'hanging' off the table on the right, each with the exact height of every row in the table, implied or not. In this example, PSP 7 generates seven of these thin 'spacer'/definition images. The only real confusion for Netscape, though, in this example, begins on row three. That's where the rows, the row height, stops being established explicitly. And the bottom row is also clearly defined by the two yellow blocks. So really, only 4 of these spacers are absolutely needed; and they are shown wider, here, than on page 1, just so you can get the mouse over them, for the popup info.
 
Now how is that they . . . 'hang'? From the same W3C page, above:

"user agents should base the number of columns on what is required by the rows. The number of columns is equal to the number of columns required by the row with the most columns, including cells that span multiple columns."

To rephrase - the number of columns is determined by which row has the most columns/cells, and a colspan counts as that many columns/cells. If a row has four cells, but one spans 3 columns, that would be 7 columns in all, for example. The top cell, in this example, spans five columns. Those columns widths are established by row 2. But you can just keep adding more cells to the right, on any particular row, and it won't matter. You literally can 'hang', seemingly, a cell off on the right like a little flag. It's an illusion, here, because what appears to be the entire table, becomes only part of the table when cells are added on the right; the 'spacer's in this case. The table gets bigger. And whichever row now has the most cells (including spans), determines the number of columns for the table. However . . . since a border is not used with sliced up images, like this, you see just a box, with stuff hanging off, so it seems, not the larger rectangular table. You are expecting to see a table, and so you see one.
 
In other words, if you change the COLSPAN for the top cell from 5, down to 3, it 'pushes' the 4th and 5th columns off to the right, where they hold together just fine, but appear to be displaced. Since there's no border, it appears as if these columns are pushed . . off to the side. But they're still - 'in the box' (which is made clear at the bottom of the next page). At COLSPAN=5, the important stuff on the table holds together, and any number of columns can be added off to the right.
 
So, by adding height specification cells, PSP 7 gets browsers to respect the row spans indicated in the table. It's a similar case where column 'spacers' are required to correct the case when column spans remove a column which before had been uniquely defined.
 
Let's consider a final example, then.