By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,825 Members | 967 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,825 IT Pros & Developers. It's quick & easy.

Server Side Word to PDF conversion

P: n/a

We have a project that requires a .NET service to convert a Word document to
a PDF document. Basically, a person would create a mail merge template in
Word and through automation, we merge the data and spit out one or more PDF
documents. It appears that the best thing for me to do is get a product
that installs some type of printer driver. The problem is that the drivers
pop up a dialog box prompting for the destination file location. I would
like to do that in code. The standard flow would go something like this:

1. Retrieve Word Document
2. Retreive Data
3. Print result to PDF printer at location X.PDF.
4. Deliver/copy/archive X.PDF

Has anybody done anything like this? What products do you suggest that I

I have spent the last couple days doing research, testing, etc. and am
frustrated with how long it is taking to find a good solution, so I thought
I would ask if anybody has had any similar experiences. I know this topic
has been covered in this newsgroup, but none of the topics seemed to address
this server-side issue. I apologize in advance :-(.

Thank you very much,
Curtis Justus
Nov 15 '05 #1
Share this Question
Share on Google+
1 Reply

P: n/a

We have a product (limited release stage now), that should do what you

The web site is and the product name is
"PDFMate Server"

The system is a multi-threaded, scriptable, windows service that
allows for "SAFE" server-side PDF conversion from a variety of desktop
applications, with an emphasis on Office documents.

The key features are:
1. Totally Dot Net managed code (Except of course for automating
Office Apps)
2. Royalty free PDF conversion using Ghost
3. Process Isolation and automatic timeouts
4. Scriptable engine (VB.NET scripting using VSA) that can accommodate
many different applications
5. Windows Service with automatic monitoring of directories, FTP
Sites, POP3emails, MSMQ
6. Templates for email subscription
7. Automatic delivery and publishing
Here how it works:
- At the core, there is a Windows Service that monitors for incoming
jobs. Any number of monitors can be defined, and we support 6 types of
monitors: (Directory, Pop3, MSMQ, FTP, PDFmate Internal, PDFMate
- A File (doc file for example) can be sent to the server using any of
those techniques
- An optional Job file can be created. The Job file is an XML
structure specifying the parameters for THAT document (i.e., who gets
the results).
- if no job file is found, a job file is created based on a
user-defined template (We call this 'autoconversion').

- Once the job file is created, it is placed in a job queue. You
control how many versions of Word/Excel/Powerpoint you want active at
any time.
- The job file specifies a script (VB.NET code) that must be run to
convert the file. We provide the basic scripts you will need and you
can tailor them.

- The Kernel then runs the job in a separate process. If Word hangs,
or throws a message box, the system will kill the job and report the
error. (There is a user-defined timeout)

- The job file actually runs using .NET scripting, which you can
tailor to your own needs. We use the VSA engine to compile/run the
script code. This gives the product a high degree of user-defined

- A Job has a main conversion script (Like Doc2PDF.vb), a
post-processing script that is used to handle publishing, emailing,
etc, and an error script to handle errors.

- The job file specifies the output filename, and what action to take
on the PDF file. Job files are XML format, and serialized at the end
of processing with results and/or error messages.

- We provide a monitoring tool to see how the service is doing.

- There is a sample web site as well that is included with the

The basis of this application was developed for a commercial
application, and we have since taken it and productized it as a
standalone product.

I know this is a long message, but this type of application, done
right, is way more complicated than it looks on the surface. We have
spent a lot of time understanding exactly how the threading and
process management work in .Net. We have also implemented .NET
Remoting on the server to we can control the process from a Windows

Please take a look at the information on the web site. Some of the
documentation needs updating, and we can provide additional
information on request.

Our objective in the near term is to pick a few companies to work with
so we can have some good reference sites.


Frank M.
(813) 856-0249
Nov 15 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.