PrinterName ignored in command line parameters

I have used PDF creator successfully for the last 4 years to automatically email a PDF version of an excel spreadsheet each day. There was a recent Win 10 x64 update in the last few days which I think has affected the PrinterName parameter, as it is now ignored and always prints to the Win 10 default printer.
I use the Windows Scheduler to trigger the PDFCreator program and a command line to pass the parameters, PrintFile (containing the excel spreadsheet) and PrinterName (containing the PDFCreator printer which emails the excel PDF attachment via SMTP).
I have uninstalled and reinstalled the latest version of PDF creator V3.1.2 but still have the same problem. Any suggestions?

Hi,

which command line did you use?
The PDFCreator.exe /PrintFile command should never print to the default Windows printer, it should use the default PDFCreator printer if no /PrinterName parameter is given or it can’t find the printer specified.

Best regards

Robin

Hi Robin,

I an from Holland and i have the same problems.
The program did this automatically, i cant print the pdf he prints the document instantly without the pdf background

Hi,

I don't think this is the same issue, it sounds more like it could be

Best regards

Robin

Hi Robin,
I used the command line in the Windows Task Scheduler feature, it’s pretty straight forward and has been working fine for 4 years, but now is ignoring the PrinterName parameter and always prints to the windows default printer.
The PDF creator printer I use in this example is called JS, which SMTP emails the excel spreadsheet (job schedule.xlsx) as a PDF attachment. When I open excel manually and print to the PDF creator printer called JS it works fine and runs PDF creator then send the excel as a PDF email attachment, I just can no longer get this working via a command prompt using the PrinterName parameter. I have also tested outside the Windows Task Scheduler system in the even it may have been a problem with parameter passing of the native Windows Task Scheduler system by using the DOS command prompt within windows but it still refuses to recognise the PrinterName parameter and always prints to the windows default printer. Command line as follows:
“C:\Program Files\PDFCreator\PDFCreator.exe” /PrintFile=“C:\Users\Luland01\OneDrive\Data Tanya LULAND\Projects\Job Schedule.xlsx” /PrinterName=“JS”
Hope PDF Support can assist, as I am a generous donor and avid supporter :slight_smile:

Hi,

I am experiencing the same issue - Since the last windows update PDFCreator fails to switch to the PDFCreator printer and sends printing to the default printer.

I noticed that this issue occurred only on machines with Microsoft Office 2016 using the latest update (1712 Build 8827.2148) and happened when I try to convert xls/xlsx files (it does work for doc/docx files).

I also tried to use PrintFileSwitchingPrinters and failed to fix this issue.

I tried it using PDFCreator V2.1 and V3.1 - both failed to switch the printer.

Can you please assist?

Hi Orr
I can confirm I am running the same Microsoft Office 2016 version 1712 Build 8827.2148
This maybe the cause of the problem, I would need to test to see if i have the same problem when running PDF creator via a command line with non Office files. Are you able to do the same?
Regards
Mango

Hi Mango,

Made another test - it is working for me with non Office files.

Regards,
Orr

Hi Robin,
I dont seem to be able to get any of the command line parameters (PrinterFile or PrinterName) to work. I have used the following command line in windows powershell and receive the following error. Appreciate if you could shed some light. Thanks
PS C:> “C:\Program Files\PDFCreator\PDFCreator.exe” /PrintFile=“C:\Users\Public\Public Temporary\test.jpg” /PrinterName=“JS”
At line:1 char:47

  • “C:\Program Files\PDFCreator\PDFCreator.exe” /PrintFile="C:\Users\Pub …
  •                                           ~
    

You must provide a value expression following the ‘/’ operator.
At line:1 char:47

  • … eator.exe" /PrintFile=“C:\Users\Public\Public Temporary\test.jpg” /Pr …
  •             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    

