What page-image generating technology should I use?

Question

I'm building a desktop application right now that presents its human-readable output as XHTML displayed in a WebBrowser control. Eventually, this output is going to have to be converted from an XHTML file to a document image in an imaging system. Unlike XHTML documents, the document image has to be divided into physical pages; additionally - and this is the part that's killing me - there need to be headers and footers on these pages.

Much as I would like to, I can't simply make the WebBrowser print to a file - the header/footer options it supports aren't anywhere near sophisticated enough. So I'm casting about trying to figure out what the right technology is for generating these images.

It seems likely to me (though it's not mandatory) that what I'll end up doing is producing PDF versions of the HTML documents (so that I can add headers and footers) and then rendering the PDFs as TIFFs, which is the ultimate format that the imaging system wants. So what I'm considering:

• Use some kind of XHTML-to-PDF conversion software. The problem with this is that without doing a lot of evaluation and testing I can't figure out if the products I've looked at even have the ability to do what I need, which is to take existing XHTML documents, decorate them with headers and footers and paginate them.

• Use XSL-FO to generate the PDFs. Being a ninja-level XSLT geek helps here (that's how I'm producing the XHTML in the first place), but it still seems like an awkward and slow solution with a lot of moving parts. Also this means I'm sticking a big clunky Java program into the middle of my nice clean .NET system, though I'm certainly enough of a grownup to do that if it's the right answer.

• Use some other technology that I haven't even thought of yet, like LaTeX. Maybe there's some miraculous page-imaging tool that turns XHTML directly into TIFFs with page headers and footers. That would be ideal.

My primary concerns are:

• I'm building a commercial product; whatever technology I use needs to be affordable and supportable. It doesn't have to be free.

• I don't want to disappear down a rabbit hole for three months banging on this stuff to get it to work. This intuitively seems like the kind of problem space where I can lose a lot of time just evaluating and rejecting tools.

• Whatever solution I adopt needs to be relatively immune to formatting changes in the XHTML. The whole reason I'm using XSLT and producing XHTML in the first place is that the documents I'm producing are being dynamically assembled using business rules that change all the time.

I've spent a lot of time searching for alternatives and haven't found anything that's obviously the answer. But maybe one of you fine people has already solved this problem, and if so, I would like to stand on your shoulders.

Answer 1

have you thought about using postscript?

ps: what kind of headers/footers you need - your custom ones to put pages in between? if so, postscript or PDF is probably the best. but it will be very difficult to create xhtml+css to pdf converter. basically, you would need to have library that is able to parse both xhtml and css (+any objects such as images, flash etc.)

Answer 2

PrinceXML is an XHTML/CSS to PDF converter. It seems to have the features you need:

• Page headers/footers, page numbering and duplex printing.

I realize you'll probably want more extensive answers than this one (I'm sorry, but I haven't evaluated the product), but nevertheless, I hope it helps!

Answer 3

If tiff is your goal, this might be a free and low risk approach:

1. Use a component to create an image for a given url. I'm not sure which tool we used for it, but GIYF: I just stumbled upon SmallSharpTool's WebPreview that seems to do the job
2. Make sure it can create an image of the entire page, ie the entire's scrollable area.
3. Use ImageMagick to do all the image manipulation, such as cutting it into multiple pages, adding your own headers, footers and page numbering and conversion to tiff.

I have personally used the above techniques separately in C# projects (console apps and websites) with success so I can almost guarantee this will work.

Answer 4

Edit (2009-03-29 9:00 AM PST) Posted sample conversion.

Edit (2009-03-23 12:30 PM PST, published to CodePlex) I developed a solution for this and posted it to CodePlex. The published version 2.0 is written using the WPF MVVP pattern. TIFF files (one per page) are output to c:\Temp\XhtmlToTiff. XAML and XPS formats are created as well. A compiled,installable version is available at CricketSoft.com

---

Have you tried the "Microsoft XPS Document Writer"? This a software-only printer that generates paged output from a variety of sources, including web pages.

There is an SDK for working with XPS documents and Open XML docs in general. Here is a How-to article by Beth Massi: "Accessing Open XML Document Parts with the Open XML SDK".

+tom

Answer 5

It all depends on how important quality is for the generated documents. It also matters what other operations you need to do with the document.

I'm building a desktop application right now that presents its human-readable output as XHTML displayed in a WebBrowser control. Eventually, this output is going to have to be converted from an XHTML file to a document image in an imaging system.

Looks like your application is a soft-form of sorts. You generate filled-in forms and save them.

[...]there need to be headers and footers on these pages.

This is the easy part. You can use templates and merge the data with the static header/footer template. You sound as if you are doing VDP. Hm. Let's move on.

I can't simply make the WebBrowser print to a file - the header/footer options it supports aren't anywhere near sophisticated enough.

Why so? All you need is a capable driver.

It seems likely to me (though it's not mandatory) that what I'll end up doing is producing PDF versions of the HTML documents

Again, it is not clear why you would want PDF right away. PDF is a document interchange format. Not a PDL per se. PostScript is a much better choice. Yes, I know there are things like XPS, PCL and what not. However, the amount of rendering control and quality you get with PS is far too much to risk a cheaper solution. I say cheaper, because, you also need to keep in mind the sort of printing you can avail of. PostScript printers (not the ones with the clone RIPs) are costlier in general.

Now, back to your PDF thing. Yes, of course you can generate PDF. It has certain advantages like:

• Better support for transparency (and in general quality)
• Archival
• Interchange
• Share it across for review
• Preview/Preflight/Correct
• Security
• Stream encryption (for both security and the amount of data you transfer to the printer)
• Use templates

But remember do you have any printers to do native PDF ripping? Because you are otherwise doing a lossy PDF to PS/PCL conversion. And you've just lost the game. Which brings me back to PostScript ;)

Answer 6

Just my 2p but if you are an XSLT ninja I'd suggest sticking with that. You can avoid the nasty java program by looking at nFop which is a C# port of the apache FOP project. What's great is that you can simply take the assembly and use directly passing your XML and XSLT to it to get the PDF output you want.

http://sourceforge.net/projects/nfop/

Hope that helps.

Answer 7

You can use PISA for Python. It uses the reportlab toolkit to generate a pdf from html (using html5lib)

Answer 8

You could also try using PDFCreator and simply printing the document to PDF. PDFCreator acts like any normal printer and uses ghostscript to convert printer output to pdf, tiff, jpeg, or whatever you want. I think you can change header and footer items through IE's com interface and print directly from IE. PDFCreator has examples for different languages in the com folder of the install directory. I have used it and can vouch for it. Windows only though.

Answer 9

Do you really need to use XHTML/Web browser?

I have been in this exact dilemma trying to generate good looking HTML reports and the solution I found is .... to drop HTML and use a "real" report generator, there are a lot of them out there, they all support all the pagination and header/footer options you can think about they can usually print to pdf and sometimes directly to images.

HTML is just not the right technology for reports.

Answer 10

Use some other technology that I haven't even thought of yet, like LaTeX.

TexML, which is LaTeX semantics with XML syntax. To use that you can create XSLT, which would decorate your XHTML with TexML commands (see example)

Answer 11

ExpertPDF HtmlToPdf Converter (www.html-to-pdf.net) should be able to do exactly what you need. It's really simple to use, just reference the assembly in your project and start using it. I've used this product with great success in a couple of work projects.

Answer 12

You mentioned your current desktop app exports results in xhtml. Since xhtml is well formed xml, you should get away with using xsl fo to export it to pdf.

XML -> XSL-FO = PDF

Here's a beginner's guide: http://www.devx.com/xml/Article/16430

My company has used this technique in a java+cocoon webaplication for the Dutch government.

Answer 13

http://iecapt.sourceforge.net/

quoting from above website:

IECapt is a small command-line utility to capture Internet Explorer's rendering of a web page into a BMP, JPEG or PNG image file. The C++ version also has experimental support for Enhanced Metafile vector graphic output. IECapt is available in a C++ and a C# version.