title: Printing HTML, with faithful CSS formatting, from IE/Delphi?
body: <p>I've got a small program that displays third-party generated HTML pages. It's really just a wrapper around a locked-down TWebBrowser component (which is just an IE wrapper, I believe).</p>
  
  <p>The client wants to print these pages now too - but the TWebBrowser print method doesn't render all of the CSS. For instance, where the client uses blocks of background colour, I just get the background colour. You can actually see this on some websites when you get IE to print the pages and some of the CSS-type formatting disappears.</p>
  
  <p>I originally convinced myself (stupidly) that the problem was because the CSS was an external reference, but after I'd made the CSS internal to the .HTML file the problem remained.</p>
  
  <p>Is there a component or technique I can use to get printed output that includes this CSS formatting? I wondered about trying to turn the browser page into a PDF first (that would have other advantages for me too, later) but I don't see any obvious way of doing that either.</p>
  
  <p><b>I guess really I'm saying - <i>printed output from IE sucks, is there a way of getting a better approximation of what you see on-screen?</i> :-)</b></p>
  
  <p><i>edit:</i> Okay, moved this on now. I can persuade the printed output to include the CSS colour elements, thanks to Will and Onnodb's suggestions - my sample page prints okay, and given that the user understands the significance of the registry setting approach, he's happy to go that way with it (it's going to be used on at most a half-dozen desktops in a locked-down corporate-type office). </p>
  
  <p>My problem now (which might itself become a new S/O post) is that there's something in their HTML/CSS that is killing IE. Firefox is happy to print it all out just fine (and so does Safari), but IE 7 and 8 will both show a print-preview of the pages but die during 'real' printing. </p>
  
  <p>Given that replacing <i>TWebBrowser</i> with some kind of <i>TGeckoBrowser(!)</i> is probably more trouble than it's worth (and might not fly with the client), I'll have to try and figure out what bit of the (nasty, convoluted) formatting code is causing the problem. There are a multitude of DIVs in there with a mixture of relative and absolute positions... :-)</p>