Click here to Skip to main content
14,696,629 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I'm working on a project in which I have to print PDF reports to specific printers.

I've tried a few approaches (including MigraDoc and others) but the only simple solution I could find so far, was opening a copy of Adobe Acrobat Reader with the correct parameters, causing it to print.

This solution has 2 problems:
1. It needs a dedicated server since Adobe pops-up every time a report is printed, even though the parameters specify that it should remain minimized. (This is a common problem)
2. More-or-less-randomly one in every 10 documents print without passing the correct document name to the printer, resulting in a document name of "Local Downlevel Document" and since I closely watch the spool in order to give feedback to the user regarding the printing of the report, I cannot identify the document in the spool or match it to the correct report.

Anyone here with experience in printing PDF's? Are there better solutions?
Updated 1-Aug-10 23:25pm

There are some options you could try. Since you only need to print the documents you only need a kind of viewer. There is an example here on codeproject for this:

PDF Viewer Control Without Acrobat Reader Installed[^]

Good luck!
MatthysDT 3-Aug-10 7:35am
Thanks, that article was very helpful. Unfortunately, that project also prints random documents with the DocumentName as "Local Downlevel Document". So, now I'm no longer dependent on Adobe, so at least I've made some progress!
E.F. Nijboer 3-Aug-10 7:42am
The random "Local Downlevel Document" could also indicate a printer driver issue. Maybe you could try some other brand/type printer to rule this out. Also, this is a problem that more people have encountered and I guess this isn't related to Adobe or this component. If you google the phrase "Local Downlevel Document" you get a huge amount of results and explainations like "You might have the BugBear virus - that's the usual cause of the Local Downlevel Document issue."
MatthysDT 3-Aug-10 9:30am
Reason for my vote of 5
great reference
Ok. Looks like I've found my problem. So for completeness sake and for the next poor soul to come across this "Local Downlevel Document" problem please read this:

If I'm correct in my assumptions, it seems that when Windows (Windows 7 in my case) creates a new Print-Job, the default Document Name is always "Local Downlevel Document".

Windows then immediately updates the Document Name to the correct name (usually the filename, but it will vary from app to app).

Now, if you are using a WMI Query to get the print job info, it may happen at random that you poll a Printjob right after it was created, but just before it's name was corrected, and THAT"S when you get the wrong document name.

So my fix was simple, for each WMI query iteration, I do not only refresh each job's status, but also it's document name (which I didn't do at first since I justly assumed that the document name will never change).

Problem Solved.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900