How to Print a PDF programmatically without the Adobe Reader Window

Guest
Jul 30, 2012 Jul 30, 2012

Copy link to clipboard

Copied

Hi,

I'm trying to print a PDF my application. I would prefer to do it as silent as possible - no PrintDialogue | Adobe Reader Window.

  • Language C#
  • Adobe Reader 10.0

Here´s some Code:

    public static void PrintPDF(string file, string printerName)
    {
        Process proc = new Process();
        proc.StartInfo.FileName = @"C:\Program Files (x86)\Adobe\Reader 10.0\Reader\AcroRd32.exe";
        proc.StartInfo.Arguments = @" /t /h " + "\"" + file + "\"" + " " + "\"" + printerName + "\"";
        proc.StartInfo.UseShellExecute = true;
        proc.StartInfo.CreateNoWindow = true;
        proc.Start();
        Thread.Sleep(1000);
        proc.WaitForInputIdle();
       

proc.Kill();

    }

It works, but the Adobe Reader Window is still popping up -> /h (start the reader minimized) does not work.

Is there another way to hide the Window ?

Regards

TOPICS
Acrobat SDK and JavaScript

Views

98.8K

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Jul 30, 2012 Jul 30, 2012

Copy link to clipboard

Copied

Moved to Acrobat SDK

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Jul 30, 2012 Jul 30, 2012

Copy link to clipboard

Copied

Correct - this is so that users don't have stuff printing out of their printers w/o their knowledge.

Using standard Windows techniques for hiding windows or opening apps minimized, if you must.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Aug 02, 2012 Aug 02, 2012

Copy link to clipboard

Copied

Hi,

I am developing an application, which have to support a PDF print. My result after searching for the best possibilities is this snippet:

    public static void PrintPDF(string path, string printer)
    {
        Process process = new Process();       
        process.StartInfo.FileName = path;
        process.StartInfo.Verb = "printto";
        process.StartInfo.Arguments = "\"" + printerName + "\"";
       

process.Start();

// I have to use this in case of Adobe Reader to close the window

        process.WaitForInputIdle();
        process.Kill();
    }

This is the most generic solution - it prints a pdf unless no matter wich reader is installed.

Only deficit - the Adobe Reader window still pops up. Why it does not behave like it´s alternatives (for example Foxit Reader) and print the PDF without popping up ?

Regards

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Aug 02, 2012 Aug 02, 2012

Copy link to clipboard

Copied

Because silent printing is a security risk – and unlike our competitors we CARE about security!

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Aug 02, 2012 Aug 02, 2012

Copy link to clipboard

Copied

Hi Irosenth,

what do you mean with "standard Windows techniques for hiding windows or opening apps minimized" - could you give me an example of this?

Thank you for the replies!

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Sep 02, 2013 Sep 02, 2013

Copy link to clipboard

Copied

I've been bitten by this "security feature" recently and digged up an ancient Adobe account to respond to the ludicrous statement:

"Because silent printing is a security risk – and unlike our competitors we CARE about security!"

Dear lrosenth,

The security issue you refer to is described here: http://www.fortiguard.com/advisory/FGA-2008-04/

It affects your javascript API and is a legitimate security flaw, but has nothing to do with MaxPr's question.

Any application, once executed, can print to any printer the machine has access to without user interaction. Adobe reader has no special magic privilige to do so, hence you are not improving security, you are just restricting automation of your software.

This new behaviour has also broken the file association verb "Print", in that it now causes Adobe to open, show the document momentarily, close the document, but leave Adobe Reader running. No amount of hand waving will persuade me that this is correct behaviour. It is ugly and incorrect and you should be ashamed. Adobe Reader version 4.0 from 1999 could do this correctly.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Sep 02, 2013 Sep 02, 2013

Copy link to clipboard

Copied

Any application, once executed, can print to any printer the machine has access to without user interaction. Adobe reader has no special magic privilige to do so, hence you are not improving security, you are just restricting automation of your software.

