Hi Olav,

If you don't need an automated solution, Adobe Acrobat (not the reader) can do most of what you want. However, we found that Adobe does not expose enough of the acrobat funtionality in their API to automate this properly. It cost us a $1000 adobe asn developer membership and hours of back and forth to get this out of them. Here's (at long last) a quote from Acrobat Developer Support:

"Be that as it may, the functionality of these menu items is, as you
know, not truly programmatically accessible from the APIs. You can
programmatically invoke the menu items, but must still deal with any
dialogs, etc., that would normally come up.

I logged your issue as a feature request and it will be considered
for any future releases of Acrobat."

We found it very difficult to find any non-vaporware product (<20K) that proported to meet our needs so we rolled our own.

In the end, we took an approach that involved using VFP as the "glue" between wget: http://www.gnu.org/software/wget/wget.html, Amyuni PDF Suite: www.vbxtras.com/products/pdfsuite.asp and some custom parsing VFP routines to deal with page order, bookmarks, image maps and workaround for bugs in the Amyuni tools etc.

One of the issues to rememember is that web pages (which are non-linear in nature) are not typically isomorphic with books (which are typically linear, front-to-back things). So, apart from all the processing code, we had to think conceptually about how to present a web-site (in our case knowledge bases implemented in wiki technology)

You can see some of the results here:
http://cisnet.cancer.gov/profiles/

Having done this and stepping back, I would say that it may have been better to build the pdfs directly via VFP reports rather than to go through the HTML-to-browser/print driver-to-PDF. But we really wanted to leverage CSS/HTML in the look and feel of the pages and in order to render the pages faithfully a standards-compliant browser (or something close to it) is needed. Amyuni uses IE which worked ok for our purposes. If layout is not an issue and you control the content, then it would be much simpler to build the pdfs more directly. And I should add, the wget step was simply used for expediency, in the future we can generate the HTML directly from the content in the database and skip the crawling step.

So, all of this to say, it is possible to build what you are looking for, but I am not aware of any out of the box tools that will provide complete control over the Web-to-PDF process.

-lc