Note that I've also posted a separate but related question about the DPI of these generated images. It includes some sample code and an indication of where I could call the .Dispose() method on images.
Link: http://essentialobjects.com/forum/postst9568_HtmlToPdf--higher-DPI.aspx

Thank you for the reply.

I had a big reply typed out but lost it :( arrgh

Short version - won't be quite as well-worded

Could you please call out this method in the documentation. I call an overload of ConvertUrl that returns a HtmlToPdfResult so it didn't even occur to me there'd be a reference to this result held within a static property on the class. Searching the *.chm of the latest version for ClearResult shows it in the method listing but no helpful pointers to "you should really call this to avoid holding on to chunks of memory".

Also, the ClearResult method seems to do exactly that - set Result to null. It doesn't do anything specifically about the images. I appreciate the garbage collector's finalizer queue will get to them eventually but making the resource ownership more clear would be great. The ship has sailed on the behaviour of the library as doing disposal of generated images in ClearResult would be a breaking change. However would you consider either
a) Adding to the 2 or 3 places in the docs that refer to GeneratePageImages that calling ClearResult is important and that the caller is responsible for disposing of these images (and that it's safe for the caller to do so); and/or
b) Adding an overload of ClearResult with a boolean parameter indicating whether or not any generated images should also be disposed.

Being able to invoke HtmlToPdf non-statically might make this a bit more clear too as it would really clarify ownership without having global state protected by what I assume must be ThreadStatics or ThreadLocals. I can call new on HtmlToPdf but there aren't any useful non-static methods anyway. Should you mark the class static?

I hope you see this (shortened and unfortunately terse) feedback as constructive rather than as criticism. I really appreciate the magic your library facilitates :)
Thank you!

A quick bit of real world feedback

This has taken a web app that routinely held on to 3GB of RAM (according to task manager) down to holding on to around 500MB of RAM. It's probably an extreme case but the last time I examined a dump when users reported issues I found 40+ instances of HtmlToPdfResult (each of which would have been anchoring 2-3 full-page colour Bitmap instances in RAM) even though I was expecting perhaps 1 instance of HtmlToPdfResult at the most. It was this discrepancy which led to me asking the disposal question in the first place.

Anyway, I'm very happy with the improvement gained after specifically disposing images and then clearing the static .Result property. Thanks for the help :D