are the jobs coming from remote machines on the server and are you using the PDFCreator Server version?
All other PDFCreator versions can usually only handle print jobs coming from the local machine.
that sounds like it should work, is the printing application installed on the server?
The /printfile parameter will print the file from the associated application.
Maybe it will help to find the problem, if you set the logging level to “trace” in the debug section of the application settings, print something and post the log here or send it to support(at)pdfforge.org and we will gladly have a look at it.
When I start pdfCreator exe using code as shown from my web application - nothing comes up in log file - even I have used debug mode - Trace.
Looking further to the issue I found something as below:
From task manager
PDF Creator starts soffice.exe and it calls soffice.bin
in soffice.bin argument -> “-writer” “-env:OOO_CWD=[path]”
If i try to open PDF creator exe from another exe on server [manually - logged in on server] - [path] in OOO_CWD command is correct - which is my local directory in inetpub.
But when PDF Creator is triggered from web application [path] is “C:\Windows\SysWOW64\inetsrv”
It seems that this is the issue preventing my doc file conversation.
how does the path variable get populated?
It looks like it is connected to the PATH environment variable settings which are set differntly on your user account and the account the web application is run from. PDFCreator only looks up the command to print the specific file type in the registry and executes that command. If adjusting the PATH environment variable doesn’t help, it might help to modify the print/print to entry for the doc/docx file type to use a hardcoded path.
please go to the advanced system settings and check your environment variables.
env:OOO_CWD is an enviroment variable which is used to determine which path open office (or the required component) is located in. Forget what I said about the PATH environment variable I was getting confused by the naming, sorry.
it looks like it could be related to that, but from your earlier posts it seems ther is an issue with the registered print command and a misterious OOO_CWD variable. I installed OpenOffice (4.1.2) in a virtual machine and check the registry entries for the “print to” commands for .doc files, which is “C:\Program Files (x86)\OpenOffice 4\program\swriter.exe” -pt “%2” “%1” here. To check this, go to HKEY_CLASSES_ROOT.doc\OpenWithProgIDs (which is OpenOffice.Doc here) and then check which command is registered for printing with that ProgId in HKEY_CLASSES_ROOT\OpenOffice.Doc(or whatever ProgID is used on your machine for .doc files)\shell\printto\command.