CLI usage details missing

[Azhy-Slemany]

Thanks for this useful tool.

Some more detail could be written to run the app with CLI instead of GUI, and here is steps I used to do it (which can be explained for others as well):

1. Name the executable something containing "cli" phrase like PDFtoPrinter-cli.exe.
2. Pipe the command to more so that it will show the results in the command line, ex) PDFtoPrinter-cli.exe "file.pdf" "printer_name" | more.
   Or, you might compile the source with this directive: #AutoIt3Wrapper_Change2CUI=Y

I could do it with a PR, but I thought it will be easier if you do it yourself.
Thanks in advance.

[emendelson]

I see that I made a CLI version of this in 2020, and found problems with it, so I never released it. I don't remember what the problems were. Of course you should feel free to compile it yourself and see whether it works or not. Please let us know your results.

(When I pipe the command to more I don't see any output, so I'm not sure what it is that this might accomplish.)

[Azhy-Slemany]

Actually I only wanted to see errors in the CLI instead of GUI (which was stopping my console app), and it works (for the errors, especially the printer or argument not found error), but I'm not sure about other possible commands, and unfortunately I don't have enough time to test, but I think for successful commands it doesn't generate anything and also it's not needed as well, the only thing that is important is some simple feedback on error responses, and also there might be some possible problems of the printers that the script might not be able to detect (the win32_printer api as well), and we can't blame it for that as the problem is the printer driver itself that is not giving enough details about errors, and what I see is that.

[emendelson]

Please feel free to recompile as a command-line app post the differences in the AutoIt script. I'm sure other people will also be interested.