So now what? We don't use nested tables, which are convenient, easy to follow, understand, and maintain. Like the old APL, perhaps, the alternative method is 'more elegant'. In fact, one might even argue it's simpler, more straightforward, and cleaner than nested tables - but only once you get used to it.
 
In addition, and I thank Rick Simon for making this clear to me, the PSP 7 image slicer algorithm is much simpler to program if generating this alternate method rather than if it were to generate nested tables. Would the 'nesting' be dumb or smart, unweildy, and so on? And nesting can become taxing on the browser, and memory, and the computer if carried too far, particularly if inserted into an existing table which is already nested.
 
At any rate, this presents the problem of trying to draw the table in one shot, with all those staggered, uneven cells. We could begin by further chopping things up to get each cell clearly defined, and all the rows and columns showing, as it were. If you were to cut the table up straight across, you'd get a lot more cells:

Working your way up and down in that second row, you'd draw across a little colored zone each time you hit a new vertical line, anywhere across. Try that here and you get 6 ribbons, or 6 rows altogether. Six rows, split into five columns is - that's right - 30 cells! That's a lot. And that's a lot of server overhead, if the server need a separate call for each image. It's just not very good. I mean, the straightforward method would be to slice up four of the letters into 4 separate images - EACH - and 3 for the E. Very messy.
 
But there is a way to use basically the same 12 cells as with nested tables, just by adding a few more - four in this case, as a sort of a 'glue'. Do that, and you can display the table without any nesting, uneven cells and all.
 
How so? Well . . . and as mentioned in the URLs given for HTML table reference on page 1, a table cell can bridge adjacent cells by, spanning. As in a spreadsheet, cells can be combined into a larger cell, but still on the row and column boundries established by the remaining cells in the table. It's just for that cell, the row or column lines are not displayed. It is made to span a couple of rows or columns.

 

[For explanation of 'dots' effect]

The HTML argument or attribute for spanning columns is - COLSPAN. For rows it's - ROWSPAN. Take the same table from the top of this page. That first row, the top row, which is just one cell, spans 5 different cells in the rows, below. Five columns. So - sure enough - the top cell actually does use the attribute: COLSPAN=5. That way the table is drawn correctly.
 
Let's say, in the PSP slicer, that you erased the short horizontal lines below the first row of the table, but left the one above the T. There would be a narrow horizontal red line above T, but none above or below the other four letters; that is, the center column would have two cells. The other four columns would just be single cells. Each of those four would, span, the two cells - the two rows - established by the middle column. So when creating the HTML table, each of the cells - the two E's, the N and the R - would also include the attribute: ROWSPAN=2.

But you're saying to yourself - this is different. If you just leave the line above the T, then you can imagine it running out to the left and right, splitting the other four columns. Easy. Everything lines up. But if you do that with all the existing lines, here, you get those six rows, in five columns, for 30 cells in all. And that's just not good.
 
So, then, let's continue with how the table is laid out, without nesting, using only ROWSPAN and COLSPAN, and a couple of 'phantom' cells.