window.print

[GerryM]

I have an unusual problem with printing tables using window.print from an .asp page.. The printer works fine otherwise. Let me describe the Table Printing Problem in more detail:

Assume I have a table of 156 rows and 2 columns. Using 7 pt font size a page header + a table header + 55 rows are printed (correctly) on the 1st page, a page header + 63 rows are printed (correctly) on the second page, and a page header + 38 rows are printed on the 3rd page except that the entry for the cell in row 1, column 1 (row 119 of the original table) is not printed; all other cellls are printed correctly.

If I increase the font size then only 38 rows of the table are printed on the first page but the entry in row 1, column 1 of the 2nd page (row 39 of the original table) is not printed, and incidentally the row 1, column 1 entries of pages 3 and 4 are also not printed, while all other table entries are printed ok. This pretty much proves to me that it is not some peculiar contents in a specific table cell.

The behavior is not consistent. In other tests, the entry in row 1, column 1 of page 2 is not printed; or the entries in row 1, column 1 of pages 2 and 3 are not printed. But in all cases, the remaining entries on those pages are printed ok.

I'm using Windows XP Professional SP3, an HP5510 printer, and have reinstalled the most recent printer driver from HP.

What may be the problem?

GerryM

[Old Pedant]

Well, for starter, this isn't an ASP question. It's strictly an HTML/CSS question.

And might even be a browser-specific question. (Have you tried the same thing with other browsers?)

Probably the big question is: Are *you* controlling where the page breaks will occur or are you relying on the browser/printer driver to do that for you?

[GerryM]

Thanks for the help -- I was guessing where to post this.
And I was relying on the browser/printer driver to do the page breaks.

I'll re-post this question in the html/css forum.

Thanks,

GerryM

[Old Pedant]

Well, I asked the question re page breaks becuz you *could* force them in there where you want them.

It's still html/css, but you can use ASP logic as to where to put the breaks.

For example, when you determine that you have enough lines output to fill a printed page, or nearly so, you can just output something like
<tr style="page-break-before: always;"> ...

I'm not sure that's going to fix the problem, but it's worth a shot. And in any case I'd try using a different browser to see if it's a browser bug.

[GerryM]

I hate to admit this but putting page breaks in by hand is pretty tedious since it would be different for every table. Also, I am afraid it may not fix the problem because (a) the page header is printed ok, and (b) the borders of the blank table cell are printed ok; it's just the cell contents that's missing.

I may try it nevertheless.

Thanks,

GerryM

[Old Pedant]

I didn't mean literally "by hand". I kind of assumed you are creating rows or lines of some kind in a loop in ASP. So the idea would be to have the ASP code dump in the forced break after every NN lines/rows/whatever. If you erred on the side of safety, your pages might be a little short but would hopefully at least have complete info.

In any case, it might be worth trying one of these truly manually just to see if it works.

[GerryM]

You are of course right. It would depend on the font size, but nothing truly challenging. Ill try it.

Thanks,

GerryM

[GerryM]

Wow! That work-around made the problem go away! Thanks a million for the suggestion; it's a trivial change to the program.

Being an engineer, however, I still would like to know which program is responsible for the problem: the browser, asp; window.print (i.e. javascript), or something else?

Thanks again!

GerryM

[GerryM]

By the way, the work-around you suggested also fixed a cosmetic flaw that had always annoyed me: the last row on a page was followed by half-height cell borders, and the first row of the next page had no cell top borders and partial cell side borders. After the fix, the last row on a page ends with cell bottoms, and the first row of the next page starts with complete cell tops. Fantastic. Looks the way it should look.

Still, I think the handling of page breaks in tables by the browser / window.print / whatever is not acceptable. Whom do I blame???

Thanks,

GerryM

[GerryM]

An afterthought: What I called a "cosmetic flaw" actually looks like the cause of the problem: Whichever part of the browser is responsible for determining whether a page break is needed is doing it too late. It started printing the side borders of the next table row on the bottom of the page, THEN discovers that a page break is needed, and finishes printing the row at the top of the next page. Why the contents of of the leftmost cell gets lost most, but not all, of the time is another good question which will probably resolve itself when the page break determination is fixed.

Ain't programming wonderful?

Cheers,

GerryM