Agreed. However, since the automation of our software is a common operation that has been used in malicious ways, we chose to prevent that. Thus we are improving the security of our software.

This new behaviour has also broken the file association verb "Print", in that it now causes Adobe to open, show the document momentarily, close the document, but leave Adobe Reader running.

Yup – see above. And Reader has always remained running after an operation, for a specific period of time, for a variety of reasons.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Sep 02, 2013 Sep 02, 2013

Copy link to clipboard

Copied

Agreed.  However, since the automation of our software is a common operation that has been used in malicious ways, we chose to prevent that.  Thus we are improving the security of our software.

Pray tell, what malicious usage are you preventing by printing, but staying open afterward? The printing still happens without additional user interaction.

Yup – see above.   And Reader has always remained running after an operation, for a specific period of time, for a variety of reasons.

I can imagine the variety of reasons you would want to do that, but it is a bad solution. Also, Reader does not close after a specific period of time. I just tested it last night and it stayed open all night.

Once again, Microsoft's specifications on the "Print" verb states: "The application prints the contents of the file and exits, displaying as little as necessary to complete the task.".

But seeing as we disagree about this, is there a non-malicious way and likely paid for privilige that you provide through the SDK or some other means that allow another system to print PDF documents?

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Sep 03, 2013 Sep 03, 2013

Copy link to clipboard

Copied

Sure, you could license the Adobe PDFLibrary and use that for "silent printing" directly in your application.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Apr 16, 2014 Apr 16, 2014

Copy link to clipboard

Copied

The biggest issue still is that there is NO way to know when the PDF is done printing and I mean NO way. I have tried, watching the process, i have tried reading the print queue jobs, I have tried everything i can think think of.

I need to print many documents, word, excel, TIF, PDF, etc, and i need to print them IN order. All the other print jobs i can tell when they are done, but not Adobe. I don't want to be contacted by a salesperson, because he/she will say some large number per every programmer and then some medium number for every year for something that should just be working if you followed standards.

I echo everything Quadiago said. This is not a public solution, i am not concerned with malicous usage. Your product is just too plain old hard to use, in fact it is so hard to use that i have NO good solution.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Apr 16, 2014 Apr 16, 2014

Copy link to clipboard

Copied

Let me see - you are comparing the use of paid-for commercial products (such was Microsoft Office, for use with Word and Excel files) to a COMPLETELY FREE product (Adobe Reader).

If you were to use our paid for product (Adobe Acrobat) you would find the APIs that you require = just as you found them in the commercial applications you use.

(and I bet that the free Word Viewer from MSFT doesn't support printing in an automated fashion either).

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Apr 17, 2014 Apr 17, 2014

Copy link to clipboard

Copied

I am not comparing them; we do not edit PDFs, we do not create PDFs from scratch, we do not create PDFs from templates by programmatically adding data. Plus Word/Excel does have a FREE library call OpenXmlSdk that will allow programmers to create Word/Excel files programmatically or from templates.

I am saying that your product that you give away for free, I am sure was part of a marketing strategy, allows you to use to print from a command line. That functionality has been intentionally crippled to make it less then useful for some reason (in the name of security) that could be at best stupid and at worst nefarious.

George J. Pokorny

Senior Programmer Analyst | ITS WAM Team| Integrys Business Support, LLC

920-433-2545

920-264-6363 cell

920-869-3500 home

GJPokorny@integrysgroup.com<mailto:GJPokorny@integrysgroup.com>

www.integrysgroup.com<http://marketing.integrysgroup.com/t/8915/356171/763/0/>

Providing support for Integrys Energy Group, Integrys Energy Services, Integrys Transportation Fuels, Michigan Gas Utilities, Minnesota Energy Resources, North Shore Gas, Peoples Gas, Upper Peninsula Power Company and Wisconsin Public Service.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Apr 17, 2014 Apr 17, 2014

Copy link to clipboard

Copied

Hi,

it's some time ago I looked into this area. So far as I remember right you have 2 options.

1. Look into the old DDE commands (if it is still supported)

2. If the print startet you can try to close the Reader via WMI or other API tools.

It will be only closed if the already started print is done.

If you want also to check if print has started you have to check the print queue (WMI, WinAPI)

(..... - or to look if the paper coming out :-))

