IE6 Print Preview Problem

IE6 does not understand as much CSS as the later versions, especially if you use CSS syntax which appeared AFTER IE6 was released. In that case you won't have any possible workaround by tweaking the browser, so you'll need to debug your code and replace the unsupported CSS with something that the old IE6 understand.

A great reference guide to what is supported and what is not is found at W3Schools

Thank you. But I question the cause being one of CSS syntax. The page structures are repetative in nature so page 1 is the same CSS structure as page 45. The IE6 browser dies at page 36. The first 35 pages are fine.

It sure sounds like the browser has run out of some internal resource when it tries to render the report.

Oh, so you have a browser crash or hang... then you can only try to isolate the problem by reproducing it under different, controlled situations. For instance, make previews of your HTML page swapping the crashing page with the following and/or previous one, add and then remove some content from the early pages to see whether resource exhaustion is to blame, delete the first page and see if IE6 displays one more page, compare all these results with IE7, etc. You are looking for some offending content, or else proof that whatever content you have, it always crashes when the page count is high (or character count, etc.)

You do need to do all these trial and error because even if you finally confirm it's an IE6 bug, I seriously doubt that Microsoft puts any free effort into fixing a browser which is more than 10 years old. In other words, you are on your own... after you isolate the problem you either adjust your page to fit a buggy browser, or you use your tests as evidence of the need to upgrade the browser.

OK .. I physically copy/pasted pages 34-45 from their original position to immediately after page 1 and they rendered correctly in the print preview. However, now pages 26-33 do not appear. The rendering appears to die about 34 pages into the report. I think that this confirms that it is not the structure of the html document that is the issue but rather a limitiation of IE6 itself.

I know that with other report writers (eg Crystal) the report preview function attempts to render the report in memory. Whe you are viewing page 1 of 45, only page #1 has been rendered. But as you scroll to the end of the report (page by page), more and more of the report is rendered in memory when you are viewing page 45 for example, pages 1-44 are also in memory. Is this the same approach used by IE??

What I am looking for is some documented physical limitation of IE6 (preferably from Microsoft) that would help me convince the customer to upgrade. IE. As you can imagine, an upgrade such as this for a major financial institution is not a trivial exercise.

Any thoughts?

Every preview function has to render the report in memory, and it also must render all pages previous to the one you are looking at because it's the only way to tell how much content has been consumed by them. For instance, if you enlarge the page size from A4 to Legal, more content will fit on each page. So if you then go to the last page, it will force everything to be rendered again just to know what content is left at that point.

Now, if you perform similar tests on machines with different RAM and get consistent results with a fully patched IE6, that ought to be enough to convince your customer. Check out this hotfix, it might apply to your scenario: http://support.microsoft.com/kb/913788

Try some more situations to determine whether you are hitting a limit on the number of bytes, or pages, or RAM, or newlines. Changing only one of those things as much as you can without disturbing all the others will help you be more precise when you present your findings to your customer. Don't make any claim before getting solid evidence to support it.

Finally, take a look at http://stackoverflow.com/questions/3333284/infinite-loop-in-ie6-print-preview. You have a minimal testcase which is presented as an IE6 print preview crasher. Just showing that to your customer should be enough ;-)

I've done some research and I think I need to re-phrase my question. As a test, I have re-generated my CSS report with 10,000 lines (200 pages) to see if I could find an upper limit and I was able to duplicate the same truncation issue in IE8 as I was having in IE6. The limitation, it would appear, is still there in IE8, it's just a higher limit.

As I understand it, each report object is an instantiation of a class. In the 10,000 line report there are 201 pages and 32,617 class instantiations (I counted the "Class=" statements in the CSS file).

Through trial and error, I determined that only 118 pages (5,897 lines) and 19,232 class instantiations appear in the IE8 browser window. Only 55 pages (2,747 lines) and 8,963 classes appear in the print preview.

The issue appears to be with the architecture of the report itself. The CSS architecture is fine for smaller reports but not large ones.

I guess have 2 choices, rewrite my report to not use CSS or somehow to convert the CSS report file to strip out the style sheets. Is there such a CSS to HTML conversion utility out there somewhere?

Does anyone have another alternative?

Have you explored media types? You can apply most CSS tags to your HTML when it's rendered on screen, and only the CSS that you cannot possibly live without when it's rendered for the printer. Check it out here: http://www.w3schools.com/CSS/css_mediatypes.asp

Thank you Akenathon but at the moment we have an application that generates these types of CSS documents and we don't have time to re-design the architecture progeram that creates these documents right now.

I ran another test to confirm my earlier theory about the problem being with the number of instantiated clases. I doubled the amount of report objects on a page (i.e.classes) thinking that I would get half the number of pages. Instead I got the same number of pages (55) being displayed and the same number of pages being print previewed (36). This would lead me to surmise that the limitation is on the number of pages and not on the number of instantiated report objects in the report as I had earlier thought.

Some of the literature out there seems to indicate that the limitation can be overcome by converting the tags to unline html. There are some post-processor utilities out there that are available?

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.