Unexpected token ‘PrintFile=“C:\Users\Public\Public Temporary\test.jpg”’ in expression or statement.
+ CategoryInfo : ParserError: (:slight_smile: [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ExpectedValueExpression

I will have a closer look at the entire situation now.

I am afraid I am unable to reproduce this issue on my Win 10 machine with PDFCreator 3.1.2 installed (I am using ConEmu though instead of Powershell).
PDFCreator will at first try to find a “print to” shell verb for the file type to be printed and if it doesn’t find one, it will look for a “print” shell verb and attempt to temporarily switch the default printer to PDFCreator. So two possible causes could be either the “print to” shell verb has registered an incorrect command (unlikely) or the temporary switching of the default printer is failing. Could you set the logging level to “trace” in the PDFCreator application settings, empty the logfile, run the command line and send us the resulting log (support(at)pdfforge.org)? It might help to find the cause of this issue more quickly.

Hi Robin,
I can confirm I have tested many scenarios and have the same results as Orr in the thread.
PDFCreator command line prints to the Windows default printer and ignores the PrinterName parameter when printing Microsoft Office files using Microsoft Office 2016 version 1712 Build 8827.2148.
I have also tested the command line using non Microsoft Office files and PDFCreator behaves correctly ie it prints to the printer named in the PrinterName parameter.
Do you have access to the current version of Microsoft office to test, running on latest Win10 x64?
Regards
Mango

Robin,
I have set logging to Trace, and after running PDF creator via a command line in Windows Task Scheduler the log file is blank, not sure why.
Maybe you can test with Office version on your machine to see if you can replicate the result.
Suggest trying Windows Task Scheduler to run the command line and place the PrintFile and PrinterName parameters in the Actions/Add arguments section.
Regards
Mango

Hi,

which value does the “Default” entry for HKEY_CLASSES_ROOT.docx contain on your machine?
For me it is “Word.Document.12”. If this is the same on your machine, is there also an entry in HKEY_CLASSES_ROOT\Word.Document.12\shell\Printto\command, which should read
“C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE” /j “%1” “%2”
Do you also get the issue if you print the office files from a command line (and not from a scheduled task)?

Best regards

Robin

Hi Robin,

The “Default” entry for HKEY_CLASSES_ROOT.docx is same as yours ie “Word.Document.12”.

I do not have HKEY_CLASSES_ROOT\Word.Document.12\Shell but I do have HKEY_CLASSES_ROOT\Word.Document.12\ShellNew but no PrintTo parameter

I have also tried the PDFCreator command via the DOS Command Prompt within windows and get the same results as I do via the Task Scheduler method ie ignores the PrinterName parameter only when printing Microsoft Office files

Appreciate any help you may be able to provide.

Regards
mango

Hi,

you could manually add the required entries, first create a backup of your registry (no problems to be expected, but always recommended) and afterwards create the key(s) HKEY_CLASSES_ROOT\Word.Document.12\shell\Printto\command
with the default entry being "C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE" /j "%1" "%2"
as on the screenshot below (German OS though):

Best regards,

Robin

Hi Robin,
Sorry for the late reply.
I checked the registry and this entry now exists, I am guessing that a recent windows or office update added this entry as it is exactly the same as what you have listed.
I am still receiving the same result when printing a Microsoft Office file (Excel in this example) from a command line ie it is ignoring the PrinterName parameter and printing to the Windows default printer. However when I open the excel file and print manually from within excel and select the PDFCreator printer then it works properly ie sends an email of the PDF’ed excel file as an attachment.
I have also checked once again that PDFCreator works properly when printing non Microsoft Office files (.JPG in this example) from the command line ie it follows the PrinterName parameter correctly.
Appreciate your help.
Thanks
Mango

Hi Robin,
Just to let you know that there have been a number of updates to Microsoft Office 365 in recent weeks and the current version Version 1802 (Build 9029.2167) is working file and does recognise the PrinterName parameter on a command line.
Regards
Mango

1 Like

Thanks for the update, I can confirm that the command is working in the current Excel build; lets hope they don’t break it again…