Good luck,

Reinhard

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Apr 22, 2014 Apr 22, 2014

Copy link to clipboard

Copied

Hi,

I am not happy with this security improvement as well.

I found this post:

http://stackoverflow.com/questions/5085491/closing-an-instance-of-acrobat-reader-from-command-line

works for me but is not as nice at it was before.

Cheers

Derion

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Sep 04, 2016 Sep 04, 2016

Copy link to clipboard

Copied

LATEST

> However, since the automation of our software is a common operation that has been used in malicious ways, we chose to prevent that.  Thus we are improving the security of our software.

You are not improving security of your software. You are violating Windows standards that had been in place for decades. Numerous thousands of Windows applications had been and still are using this functionality with the same expectation: that the application starts, prints, and quietly goes away  - starting with notepad.exe. Now comes Adobe who "unlike our competitors we CARE about security!" - said competitors apparently being the whole other universe, since nobody else came up with this idea. Do you think Microsoft should patch notepad.exe to be "more secure" by staying on the screen? The same malicious code that would strive to print on users' printers without their knowledge, might use Notepad, web browser, or any other print-capable application - all of which do conform to the standards and quit. You can't imagine that anybody would print by anything but Adobe reader?

So let's see what is the result of this "improved security". The result is that every your customer who is using this feature is frustrated, and looking for a workaround, which is evidenced by the dozens of posts in all places, all about the same - how to make acrord32 window close after printing. The result is that programmers write the special code that finds acrord32.exe process and kills it. Is this more secure? No, it's 1,000 times more arrogant and counterproductive. Your users naively think that this is a bug that you just don't care to fix. It can't even cross the mind that the design as counterproductive as this might be a conscious design. And certainly, nobody is taking advantage of this increased awareness, so the whole effort is moot.

Of course, half of the users found another solution - they switched to another pdf reader, like Foxit or Sumatra, both apparently so unconcerned about the security that they work as everybody expects.

Show us one soul who congratulated you for this "security" mitigation. Show one who has agreed that this helps. Show one who even understands how to use the fact that reader's window is on the screen. You won't. But you don't care, because apparently you know better than everybody else.

Speaking of security, do you know how an application that stays on user's computer uninvited and unsolicited is called? It's called a virus. And yes, half of the viruses claim that they are there to protect the user, and half of those actually believe that it's true. Apparently, the distance between arrogance and malice is short.

But the problem is not only in the fact that the window stays. The problem is that the reader that stays on the screen, does not operate as expected.That is, after running the following code:

        Dim pr As New Process()

        pr.StartInfo.FileName = "c:\myfile.pdf"

        pr.StartInfo.UseShellExecute = True

        pr.StartInfo.Verb = "print"

        pr.Start()

        pr.WaitForExit()

Reader's window stays on the screen. If we now try to open another pdf file by double-click in Explorer, it won't open. You now can open it only from Reader. I guess, this is another security measure?

Regarding helpful advise to use the API - regardless of the API, you install your product with the standard verbs "print" and "printto" available to shellexecute. If so, then these verbs should perform as expected, because this is industry standard. If you think that it's bad idea and you don't want to support them, then you should remove those verbs from the system. Leaving there when they don't work as they should, is standards violation, however noble are justifications.

We hope that Adobe will finally listen to your customers and do what they expect. We heard your concern, but we don't appreciate it.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Jul 31, 2012 Jul 31, 2012

Copy link to clipboard

Copied

Hi,

you mixed up the commandline options, so:

AcroRd32.exe /h /t "......."

should work (at least until v9..)

HTH, Reinhard

PS: simple test under START->EXECUTE: AcroRd32.exe /h /p "c:\Test.pdf"

where /p stands for print to standardprinter

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines