Document Conversion - to print or convert?

Mar 11, 2008 at 7:57 PM
Edited Feb 10, 2009 at 9:20 PM

I would like to get a discussion going on how to best create document converters. *’A much advertised 3rd party product’ seem to convert, or interpret, rather than using printing. Printing on the server using desktop app automation certainly has its problems, but so does conversion/interpretation. When I tested *’A much advertised 3rd party product’ I found my content rich documents did not convert accurately. It is not surprising that conversion based on interpretation is a difficult task.

Other 3rd Party Products have had accurate conversion down for years, but these products rely on desktop automation and the time tested accuracy of 'printing'. Really they just provided a wrapper around Office 2003 desktop automation and print queues. And automating desktop applications on a server is problematic. For various reasons desktop automation based processes tend to break down, specifically under load. Sometimes it's a print-queue problem, or more often a matter of multiple instances of the desktop app building up on the server until the process breaks down.

What should a developer do?

These document converters I have developed rely on Office 2007 (Word and Excel) being installed on the server.

It seems to me that these converters, using the Office 12 interop assemblies, operate much better than Office 2003 desktop applications on the server. But I don't know the details as to why, or how Office 12 is different. Please contribute to the discussion if you know.


It is best to isolate document conversion onto its own server(s) if you have the resources.  The following link is a good starting point